Hi everyone,
Well, as said in the subject, here it is. It should be no surprize since I
announced it 3 days ago. Version 1.3.14 is a big step forward in the number
of changes, in part because of two major features I needed, and also thanks
to a huge boost in contributions rate since the mailing list was opened.
I owe a Big Thanks to several contributors, for the time they spend on the
code, for the quality of their contributions and for their open mind, which
allows me to trust them quite a lot and merge their code without worries.
They help me focus on major core changes without being disturbed by the
usual rate of regular new features requested by users. People offering help
to new users also save me a lot of time, and provide faster responses to them
than what they were used to, and that's really great !
Given the nature of some contribs, it looks like this version is quite
important to several of us. I personally relied a lot on it to begin the
progressive upgrade of a large set of 1.2 and even 1.1 on sensible production
systems. We've been running a lot of tests today and did not catch even
one bug yet, which is encouraging, even if we'll be very careful about any
unexpected behaviour. BTW, layer 7 performance remains very good, with about
20khits/s on small objects, 1.6 Gbps on large objects, and 10khits/s @1Gbps
on mixed traffic, all that on a single-socket dual-core opteron @1.8 GHz,
with content-switching, cookie insertion and logging enabled.
I consider that we're now getting pretty close to switching to a stable
release, and moving important changes to a new branch. I still have several
medium changes pending in the queue (leastconn, log buffers and better
protocol abstraction), and after that I'll freeze the branch and try to
complete the documentation.
Major changes from 1.3.13 to 1.3.14 include :
- new tree-based fair WRR scheduler to replace the previous algorithm,
this one permits to adjust server weights on the fly without recalculating
a table. It was required to support the slowstart. A positive side effect
is that it considerably reduced the time required to find an available
server in situations were one of more servers were at their maxconns,
leading to better performance (or less CPU) at high rates.
- major rework of the listeners and reordering of the protocol-specific
code. In earlier versions, a listener was only available through a
proxy. Now everyone can declare a listener, which will make it easier
to later implement support for FTP.
Useful changes include :
- Krzysztof Oledzki's downtime report. It reports for how long a server
has been in current state, as well as the total cumulated downtime. This
helps troubleshooting and also makes it possible to announce SLA indicators
to customers.
- Elijah Epifanov's maxqueue parameter. It puts a limit on the per-server
queue length, above which requests automatically get redispatched instead
of waiting for nothing to happen.
- Krzysztof Oledzki's continuous statistics option. This is handy on long TCP
sessions (eg: RDP, SSH, ...) where you used to only get statistics once the
session ended. Now you get them in real time.
- Alexandre Cassen's http_proxy option and ACL matches. With this option,
it becomes possible to request haproxy to connect to any server by using
"GET http://address:port/". The ACL allows you to filter on the address
and port.
- Robert Tsai's support for logging to a UNIX socket (such as /dev/log).
Many people don't like to start a local UDP syslog server. I was not
fond of /dev/log because of chroots which cannot access it, but there
are several syslog servers which have no problem stuffing additional
sockets inside those chroots. With this, it makes a lot more sense to
support logging via a UNIX socket. Ironically, I observed log drops
on medium loads due to the fact that the syslogd was not scheduled
often enough to flush the socket buffer. It looks like UDP buffers are
bigger. For this reason, I will implement a user-sizable log buffer.
- slowstart parameter for servers so that the load ramps up slowly
after a failure. Both maxconn and its weight are modulated, so that
the load increases smoothly. This does not apply when haproxy has
just been started, it's only when a server has been seen down.
- new graceful shutdown with "http-check disable-on-404" to take a
server out. It allows one to remove a checked file from the server
so that it's seen as "in maintenance" and does not get new traffic.
When the server is finally stopped, no alert is sent, only a warning
because the operation was planned.
- url_param balance method. Hash on a specific parameter in the requested
URL. This can be used to track user ID and always send it to the same
server for instance.
- numeric pid/proxy/server IDs in the CSV stats (useful for SNMP). It was
far from easy to convert CSV stats to SNMP. With this, it's better because
reading those IDs indicate what is read.
- new "nbsrv" ACL verb to count available servers in a backend. It permits
to put conditions on actions based on the number of usable servers in a
backend. This can be used to build backup groups.
- add "fail" condition to "monitor" request. It's possible to return 503
instead of 200 if the condition is met. With this, we could make the
service's IP address disappear in a BGP table when too many servers
were down (using nbsrv). This is very useful to build multi-site
architectures.
- support for time units in timeouts, such as 5s, 10m or 3h. People get
bored to enter timeouts in milliseconds for large values. Now all units
from the microsecond to the day are available. Default remains unchanged
of course.
- new "timeout" keyword to individually set all timeouts, including
queue and tarpit. Previously it was not possible to specify the queue
or tarpit timeouts without acting on the contimeout. Also, it was not
always very convenient to manipulate those names. The "timeout" keyword
makes it nicer as it's followed by the name of the entity which will be
configured (eg: "queue", "connect", "client", "tarpit", "server", ...)
- fixes and restrictions to the the character set of proxies, servers
and ACL names. Any character was possible in proxies/servers/ACL names,
leading to a lot of confusion and even trouble analysing reporting (eg:
problems in logs if the server name contained a slash, or problems in
the CSV stats if it contained a comma). Now it's simpler: only alphanum,
and the classical "-", "_", "." and a few other characters are permitted.
Other ones will complain.
- a few more hints to help fix wrong configurations by associating hints
to the warnings. Today I checked that old 1.1 versions with large numbers
of listen entries (400+) still worked, and I was happy to find a few
warnings about copy-paste errors that 1.1 had not caught :-)
- new fields in the stats, including per-server total downtime, and
the number of sessions assigned to a server by the load balancing
algorithm (~= number of users). More and more people are using the
stats page as a centralized monitoring solution. It's important to
give them all the information they need.
- port to AIX 5.3 (at least builds and runs). I've been asked by AIX admins
if haproxy worked on AIX. I didn't know. Now I tested, fixed and know it
works :-)
- R.I. Pienaar's fix to the RH init script. The status function would never
return OK.
- Prizee's monitoring script for the unix socket. Useful for instantaneous
monitoring from the command line.
- many many cleanups, several optimizations, bugs fixed, ... as usual.
Wow. Finished. I've built it on linux, freebsd, openbsd, solaris/sparc and
AIX, but only tested it on the 3 former ones as of now. As usual, Linux and
Solaris executables are provided on the site next to the sources :
http://haproxy.1wt.eu/download/1.3/src/
http://haproxy.1wt.eu/download/1.3/bin/
Please test it, beat it, I'm quite confident in this version. I already
expect a .1 sub-version with a more complete documentation, but I have
no timing for this yet. Of course, problem reports are welcome !
On another subject, I'm pleased to announce that a maker of 10 Gig NICs
kindly offered to send me several ones for free as a contribution to
facilitate architectural optimizations to achieve even higher performance
(I will not give more info before getting the NICs, because in the event
that for any reason they finally couldn't send them, it would injustly
make bad publicity to them). So, expect new benchmarks soon, stay tuned !
Have fun,
Willy
Received on 2007/12/06 23:31