tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Bug that spans tomcat and tomcat-native
Date Fri, 24 Jun 2016 17:27:16 GMT
On 24/06/2016 18:25, Mark Thomas wrote:
> On 24/06/2016 18:11, therealneworld@gmail.com wrote:
>> On Fri, Jun 24, 2016 at 11:18 AM, Mark Thomas <markt@apache.org> wrote:
>>> On 24/06/2016 11:17, Rémy Maucherat wrote:
>>>> 2016-06-24 12:08 GMT+02:00 Mark Thomas <markt@apache.org>:
>>>>
>>>>> Thanks.
>>>>>
>>>>> I'm going to start some local performance testing to confirm I see
>>>>> similar results and, assuming I do, I'll start looking at fixing this
>>>>> for 1.2.x/9.0.x and back-porting.
>>>>>
>>>> Hum, the fix that was submitted doesn't make sense IMO since writes can be
>>>> async, so I don't see a way besides adding the "error clear" thing after
>>>> each operation [and we'll remove it once OpenSSL 1.1 is there if it
>>>> actually fixes it]. That's assuming this issue is real [I actually never
>>>> noticed anything during my many ab runs and they use a lot of threads, so
I
>>>> have a hard time believing it is significant enough ;) ].
>>>
>>> I haven't been able to reproduce anything like this yet. So far I have
>>> only been testing with tc-native 1.2.x and Tomcat 9.0.x. I might need to
>>> test with 1.1.x and Tomcat 7.0.x, the versions used by the OP.
>>>
>>> I'm having trouble understanding how this is happening. I could imagine
>>> that HashMap becoming a problem if there was a high churn in Threads.
>>> I'm thinking of something like bursty traffic levels and an executor
>>> aggressively halting spare threads. I need to experiment with that as well.
>>>
>>
>> I do not understand it either. Using the thread pool there is not much
>> thread churn so I am not sure why the problem gets as bad as it does.
>> I didn't look into what the hash table actually had in it. I just
>> noticed that the majority of a read threads time was spent waiting for
>> the lock to access this hash table. Once I added the call to
>> ERR_remove_thread_state the waiting basically disappeared.
>>
>> For this test the traffic is constant. Each client thread creates one
>> connection and just keeps pushing requests for set number of requests,
>> so we aren't even creating new connections.
> 
> Can you provide the settings you are using for the Executor as well please?

And how long do the initial 5,000,000 4k requests take to process?

Thanks,

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message