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 > > > > > >
