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

Reply via email to