2018-02-05 2:41 GMT+01:00 Eric Covener <cove...@gmail.com>:

> On Sun, Feb 4, 2018 at 8:27 PM, Luca Toscano <toscano.l...@gmail.com>
> wrote:
> > 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:
> >
> > /etc/apache2/conf.d/limits.conf
> > 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
> > </Proxy>
> > <FilesMatch \.php$|\.php70$>
> >    SetHandler "proxy:fcgi://php70fpm/"
> > </FilesMatch>
> >
> > 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).
>
> We should definitely spell out the impact of enablereuse on php-fpm
> specifically.
>
> I think one thing that is missing in the above recap is that w/o H2
> given MaxClients=500, the impact is probably nil because there are
> simply not enough server threads to max out the pool and still try to
> make new connections.
>
> With H2, you have N additional h2 worker threads per process, so it
> puts it as out of balance as if MaxClients were larger but
> pm.max_children were not.


This is a very good point Eric! Completely agree.

Luca

Reply via email to