Hello Luca,

It’s a problem with the limited fifo queue size of http2.

Stefan send me a workaround not sure if this one will go into http2 or if he 
will release a real fix soon.

Greets,
Stefan

Excuse my typo sent from my mobile phone.

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

Reply via email to