I collect come interesting infos/notes about useful applications.

http://www.anchor.com.au/blog/2009/10/load-balancing-at-github-why-ldirectord/

Comment from Willy TARREAU:
Concerning the performance, it depends what you are doing. Direct-routing load balancers installed in one-leg configuration where they only see upstream traffic will always be faster than a proxy because they see about half the packets. Common figures are about 4 times haproxy's max connection rate. A load balancer set up in the middle of the stream will still generally be faster than the proxy on connection rate, but can be slower on high bit rates (multi-gigabit), because it cannot make use of TCP speedups the NIC provides, while a proxy can. For instance, haproxy can forward 10 Gbps of HTTP traffic with only 20% CPU on one of my machines, while this machine has high difficulties to simply IP-forward the same stream at this rate. This is because of the TCP off-loading capabilities of the NICs which can only work with the proxy. But granted, this is not everyone's needs !

Concerning queuing, well, I can tell you that this has saved quite a number of medium to large sites. Yes connections can sometimes pile up. But better accept them, parse them, reject wrong ones and get the good ones ready to be served than simply drop the SYNs and wait for the client to resend them 3 seconds later. Also, it is quite possible that your site has a very predictible load. But gaming sites, sports sites, online newspapers, stock exchange, etc… are extremely unpredictable and need to be prepared for 4-10 times the load without failing, even if some requests get slightly delayed. And quite honnestly, it's very rare that the queue delay is counted in seconds. This happens when something breaks behind. But even there, having the ability to automatically flush requests out of the queue is nice.

Concerning QoS, well, it also depends on your usages. Gaming sites like to reserve resources for paying customers. Other sites with many external partners will prefer to prioritize some requests vs some others to the same partner so that if they become bandwidth-limited, the most important objects are fetched first. But doing that really does not cost much. It's just a switching rule between two queues. You may drom from 15000 connections per second to 14980 maybe, this is not particularly noticeable.

Concerning the logs, I don't agree with you. The web servers will tell what they do, not how it's perceived. The front LB will see how it's perceived and will be able to quickly tell you that server XX has higher response times than others or fails to accept a connection 1/1000th of the times, etc… This is very valuable information when people start to complain about performance issues, and it's even better when you can compare what the LB sees with what the server says. Most often, the difference is in (too short) system queues on the server itself (small TCP backlog, etc…) that can't even be detected by the server software because the information is dropped before reaching it. That's also the only place you can detect the famous 3-second stairs indicating some packet loss.

Overall, all a proxy can bring is a tradeoff, adding more intelligence in the decisions taken by the load balancer at the expense of an increased resources usage on one cheap box. If the smart decisions can improve the site's responsiveness, reliability or scalability, that's fine. If they don't bring anything, it's not a place for a proxy. That's why you generally see them in front of HTTP servers, sometimes in front of mail servers, database servers and terminal servers, and rarely in front of anything else.

Most likely in your case, as you explain it, it would simply not bring anything for your current usage (and I have no problem with that). And I agree with you that with only 128 MB of RAM it's hard to run a proxy with large numbers of connections, considering that the system itself will take 16 kB minimum per connection !