Author: markt
Date: Thu Jun 18 08:32:29 2009
New Revision: 785952
URL: http://svn.apache.org/viewvc?rev=785952&view=rev
Log:
Add some micro-benchmarks that enable the differences between the Sync and
ThreadLocal approach to be compared
Added:
tomcat/trunk/test/org/apache/catalina/valves/
2009/6/18 :
> Author: markt
> Date: Thu Jun 18 08:32:29 2009
> New Revision: 785952
>
> URL: http://svn.apache.org/viewvc?rev=785952&view=rev
> Log:
> Add some micro-benchmarks that enable the differences between the Sync and
> ThreadLocal approach to be compared
>
> Added:
> tomcat/trunk/test
I think this needs to be volatile ?
In (GetDateBenchmarkTest)
> +private long currentMillis = 0;
Same for (in TimeDateElementBenchmarkTest)
> +private Date currentDate = null;
Of course - since the test is single threaded - it doesn't really matter.
-Tim
ma...@apache.org wrote:
Tim Funk wrote:
> I think this needs to be volatile ?
> In (GetDateBenchmarkTest)
>> +private long currentMillis = 0;
>
> Same for (in TimeDateElementBenchmarkTest)
>> +private Date currentDate = null;
>
> Of course - since the test is single threaded - it doesn't really matter.
Konstantin Kolinko wrote:
> 2009/6/18 :
>> Author: markt
>> Date: Thu Jun 18 08:32:29 2009
>> New Revision: 785952
>>
>> URL: http://svn.apache.org/viewvc?rev=785952&view=rev
>> Log:
>> Add some micro-benchmarks that enable the differences between the Sync and
>> ThreadLocal approach to be compar
Mark, since each of your thread runs a TestThread which implements runnable,
those thread do not access the field or method of other threads, I do not
think the test is multi-threaded. You could use one or two
your BenchmarkTest class, and let more than more thread access its method
instead.
200
sorry, maybe I misunderstood your code, I'll recheck it.
2009/6/18 Xie Xiaodong
> Mark, since each of your thread runs a TestThread which implements
> runnable, those thread do not access the field or method of other threads, I
> do not think the test is multi-threaded. You could use one or two
On 18/06/2009, Mark Thomas wrote:
> Tim Funk wrote:
> > I think this needs to be volatile ?
> > In (GetDateBenchmarkTest)
> >> +private long currentMillis = 0;
> >
> > Same for (in TimeDateElementBenchmarkTest)
> >> +private Date currentDate = null;
> >
> > Of course - sinc
On 18/06/2009, sebb wrote:
> On 18/06/2009, Mark Thomas wrote:
> > Tim Funk wrote:
> > > I think this needs to be volatile ?
> > > In (GetDateBenchmarkTest)
> > >> +private long currentMillis = 0;
> > >
> > > Same for (in TimeDateElementBenchmarkTest)
> > >> +private
I think the entire Benchmark test is wrong.
I'm not sure what we are trying to do in this test, in my mind we are
proving nothing with this test :)
The thread safety in AccessLogValve is the fact that the formatters are
not thread safe and can yield some funky dates showing up.
And in the idea
Filip Hanik - Dev Lists wrote:
> I'm not sure what we are trying to do in this test, in my mind we are
> proving nothing with this test :)
The only purpose of the test is to provide a representative micro
benchmark of the current code vs your suggestion to use ThreadLocals
instead (in the 5.5.x pa
sebb wrote:
> Oops, forgot to mention - there are only 5 threads in the test; it
> might be useful to try tests with increasing numbers of threads to see
> if the relative numbers change.
I did (I used 50) and they get a little closer but not much.
I left it at 5 as that was my best WAG as to how
sebb wrote:
> If it is intended to allow currentDate to be updated by another thread
> before the return, then the field needs to be volatile. Otherwise the
> return value needs to be established in the synch. block.
It needs to be volatile. I ran some comparisons and the performance
difference ap
Mark,
I rewrote the benchmark to allow more than two implementations to be compared.
A test now implements Runnable and its toString() prints the variable
part of the message.
It was fun running these tests. I will detail my observations later.
My thought is that the main difference in time com
Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
I'm not sure what we are trying to do in this test, in my mind we are
proving nothing with this test :)
The only purpose of the test is to provide a representative micro
benchmark of the current code vs your suggestion to use ThreadLoca
Filip Hanik - Dev Lists wrote:
> Mark Thomas wrote:
>> I was a little surprised that ThreadLocal seems to be slower. I still
>> wonder if I got the test wrong for that but I can't see anything.
>>
> If it was me doing the date, and making it all threadlocal, with no
> global variables at all
> And
2009/6/19 Mark Thomas :
>
> I've made the changes you suggested and lo and behold the ThreadLocal is
> quicker.
>
>> testAccessLogGetDate: 16 threads and 1000 iterations using Syncs
>> took 7461ms
>> testAccessLogGetDate: 16 threads and 1000 iterations using
>> ThreadLocals took 6433ms
>
>
17 matches
Mail list logo
