tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <...@greenhydrant.com>
Subject Re: java Date related classes synchronization bottlenecks
Date Fri, 11 Jul 2003 01:52:31 GMT
On Thu, Jul 10, 2003 at 05:46:06PM -0500, Glenn Nielsen wrote:
> 
> Now use jar to unarchive the src.jar file in your java SDK.
> Take a look at the java.sql.Timestamp.toString() method which the FileLogger
> above uses.
> 
> To verify this look at the source for java.util.Date.getField().

Yes, that looks bad (looking at 1.4.2 src)!  It appears that avoiding calls to the
Timestamp.toString() is really to be avoided if possible.

> And there are many other synchronization bottlenecks in the following Date
> related classes:
> 
> java.util.Calendar.getInstance()
> java.util.Date
> java.util.TimeZone.getDefault()
> java.sql.Date
> java.sql.Time
> java.sql.Timestamp

I took a look at some of these, these don't appear to be as bad as the
Timestamp.toString().

I did a quick google of Date performance issues and didn't find
anything.  Is this a well known bottleneck in multi-threaded
applications?

>   > Does a simple test case which simply starts up a number of threads which
>   > all use one of the classes shown below display the problem nicely?
> 
> I am sure it would, I haven't had time to write one up yet.

I wrote a simple multithreaded program which makes calls to
Timestamp.toString() and varied the number of threads running and the
number of calls.  On a single CPU system (a Duron 600), scaling from
1-20 threads performed as I expected, with the 20 thread iteration
taking only slightly longer than the single thread iteration.  

However, when running this on a dual-cpu system (PIII 500), going from
1 to 2 treads took over twice as long for the same overall number of
calls to Timestamp.toString().  From 4-20 threads overall time
slightly increased most likely due to the overhead of scheduling
multiple threads.

You must be running on a multiple-CPU system as it doesn't appear to be
a bottle-neck (except for the fact that it's a slow operation) on a
single-cpu machine and only one multi-cpu machines.

Given that this is the case, a temporary fix in your case would be to
run as many Tomcat's as you have processors on that particular machine
(assuming you have enough memory)

-Dave

Mime
View raw message