b.t.w. if sole purpose of the frontend is to echo the ip back to the client.
You should probably also check the 'use-service' applet syntax, i dont know if that could be faster for your purpose. Then another thing to check would be if you want to use the tcp or http service mode. A TCP service could be almost 1 line of lua code.. And i kinda expect to be a bit faster.

http://www.arpalert.org/src/haproxy-lua-api/1.6/index.html#haproxy-lua-hello-world
Instead of sending 'hello world' you could send the client-ip..

Op 10-11-2015 om 23:46 schreef Thrawn:
OK, some explanation seems in order :).

I ran ab with concurrency 1000 and a total of 30000 requests, against each server, 5 times, plus one run each with 150000 requests (sum of the previous 5 tests). For Apache+PHP, this typically resulted in 5-15ms response time for 99% of requests, with the remaining few either taking tens of seconds or eventually disconnecting with an error. For HAProxy+Lua, 99% response times were 1ms, or sometimes 2ms, with the last few taking about 200ms. So, HAProxy worked much better (of course).

However, on the larger run (150k), HAProxy too had a small percentage of disconnections (apr_socket_recv: Connection reset by peer). I've been able to reproduce this with moderate consistency whenever I push it beyond about 35000 total requests. It's still a better error rate than PHP, but I'd like to understand why the errors are occurring. For all I know, it's a problem with ab.

I've also tried a couple of runs with 150000 requests but concurrency only 100, and neither server had trouble serving that, although interestingly, PHP is slightly more consistent: 99% within 4-5ms, then about 200ms for the last few, whereas HAProxy returns 99% within 1-2ms and 1800ms for the last few.

The box is just my workstation, 8 cores and 16GB RAM, running Ubuntu 15.10, with no special tuning.

Any ideas on why the HAProxy tests showed disconnections or occasional slow response times at high loads?



On Wednesday, 11 November 2015, 8:29, Baptiste <bed...@gmail.com> wrote:


On Tue, Nov 10, 2015 at 10:46 PM, Thrawn
<shell_layer-git...@yahoo.com.au <mailto:shell_layer-git...@yahoo.com.au>> wrote:
> OK, I've set this up locally, and tested it against PHP using ab.
>
> HAProxy was consistently faster (99% within 1ms, vs 5-15ms for PHP), but at > request volumes over about 35000, with concurrency 1000, it consistently had > a small percentage of socket disconnections. PHP had timeouts - or very long > response times - and disconnections at pretty much any request volume with > that concurrency, but I'm wondering where the errors stem from, or even if
> it's a limitation of ab.
>
> HAProxy config:
>
> global
>    maxconn 4096
>    daemon
>    nbproc 1
>    stats socket localhost:9461 level admin
>    chroot /etc/haproxy/jail
>    user haproxy
>    group haproxy
>    lua-load /etc/haproxy/jail/echo.lua
>
> defaults
>    log 127.0.0.1 local0
>    mode http
>    timeout client 60000
>    timeout server 60000
>    timeout connect 60000
>    option forwardfor
>    balance roundrobin
>    option abortonclose
>    maxconn 20
>
> frontend echo
>    bind 127.0.1.1:1610
>    timeout client 10000
>    mode http
>    http-request lua.echo
>
> Lua:
> core.register_action("echo", { "http-req" }, function (txn)
>    local buffer = txn.f:src()
>    txn.res:send("HTTP/1.0 200 OK\r\nServer:
> haproxy-lua/echo\r\nContent-Type: text/html\r\nContent-Length: " ..
> buffer:len() .. "\r\nConnection: close\r\n\r\n" .. buffer)
>    txn:done()
> end)
>

Hi Thrawn

I'm sorry, but I don't understand anything to all your benchmarcks!
If you could at least give an explanation  before running each ab,
this may help.

Furthermore, you don't share anything about your hardware environment
neither the tuning you did on each box.
So it's impossible to help you.

At least, I can say that Lua seems to perform very well :)

Baptiste



Reply via email to