Hi Willy, thanks for the response!
On Mon, May 18, 2015 at 7:58 PM, Willy Tarreau <w...@1wt.eu> wrote: > It's useless at such sizes. A rule of thumb is that splicing will not be > used at all for anything that completely fits in a buffer since haproxy > tries to read a whole response at once and needs to parse the HTTP headers > anyway. In general, the cost of the splice() system calls compared to > copying data sees a break-even around 4-16kB depending on arch, memory > speed, setup and many factors. I find splice very useful on moderately > large objects (>64kB) at high bit rates (10-60 Gbps). On most gigabit > NICs, it's inefficient as most such NICs have limited capabilities which > make them less efficient at performing multiple DMA accesses for a single > packet (eg: no hardware scatter-gather to enable GSO/TSO for example). > I had considered doing tcp proxying at the top level haproxy such that this workload is passed down to individual hosts and then maybe splice would be effective, but I am not sure it is enough of a win. Managing http as such seems to be more correct and gettting http stats is useful too. We are running Intel I350 Gigabit NICs which appear support most tcp offloading except LRO. We previously had Broadcom interfaces, which again had good TCP offload, but appear to have interrupt coalescing issues. Are you still using Myricom cards? Any thoughts if these would be a win with our workload? Our data rates are relatively small, it's all about request rates. > > Nothing apparently wrong here, though the load could look a bit high > for that traffic (a single-core Atom N270 can do that at 100% CPU). > You should run a benchmark to find your system's limits. The CPU load > in general is not linear since most operations will be aggregated when > the connection rate increases. Still you're running at approx 50% CPU > and a lot of softirq, so I suspect that conntrack is enabled on the > system with default settings and not tuned for performance, which may > explain why the numbers look a bit high. But nothing to worry about. > > Conntrack is not used or loaded, however, what I believe is contributing to higher than expected system load is non keep-alive traffic. We also serve a lot of http 302s, about 1000 reqs/sec, keep-alive is disabled as these are single requests from individual clients. For these I would love to have backend connection pooling, I've seen it discussed, but based on my reading of the conversations it may be problematic to implement? Is this still a likely feature? Regards, Rob
