In r1899885 the test checks on dynamic child behaviour on a graceful reload.
Is this a setup that allows us to verify behaviour that troubled us in the past? Cheers, Stefan > Am 15.04.2022 um 10:41 schrieb Stefan Eissing <ste...@eissing.org>: > > > >> Am 14.04.2022 um 17:54 schrieb Yann Ylavic <ylavic....@gmail.com>: >> >> On Thu, Apr 14, 2022 at 1:43 PM Stefan Eissing <ste...@eissing.org> wrote: >>> >>> >>> In test/modules/core/test_002_restarts.py there is now a start of this. >>> Invoked >>> specifically with: >>> >>> trunk> STRESS_TEST=1 pytest -vvv -k test_core_002 >> >> Thanks for writing this! >> >>> >>> this uses the config given and runs h2load with 6 clients, each using 5 >>> connections >>> over time to perform a number of total requests. Number of clients easily >>> tweakable. >> >> I saw h2load issue up to 12 connections with this configuration, so >> raised the MPM limits a bit in r1899862 to avoid failing on >> "MaxRequestWorkers reached" in the logs. > > It may not be totally exact in its limiting or you may have counted lingering > connections? > >>> >>> The test in its current form fail, bc it expects all requests to succeed. >>> However, h2load >>> counts the remaining requests on a connection unsuccessful if the server >>> closes. So, maybe >>> we should use another test client or count 'success' differently. >> >> It passes for me currently with the new MPM limits, probably because >> kept-alive connections are not killed anymore. >> >>> >>> Anyway, in test/gen/apache/logs/error_log one can see how mpm_event hits it >>> limits >>> on workers and concurrent connections. Like >>> >>> " All workers are busy or dying, will shutdown 1 keep-alive connections" >>> or "AH03269: Too many open connections (1), not accepting new conns in this >>> process" >>> >>> So, we need to define how we measure `success` and what we expect/not >>> expect to see >>> in the error log. I guess? >> >> I'm not sure what we want to test here, the limits or the restart? >> I thought it was the latter as a first step, but yes if we want to >> test the former we need to either disable keepalive to avoid confusing >> h2load or use another (dedicated?) client more tolerant on how we may >> early close kept-alive connections. > > This initial version was just a test balloon. I think we want to test > the dynamic behaviour of mpm_event in regard to child processes and > restarts. I'll take a stab on changing it for this. > >> Measuring how we behave at the limits may also be tricky, what would >> be the expectations? No unhandled connections? A minimal latency? Or? >> That may depend on the running machine too.. >> >> If we want to test the reload, we don't need to stress too much (just >> some active connections for each generation), but we need something >> that "-k restart" and/or "-k restart" in parallel and counts the >> processes or the "Child <slot> started|stopped: pid=<pid>" in the >> logs. >> >> >> Cheers; >> Yann.
