The fix went into trunk as r1816619 and in 2.4.x as r1816969 in 2.4.x. Cheers,
Stefan > Am 02.12.2017 um 09:23 schrieb Luca Toscano <toscano.l...@gmail.com>: > > Hi everybody, > > did I miss an update or are we still waiting for more data? (Don't mean to > rush you Stefan, just to understand what's the status of the thread :) > > Luca > > 2017-11-24 15:26 GMT+01:00 Stefan Priebe - Profihost AG > <s.pri...@profihost.ag>: > Thanks i‘ll post a log tonight with a 120s stalled request. > > Greets, > Stefan > > Excuse my typo sent from my mobile phone. > > Am 23.11.2017 um 17:09 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>: > >> Hey, >> >> could you try the patch below and produce such a lovely log file again? >> H2MaxWorkers please back to before, unconfigured. Thanks! This is a small >> change that a) logs the interaction with h2_workers a bit more and makes >> sure that time gets lost where I think it does. It also switches the fifo >> queue in set mode where duplicate entries are checked, in case that >> interferes here. >> >> Cheers, >> >> Stefan >> >> <h2worker_register-v0.diff> >> >> >>> Am 23.11.2017 um 14:16 schrieb Stefan Priebe - Profihost AG >>> <s.pri...@profihost.ag>: >>> >>> Hi, >>> Am 23.11.2017 um 14:10 schrieb Stefan Eissing: >>>> Interesting. I assume that otherwise this host is the same (OS/CPU etc.) >>>> as others where it runs without probs? >>> >>> Yes and no i got some more reports by colleagues where they've disabled >>> http2 as the customers had unexpected long loading times. >>> >>>> We are not ghosted by some strange blabla-lake hyper threading thingie >>>> singularity? >>> >>> Huhoh what's that? Any chance to add some more debugging? >>> >>> Greets, >>> Stefan >>> >>>> >>>> Need to think about this. >>>> >>>>> Am 23.11.2017 um 13:43 schrieb Stefan Priebe - Profihost AG >>>>> <s.pri...@profihost.ag>: >>>>> >>>>> *argh*, i was too fast no it did NOT fix the problem. It even happens >>>>> with: >>>>> H2MaxWorkers 4096 >>>>> >>>>> Sorry about that. >>>>> >>>>> Stefan >>>>> >>>>> Am 23.11.2017 um 13:42 schrieb Stefan Priebe - Profihost AG: >>>>>> Hello,, >>>>>> >>>>>> setting: >>>>>> H2MaxWorkers 1024 >>>>>> >>>>>> fixes the issue for me. The main problem is how to i know how many >>>>>> workers are needed? How can i detect whether all workers of h2 are busy? >>>>>> >>>>>> Stefan >>>>>> >>>>>> Am 22.11.2017 um 13:23 schrieb Stefan Priebe - Profihost AG: >>>>>>> Hell Stefan, >>>>>>> >>>>>>> will send a log to you in a few seconds via private email. >>>>>>> >>>>>>> Greets, >>>>>>> Stefan >>>>>>> >>>>>>> Am 21.11.2017 um 23:18 schrieb Stefan Eissing: >>>>>>>> sorry for the late reply. for stucks trace2 is best. >>>>>>>> >>>>>>>>> Am 21.11.2017 um 19:35 schrieb Stefan Priebe - Profihost AG >>>>>>>>> <s.pri...@profihost.ag>: >>>>>>>>> >>>>>>>>> Hello Stefan, >>>>>>>>> >>>>>>>>> which loglevel do you need? trace2? >>>>>>>>> >>>>>>>>> Greets, >>>>>>>>> Stefan >>>>>>>>> >>>>>>>>>> Am 21.11.2017 um 16:48 schrieb Stefan Eissing: >>>>>>>>>> Never done this, but https://www.howtoforge.com/setenvif_apache2 >>>>>>>>>> seems like one way to do make it work. >>>>>>>>>> >>>>>>>>>>> Am 21.11.2017 um 16:16 schrieb Stefan Priebe - Profihost AG >>>>>>>>>>> <s.pri...@profihost.ag>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Am 21.11.2017 um 16:06 schrieb Stefan Priebe - Profihost AG: >>>>>>>>>>>>> Am 21.11.2017 um 15:45 schrieb Stefan Eissing: >>>>>>>>>>>>> >>>>>>>>>>>>>> Am 21.11.2017 um 14:33 schrieb Stefan Priebe - Profihost AG >>>>>>>>>>>>>> <s.pri...@profihost.ag>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello Stefan, >>>>>>>>>>>>>> Hello Yann, >>>>>>>>>>>>>> >>>>>>>>>>>>>> me the http2 bug tester is calling again ;-) >>>>>>>>>>>>> >>>>>>>>>>>>> And the day was going so well... >>>>>>>>>>>> >>>>>>>>>>>> I'm sorry ;-) >>>>>>>>>>>> >>>>>>>>>>>>>> While running two bash curl while loops the one using http1.1 >>>>>>>>>>>>>> always >>>>>>>>>>>>>> finishes in < 0.05s while the http2 one takes sometimes 0.4 to >>>>>>>>>>>>>> 20s to >>>>>>>>>>>>>> finish. Sadly i can't reproduce this all the time - mostly more >>>>>>>>>>>>>> requests >>>>>>>>>>>>>> more failures. As this is a production server i've no idea how >>>>>>>>>>>>>> to debug >>>>>>>>>>>>>> as the http2 trace logs might flood the harddisk. >>>>>>>>>>>>> >>>>>>>>>>>>> Hmmm. Do you know if this happens waiting for a response or at >>>>>>>>>>>>> the end of a connection? Or in the middle of a body? All GETs or >>>>>>>>>>>>> also POSTs? >>>>>>>>>>>> >>>>>>>>>>>> My Test only contains GET - but most probably there are also >>>>>>>>>>>> running >>>>>>>>>>>> POST requests but not started by me. >>>>>>>>>>>> >>>>>>>>>>>> Strangely this only happens between 1pm and 2pm a day but i've no >>>>>>>>>>>> idea >>>>>>>>>>>> what's different at that time. >>>>>>>>>>> >>>>>>>>>>> OK i'm also able to reproduce this whenever your want. Can we >>>>>>>>>>> activate >>>>>>>>>>> trace logging for a specific IP? So i can generate a http2 log? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I can output a lot of information from curl: >>>>>>>>>>>> time_namelookup >>>>>>>>>>>> time_connect >>>>>>>>>>>> time_appconnect >>>>>>>>>>>> time_pretransfer >>>>>>>>>>>> time_redirect >>>>>>>>>>>> time_starttransfer >>>>>>>>>>>> >>>>>>>>>>>> Another way might be to enable trace logging only for "my" IP? Is >>>>>>>>>>>> something like this possible? >>>>>>>>>>>> >>>>>>>>>>>> Greets, >>>>>>>>>>>> Stefan >>>>>>>>>> >>>>>>>> >>>> >> >
