100% epoll_wait loops in 1.5.11

, hoping the description makes the issue obvious to the authors. thanks! -Dormando (not mailing from my usual address since I got RBL'ed :/ user on the same IP had a spam field day)

Re: HAPROXY pool of keep-alive connections to backend

backend persist, but you add some latency. If nothing else, I'd be curious to know what real bugs perlbal has relative to backend keepalives, so we can document them at least. -Dormando

Re: HAPROXY pool of keep-alive connections to backend

I'm not even speaking about a specific implementation but about HTTP. HTTP provides no way to announce that a keep-alive connection will close. So in general it can close while you are sending a request over it. HTTP says that when this happens, you just apply a classical back-off algorithm

Re: HAPROXY pool of keep-alive connections to backend

The problem is not the client but the server. When you're resending a request to it, you have to know whether it may have started processing your past request or not. Yeah, my point is that semantically it doesn't seem to make a difference whether or not the LB is there if you close the

Intel nehalem crc32 for URI hashing (and Keep-Alive)

Hey, Attached, and linked here: http://consoleninja.net/p/haproxy_intel_hash.diff ... is a patch to HAProxy 1.3.22 that uses intel's nehalem hardware CRC32 instruction for the URI hashing. I did some tests here: http://dormando.livejournal.com/522027.html With this bench tool:

Re: Intel nehalem crc32 for URI hashing (and Keep-Alive)

to index. That's fine though, still a 4x+ speedup for longer strings. -Dormando