tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Farzad Panahi <farzad.pan...@gmail.com>
Subject Re: [OT] RE: 80ms delay switching between worker threads
Date Tue, 03 Nov 2015 19:45:20 GMT
That's correct André. That is my point.

On Tue, Nov 3, 2015 at 8:18 AM, André Warnier (tomcat) <aw@ice-sa.com> wrote:
> On 02.11.2015 21:23, David kerber wrote:
>>
>> On 11/2/2015 3:09 PM, Farzad Panahi wrote:
>>>
>>> Quoting from David Holme's blog:
>>>
>>>> The nanoTime method uses the highest resolution clock available on the
>>>> platform, and
>>>> while its return value is in nanoseconds, the update resolution is
>>>> typically only
>>>> microseconds.
>>>
>>> https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks
>>>
>>> I think we can rely on nanoTime as a clock with microsecond
>>> resolution. Having said that can't we say printing out nanoTime in
>>> websocket message handler will give us a fair number (with microsecond
>>> accuracy) to measure how quickly the message handler is being called?
>>>
>>> All I am saying is that I see an obvious hiccup in order of
>>> milliseconds when threads are switching which I have no explanation
>>> for.
>>>
>>> Please advise if you think the way I am measuring is wrong.
>>
>>
>> I'm with Chris on this one:  I think it's due to running on a VM rather
>> than on real
>> hardware.
>
>
> I am no specialist in the matter, but I believe that what the OP is saying,
> is that there is a clear and systematic difference between 2 cases :
> - when the threads are switching
> - versus when they are not switching
> If so, and assuming that his measurements use the same method and
> instruments in each case, statistically-speaking there would still be an as
> yet unexplained difference, no ?
> (even if it is only a blink of an eye, repeated blinks can amount to
> something significant)
>
>
>
>
>>
>>
>>>
>>> Cheers
>>>
>>> Farzad
>>>
>>> On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dckerber@verizon.net>
>>> wrote:
>>>>
>>>> On 10/31/2015 10:51 AM, David Balažic wrote:
>>>>>
>>>>>
>>>>> Just a note: When most of you say "resolution" what you think about is
>>>>> actually called "accuracy".
>>>>> (also see "precision" , here is a good roundup:
>>>>> http://www.tutelman.com/golf/measure/precision.php )
>>>>
>>>>
>>>>
>>>> I'm not sure about the others, but as an Electrical Engineer, I know the
>>>> difference between resolution, precision, and accuracy.  In the post I
>>>> made
>>>> earlier, I said and meant "resolution".
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> David Balažic
>>>>> Software Engineer
>>>>> www.comtrade.com
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Konstantin Preißer [mailto:kpreisser@apache.org]
>>>>>> Sent: 31. October 2015 10:27
>>>>>> To: Tomcat Users List
>>>>>> Subject: [OT] RE: 80ms delay switching between worker threads
>>>>>> Importance: Low
>>>>>>
>>>>>> Hi Christopher,
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>>>>>>> Sent: Saturday, October 31, 2015 3:43 AM
>>>>>>>
>>>>>>> What OS are you using? IIRC, the Windows timer has horrible
>>>>>>> resolution.
>>>>>>> you can call System.currentTimeNanos all you want, but you won't
get
>>>>>>> anything meaningful lower than some threshold regardless of the
>>>>>>> actual
>>>>>>> least significant digits coming back from those calls.
>>>>>>
>>>>>>
>>>>>>
>>>>>> While that may have been true in ancient versions like XP and Vista,
>>>>>> at
>>>>>> least
>>>>>> starting with Win7 QueryPerformanceCounter() uses the processor's
TSC
>>>>>> [1]
>>>>>> (where Vista used the HPET if available) so you should have a very
>>>>>> high
>>>>>> resolution here. E.g. running the following Java program:
>>>>>>
>>>>>>       int[] iterations = { 100, 120, 150, 250 };
>>>>>>
>>>>>>       for (int i = 0; i < iterations.length; i++) {
>>>>>>           for (int j = 0; j < 3; j++) {
>>>>>>               long currentTime = System.nanoTime();
>>>>>>               double startValue = 1000;
>>>>>>               for (int z = 0; z < iterations[i]; z++) {
>>>>>>                   startValue = Math.pow(startValue, 0.99);
>>>>>>               }
>>>>>>               long difference = System.nanoTime() - currentTime;
>>>>>>               System.out.println(iterations[i] + " pow iterations
ms
>>>>>> took
>>>>>> " +
>>>>>> (difference / 1000L) + " µs");
>>>>>>           }
>>>>>>       }
>>>>>>
>>>>>> prints on my system something like:
>>>>>>
>>>>>> 100 pow iterations ms took 25 µs
>>>>>> 100 pow iterations ms took 7 µs
>>>>>> 100 pow iterations ms took 7 µs
>>>>>> 120 pow iterations ms took 8 µs
>>>>>> 120 pow iterations ms took 9 µs
>>>>>> 120 pow iterations ms took 8 µs
>>>>>> 150 pow iterations ms took 11 µs
>>>>>> 150 pow iterations ms took 10 µs
>>>>>> 150 pow iterations ms took 13 µs
>>>>>> 250 pow iterations ms took 18 µs
>>>>>> 250 pow iterations ms took 17 µs
>>>>>> 250 pow iterations ms took 17 µs
>>>>>>
>>>>>>
>>>>>> So there should at least be a microsecond resolution. On a C# program
>>>>>> using
>>>>>> Stopwatch I get similar results in the range from 5 to 12 µs.
>>>>>>
>>>>>> Note, QueryPerformanceFrequency() [2] can be used to get the frequency
>>>>>> of the timer which is exposed in .Net through static
>>>>>> System.Diagnostics.Stopwatch.Frequency field as ticks per second.
On
>>>>>> my
>>>>>> system it prints "3323580" so the resolution should be around ~0.3
>>>>>> microseconds.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Konstantin Preißer
>>>>>>
>>>>>> [1] https://msdn.microsoft.com/en-
>>>>>> us/library/windows/desktop/dn553408%28v=vs.85%29.aspx
>>>>>> [2] https://msdn.microsoft.com/de-
>>>>>> de/library/windows/desktop/ms644905%28v=vs.85%29.aspx
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

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


Mime
View raw message