Hi all,
Yes that's it, it's not a joke !
-- Keep-alive support is now functional on the client side. --
From now on, we support 4 different modes :
- tunnel mode (the default one), where we only look at
the first request and first response then let everything
be exchanged as if it were pure data. I wanted to get rid
of that one but I realized that many people are running
their static servers that way as a workaround for lack of
keep-alive. So let it live a bit longer.
- server-close : this new mode is enabled via option http-server-close
and maintains keep-alive on the client side while closing connections
on the server side. It's comparable to what apache 1.3 or nginx do.
- close : this one is still enabled via option httpclose but now
tracks the whole request too in order to keep ni sync till the end
(previously it considered everything as data).
- force-close : enabled via option forceclose, like httpclose, but
it also enforces connection close at the end of each request. In
the past it was discouraged from using it because it used a trick
consisting in closing the request as soon as the response started
to come back. Now it really waits for both channels to complete
before closing. It will probably become the new httpclose later
as it is what it should be.
Technically, the code could also support plain end-to-end keep-alive,
but there are still some issues to work on first, starting with how
to steal a sleeping session in case of starvation. Also, the code to
reinitialize a request is quite awful right now and I should say I
don't like it, so most likely there will be some changes later which
will benefit to full keep-alive.
Some minor improvements have also been performed. The redirects are
now emitted as HTTP/1.1 with a content-length and maintain keep-alive
if the request asked to do so and the response is relative to the same
site (begins with a slash).
The HTTP parser has been enhanced and fixed a lot to correctly support
keep-alive. Despite previous blind efforts, it was far from being
pipelining-compatible. Now pipelining works for both requests and
responses (provided the server responds fast enough for its response
to be merged with a former one).
Pipelining is really what reduces perceived latency over slow networks,
and what saves CPU cycles, as we reduce the number of system calls that
way. The code is currently capable of 1 million pipelined requests and
responses per second on one core of my Phenom 3 GHz (this is done by
matching an ACL and performing a keep-alive redirect). But performance
drop as soon as we make system calls. In server-close mode, I've got
numbers varying between 40 and 82000 requests/s. I have to re-run the
tests with a stabilized lab to get more reliable numbers.
The end-user feeling has improved nicely. The following page contains
110 small images and is served about twice as fast with keep-alive and
pipelining enabled when doing a soft refresh (Ctrl-R) :
http://www.ant-computing.com/album.html
This is due to the fact that the browser can fill packets with requests
and that haproxy fills packets with multiple short responses (304 not
modified), resulting in a low number of overall packets exchanged over
the net.
Please note that there have been several issues during the development
of this feature, and while we have apparently fixed everything we found,
it is still possible that some of them remain. So use it with care.
Another important point concerns the logs. When multiple requests are
processed from a same connection, they will look similar in the logs
because there is no indication of keep-alive right now. However, the
accept date is reset to the completion date of the last request, so
that the next request time corresponds to the time the browser took
to send a new request.
The keep-alive timeout is bound to the http-request timeout right now,
but I'm thinking about adding a new timeout for this one, so that we
can lower it even more (eg: a few tens or hundreds of milliseconds).
Please note that there have been quite a number of fixes since last
version. Maybe some of those fixes were for bugs introduced since,
but if you're experiencing issues with 1.4-dev4, you should give this
one a try. Oh BTW I've removed the limits on the numbers of config
files and reqadd/rspadd statements some users were complaining about.
Right now I don't have anything else to say. You can grab the sources
here as usual :
http://haproxy.1wt.eu/download/1.4/src/
As usual, have fun and please report any positive or negative experience !
Willy
