3 ms·

My favorite part was when you were rewarded for scouring the source code by finding an undocumented qdisc, that was golden. :) You mentioned that your colleagu

My favorite part was when you were rewarded for scouring the source code by finding an undocumented qdisc, that was golden. :) You mentioned that your colleague had produced a patch that did file handle passing? Is that patch available? My first thought on reading that was, how many other people have tried that very task. Im wondering if it would be helpful to HAPrpxy if your patch was made available? Thank you for sharing the plug qdisc, this is hugely useful in any number of situations. Did you find any others by chance? I can see why some would say this solution is brittle, but actually I quite like it. It feels elegant and The Right Way to do it.

josnyder 12y ago
Yep, I found a number of them, but I promptly forgot them in excitement when I found the one I actually wanted. If you want to check them out yourself, they appear to congregate in the kernel tree at net/sched/sch_* [1]. The only other qdisc I have much experience with is sch_netem, which emulates behaviors of a WAN (delay, loss, etc). I used it in this post [2] to conduct adversarial testing of MySQL replication (search 'tc qdisc'). [1] http://lxr.free-electrons.com/source/net/sched/ http://lxr.free-electrons.com/source/net/sched/ [2] http://engineeringblog.yelp.com/2014/03/mysql-replication-network-issues-and-why-you-might-want-to-upgrade.html http://engineeringblog.yelp.com/2014/03/mysql-replication-ne...
jolynch 12y ago
Josh gets all the credit for finding the plug qdisc. I was originally planning on using netem and having a fixed delay of 50ms or something, but Josh decided that wasn't elegant enough and went looking for a better solution. As for the patch, I can certainly ask John but I do know that the proof of concept was written during a hackathon so I imagine there could either be fundamental flaws or just need a lot of work to get ready to merge. From reading the HAProxy mailing list I think they have been working on this for a while, but the issue seems to be merge risk (it's a fairly large architecture change). I'll mention it to John though. I'm glad you think it's elegant :-) I tried hard to find a solution that was minimally invasive (no code changes, no significant infrastructure, etc ...).

josnyder 12y ago

Yep, I found a number of them, but I promptly forgot them in excitement when I found the one I actually wanted. If you want to check them out yourself, they appear to congregate in the kernel tree at net/sched/sch_* [1]. The only other qdisc I have much experience with is sch_netem, which emulates behaviors of a WAN (delay, loss, etc). I used it in this post [2] to conduct adversarial testing of MySQL replication (search 'tc qdisc'). [1] http://lxr.free-electrons.com/source/net/sched/ http://lxr.free-electrons.com/source/net/sched/ [2] http://engineeringblog.yelp.com/2014/03/mysql-replication-network-issues-and-why-you-might-want-to-upgrade.html http://engineeringblog.yelp.com/2014/03/mysql-replication-ne...

jolynch 12y ago

Josh gets all the credit for finding the plug qdisc. I was originally planning on using netem and having a fixed delay of 50ms or something, but Josh decided that wasn't elegant enough and went looking for a better solution. As for the patch, I can certainly ask John but I do know that the proof of concept was written during a hackathon so I imagine there could either be fundamental flaws or just need a lot of work to get ready to merge. From reading the HAProxy mailing list I think they have been working on this for a while, but the issue seems to be merge risk (it's a fairly large architecture change). I'll mention it to John though. I'm glad you think it's elegant :-) I tried hard to find a solution that was minimally invasive (no code changes, no significant infrastructure, etc ...).