You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David kerber <dc...@verizon.net> on 2015/11/02 13:56:38 UTC
Re: [OT] RE: 80ms delay switching between worker threads
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
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Farzad Panahi <fa...@gmail.com>.
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 <dc...@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
Re: [OT] RE: 80ms delay switching between worker threads
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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 <dc...@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
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Farzad Panahi <fa...@gmail.com>.
Chris - I am running a mac book pro. I will try to setup a simple test
case when I get a chance and post the results.
On Wed, Nov 4, 2015 at 11:54 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Farzad,
>
> On 11/3/15 2:45 PM, Farzad Panahi wrote:
>> I wish I could get my hands on a real server : )
>
> What computer do you use to access the server? That one will certainly
> work for this kind of testing.
>
> -chris
>
>> On Mon, Nov 2, 2015 at 12:23 PM, David kerber <dc...@verizon.net> 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.
>>>
>>>
>>>
>>>>
>>>> Cheers
>>>>
>>>> Farzad
>>>>
>>>> On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dc...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Farzad,
On 11/3/15 2:45 PM, Farzad Panahi wrote:
> I wish I could get my hands on a real server : )
What computer do you use to access the server? That one will certainly
work for this kind of testing.
-chris
> On Mon, Nov 2, 2015 at 12:23 PM, David kerber <dc...@verizon.net> 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.
>>
>>
>>
>>>
>>> Cheers
>>>
>>> Farzad
>>>
>>> On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dc...@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
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Farzad Panahi <fa...@gmail.com>.
I wish I could get my hands on a real server : )
On Mon, Nov 2, 2015 at 12:23 PM, David kerber <dc...@verizon.net> 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.
>
>
>
>>
>> Cheers
>>
>> Farzad
>>
>> On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dc...@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
Re: [OT] RE: 80ms delay switching between worker threads
Posted by David kerber <dc...@verizon.net>.
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.
>
> Cheers
>
> Farzad
>
> On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dc...@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
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Farzad Panahi <fa...@gmail.com>.
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.
Cheers
Farzad
On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dc...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org