Hi Hajo,

2018-02-01 3:58 GMT+01:00 Luca Toscano <toscano.l...@gmail.com>:

> Hi Hajo,
> 2018-01-31 2:37 GMT-08:00 Hajo Locke <hajo.lo...@gmx.de>:
>> Hello,
>> Am 22.01.2018 um 11:54 schrieb Hajo Locke:
>> Hello,
>> Am 19.01.2018 um 15:48 schrieb Luca Toscano:
>> Hi Hajo,
>> 2018-01-19 13:23 GMT+01:00 Hajo Locke <hajo.lo...@gmx.de>:
>>> Hello,
>>> thanks Daniel and Stefan. This is a good point.
>>> I did the test with a static file and this test was successfully done
>>> within only a few seconds.
>>> finished in 20.06s, 4984.80 req/s, 1.27GB/s
>>> requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0
>>> failed, 0 errored, 0 timeout
>>> so problem seems to be not h2load and basic apache. may be i should look
>>> deeper into proxy_fcgi configuration.
>>> php-fpm configuration is unchanged and was successfully used with
>>> classical fastcgi-benchmark, so i think i have to doublecheck the proxy.
>>> now i did this change in proxy:
>>> from
>>> enablereuse=on
>>> to
>>> enablereuse=off
>>> this change leads to a working h2load testrun:
>>> finished in 51.74s, 1932.87 req/s, 216.05MB/s
>>> requests: 100000 total, 100000 started, 100000 done, 100000 succeeded, 0
>>> failed, 0 errored, 0 timeout
>>> iam surprised by that. i expected a higher performance when reusing
>>> backend connections rather then creating new ones.
>>> I did some further tests and changed some other php-fpm/proxy values,
>>> but once "enablereuse=on" is set, the problem returns.
>>> Should i just run the proxy with enablereuse=off? Or do you have an
>>> other suspicion?
>> Before giving up I'd check two things:
>> 1) That the same results happen with a regular localhost socket rather
>> than a unix one.
>> I changed my setup to use tcp-sockets in php-fpm and proxy-fcgi.
>> Currently i see the same behaviour.
>> 2) What changes on the php-fpm side. Are there more busy workers when
>> enablereuse is set to on? I am wondering how php-fpm handles FCGI requests
>> happening on the same socket, as opposed to assuming that 1 connection == 1
>> FCGI request.
>> If "enablereuse=off" is set i see a lot of running php-workerprocesses
>> (120-130) and high load. Behaviour is like expected.
>> When set "enablereuse=on" i can see a big change. number of running
>> php-workers is really low (~40). The test is running some time and then it
>> stucks.
>> I can see that php-fpm processes are still active and waiting for
>> connections, but proxy_fcgi is not using them nor it is establishing new
>> connections. loadavg is low and benchmarktest is not able to finalize.
>> I did some further tests to solve this issue. I set ttl=1 for this Proxy
>> and achieved good performance and high number of working childs. But this
>> is paradoxical.
>> proxy_fcgi knows about inactive connection to kill it, but not reenable
>> this connection for working.
>> May be this is helpful to others.
>> May be a kind of communicationproblem and checking health/busy status of
>> php-processes.
>> Whole proxy configuration is  this:
>> <Proxy "unix:/dev/shm/php70fpm.sock|fcgi://php70fpm">
>>     ProxySet enablereuse=off flushpackets=On timeout=3600 max=15000
>> </Proxy>
>> <FilesMatch \.php$|\.php70$>
>>    SetHandler "proxy:fcgi://php70fpm"
>> </FilesMatch>
> Thanks a lot for following up and reporting these interesting results!
> Yann opened a thread[1] on dev@ to discuss the issue, let's follow up in
> there so we don't keep two conversations open.
> Luca
> [1]: https://lists.apache.org/thread.html/a9586dab96979bf45550c9714b36c4
> 9aa73526183998c5354ca9f1c8@%3Cdev.httpd.apache.org%3E
reporting in here what I think it is happening in your test environment
when enablereuse is set to on. Recap of your settings:

StartServers          10
MaxClients          500
MinSpareThreads      450
MaxSpareThreads      500
ThreadsPerChild      150
MaxRequestsPerChild   0
Serverlimit 500

<Proxy "unix:/dev/shm/php70fpm.sock|fcgi://php70fpm/">
    ProxySet enablereuse=on flushpackets=On timeout=3600 max=1500
<FilesMatch \.php$|\.php70$>
   SetHandler "proxy:fcgi://php70fpm/"

request_terminate_timeout = 7200
listen = /dev/shm/php70fpm.sock
pm = ondemand
pm.max_children = 500
pm.max_requests = 2000

By default mod_proxy allows a connection pool of ThreadsPerChild
connections to the backend for each httpd process, meanwhile in your case
you have set 3200 using the 'max' parameter (as stated in the docs it is a
per process setting, not a overall one). PHP-FPM handles one connection for
each worker at the time, and your settings allow a maximum of 500
processes, therefore a maximum of 500 connections established at the same
time from httpd. When connection reuse is set to on, the side effect is
that for each mod_proxy's open/established connection in the pool there
will be one PHP-FPM worker tight to it, even if not serving any request
(waiting for one basically). This can lead to a situation in which all
PHP-FPM workers are "busy" not allowing mod_proxy to create more
connections (even if it is set/allowed to do so) leading to a stall that
finishes only if one PHP-FPM worker is freed (Timeout/ProxyTimeout or 'ttl'
elapsed for example).

If you have time and patience could you re-try your tests with different
settings in light of what said above and see if the weird slowdown/stall
issue goes away?

I am planning to update the docs to reflect this use case!



Reply via email to