nice try ;-)
But some parts are not that bad, IMHO.
Am 01-04-2015 10:43, schrieb Willy Tarreau:
As some might have noticed, HAProxy development is progressively
down over time. I have analyzed the situation and came to the following
Recently with the Lua addition, we found it to be quite fast. Maybe not
as fast as C, but Lua is improving and C skills are diminishing, so I
guess that in a few years the code written in Lua will be much faster
than the code we'll be able to write in C. Thus I found it wise to
declare a complete rewrite of HAProxy in Lua. It comes with many
First, Lua is easy to learn, we'll get many more developers and
contributors. One of the reason is that you don't need to care about
resource allocation anymore. What's the benefit of doing an strdup() to
keep a copy of a string when you can simply do "a = b" without having
care about the memory used behind. Machines are huge nowadays, much
larger than the old Athlon XP I was using 10 years ago.
Second, Lua doesn't require a compiler, so we'll save 30 minutes a day
per 200 builds, this will definitely speed up development for each
developer. And we won't depend on a given C compiler, won't be subject
to its bugs, and more importantly we'll be able to get rid of the few
lines of assembly that we currently have in some performance-critical
Third, last version of HAProxy saw a lot of new sample fetch functions
and converters. This will not be needed anymore, because the code and
the configuration will be mixed together, just as everyone does with
Shell scripts. This means that any config will just look like an
directive for the haproxy code, followed by some code to declare the
configuration. It will then be possible to create infinite
of new functions, and the configuration will have access to anything
internal to HAProxy.
Sounds like mod_perl/mod_lua for apache or mod_lua for nginx.
I think it would be worth to check how much time costs to switch from
c to lua and back.
Looks like this questions is answerd.
1.8 Optimization tips?
6.1 LuaJIT is significantly faster than vanilla Lua. What's the catch?
But as every time then comes the Users and say haproxy is slow because
there LUA-Script is full of flaws ;-/
They should read http://www.luafaq.org/ before code *SHOULD*.
Who do what he/she should ;-)
In the end, of the current HAProxy will only remain the Lua engine, and
probably by then we'll find even better ones so that haproxy will be
distributed as a Lua library to use anywhere, maybe even on IoT devices
if that makes sense (anyone ever dreamed of having haproxy in their
From my point of view this was the funniest part ;-).
Say us good luck!