Re: core.sleep() ignores param and sleeps for 10 seconds in response action
thank you for the explanation. On 10.11.2017 19:28, Willy Tarreau wrote: > On Fri, Nov 10, 2017 at 07:05:39PM +0200, Nick Dimov wrote: >> For example, I use a backend like this >> >>> backend b_http_hosts >>> mode http >>> >>> server s_web1 server:80 maxconn 10 check >> And I'm testing with wrk -c 20 and checking the established connections >> from haproxy to apache (with netstat), and that number is always equal >> to what i specify in -c param for wrk. >> >> It's worth mentioning that it respects the number of simultaneous >> requests (i checked that specifically) but is this behavior normal? Is >> it ok that it creates more connections than specified in maxconn ? > Yes, it's expected as soon as you have enabled keep-alive on the backend. > Counting the number of idle connections in the limit would be counter- > productive and even prevent new requests from being served while some > idle connections remain. In the end, since most servers have accept queues > and dispatch requests to threads, it makes more sense to only count what > really matters, ie outstanding requests. However if you enable connection > sharing using "http-reuse", you'll see that the number of outstanding > requests is much closer to the number of connections. > > Regards > Willy
Re: core.sleep() ignores param and sleeps for 10 seconds in response action
Hi again, Since I'm still on this, I'm having another possible issue with haproxy. The documentation states: > When a server has a > "maxconn<https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#>" > parameter specified, it means that its number > of concurrent connections *will never go higher*. But in my experiments, the haproxy creates more connections to the backend than specified in maxconn. For example, I use a backend like this > backend b_http_hosts > mode http > > server s_web1 server:80 maxconn 10 check And I'm testing with wrk -c 20 and checking the established connections from haproxy to apache (with netstat), and that number is always equal to what i specify in -c param for wrk. It's worth mentioning that it respects the number of simultaneous requests (i checked that specifically) but is this behavior normal? Is it ok that it creates more connections than specified in maxconn ? Regards, Nick. On 10.11.2017 18:57, Willy Tarreau wrote: > On Fri, Nov 10, 2017 at 06:43:42PM +0200, Nick Dimov wrote: >> Hello, >> >> The patch works great. I tested on 1.8 and 1.7 and both are working good >> now. > thanks for confirming! > > Willy
Re: core.sleep() ignores param and sleeps for 10 seconds in response action
Hello,
The patch works great. I tested on 1.8 and 1.7 and both are working good
now.
Thanks a lot!
On 10.11.2017 18:20, Willy Tarreau wrote:
> Hello Nick,
>
> On Fri, Nov 10, 2017 at 04:50:37PM +0200, Nick Dimov wrote:
>> Hello, everyone.
>>
>> I am encountering a problem with LUA in haproxy, I also reported it here
>> https://github.com/sflow/haproxy/issues/2 but the problem is lieke this:
>>
>> When using a response action, this function - sleeps for 10 seconds, no
>> matter what param i pass to it. Also it seems that the wait time always
>> equals timeout connect. The sample config is:
>>
>> global
>> daemon
>> log /dev/log local6
>> lua-load /etc/haproxy/delay.lua
>>
>> defaults
>> mode http
>> timeout connect 1ms
>>
>> frontend fe
>> bind *:80
>> mode http
>> default_backend b_http_hosts
>>
>> backend b_http_hosts
>> mode http
>> http-response lua.delay_response
>> server s_web1 server:80 check
>>
>> and the LUA code:
>>
>> function delay_response(txn)
>> core.msleep(1)
>> end
>>
>> core.register_action("delay_response", {"tcp-res", "http-res" },
>> delay_response);
>>
>> Note that if core.msleep() is commented out - everything works as expected.
>>
>> I tested version 1.6 (it hangs 30 seconds there), 1.7 - matches timeout
>> connect, and 1.8 - same as 1.7.
>>
>> Any idea how to overcome this problem? All i need is to delay the
>> responses based on information from backend header.
> I've checked and in fact it's been like this forever, it's just that Lua
> uncovered it :-) Basically the response analyse timeout was never handled
> in process_stream().
>
> I've just fixed it upstream now and verified that your example above
> correctly pauses for delays smaller than the connect timeout.
>
> You can apply the attached patch, it should work on 1.7 as well.
>
> Thanks for reporting this!
> Willy
core.sleep() ignores param and sleeps for 10 seconds in response action
Hello, everyone.
I am encountering a problem with LUA in haproxy, I also reported it here
https://github.com/sflow/haproxy/issues/2 but the problem is lieke this:
When using a response action, this function - sleeps for 10 seconds, no
matter what param i pass to it. Also it seems that the wait time always
equals timeout connect. The sample config is:
global
daemon
log /dev/log local6
lua-load /etc/haproxy/delay.lua
defaults
mode http
timeout connect 1ms
frontend fe
bind *:80
mode http
default_backend b_http_hosts
backend b_http_hosts
mode http
http-response lua.delay_response
server s_web1 server:80 check
and the LUA code:
function delay_response(txn)
core.msleep(1)
end
core.register_action("delay_response", {"tcp-res", "http-res" },
delay_response);
Note that if core.msleep() is commented out - everything works as expected.
I tested version 1.6 (it hangs 30 seconds there), 1.7 - matches timeout
connect, and 1.8 - same as 1.7.
Any idea how to overcome this problem? All i need is to delay the
responses based on information from backend header.
Reegards!
