Re: java Date related classes synchronization bottlenecks
David (this is weird its like having a conversation with myself) OK - here goes same machine / spec as before ... I must say that the linux box kicks some serious ass Sun box .. time java TestDatePerf 1 100 real2m29.685s user1m50.051s sys 0m0.343s time java TestDatePerf 2 100 real3m18.918s user2m43.431s sys 0m45.973s time java TestDatePerf 3 100 real4m4.658s user2m59.931s sys 1m21.882s time java TestDatePerf 4 100 real4m38.220s user3m4.771s sys 1m38.683s time java TestDatePerf 5 100 real4m35.668s user3m11.771s sys 1m58.093s time java TestDatePerf 6 100 real5m6.130s user3m21.621s sys 2m16.882s time java TestDatePerf 7 100 real4m41.621s user3m26.351s sys 2m22.363s Linux box time java TestDatePerf 1 100 real0m22.093s user0m21.640s sys 0m0.120s time java TestDatePerf 2 100 real0m59.431s user1m0.020s sys 0m26.020s time java TestDatePerf 3 100 real1m23.931s user1m11.000s sys 0m43.220s time java TestDatePerf 4 100 real1m27.331s user1m11.820s sys 0m43.930s time java TestDatePerf 5 100 real1m29.111s user1m8.940s sys 0m44.740s time java TestDatePerf 6 100 real1m27.971s user1m10.200s sys 0m45.620s time java TestDatePerf 7 100 real1m30.532s user1m10.340s sys 0m45.370s time java TestDatePerf 8 100 real1m30.701s user1m11.080s sys 0m44.770s time java TestDatePerf 9 100 real1m29.651s user1m13.360s sys 0m45.050s time java TestDatePerf 10 100 real1m29.771s user1m13.640s sys 0m43.940s "David Rees" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .com>cc: Subject: Re: java Date related classes synchronization bottlenecks 11/07/2003 16:34 Please respond to "Tomcat Developers List" David Cassidy said: > > I've done some tests with the below code > hope this helps David, Could you give this version a try, and run it for 1 million iterations instead of just 10k? I'll be posting my results shortly for a couple of different machines shortly. The new version keeps the theoretical overall run time constant by keeping the overall amount of work the same while you vary the thread count. So if you supply arguments 1 and 1 million, and then 2 and 1 million, in the first case 1 thread will go through 1 million iterations, in the second case each of the two threads will only go throgh 500,000 iterations. Saves you division. ;-) Glenn, it would be interesting for you to modify the code to remove the synchronization issue and then re-run the quick benchmark. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
On Fri, Jul 11, 2003 at 08:57:54AM -0700, David Rees wrote: > > System 4: > Dual Mips R10k 225MHz, SGI Java 1.4.1 SGI IRIX I was mistaken about the CPU freq of this machine, it really has 2 R10k 180MHz CPUs, not 225MHz. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
On Fri, Jul 11, 2003 at 10:10:21AM -0700, James Courtney wrote:
> I didn't see an attachment that time. Thanks as this is interesting
> stuff for Java development of any kind, not just Tomcat!
Stupid me. Is attached now.
-Dave
import java.sql.*;
import java.util.*;
public class TestDatePerf
extends Thread
{
int iterations;
Timestamp date = null;
public TestDatePerf(int iterations) {
this.iterations = iterations;
date = new Timestamp(System.currentTimeMillis());
}
public void run() {
for (int i = 0; i < iterations; i++) {
date.toString();
}
}
public static void main(String args[]) {
int threads = Integer.parseInt(args[0]);
int iterations = Integer.parseInt(args[1]);
for (int i = 0; i < threads; i++) {
TestDatePerf tdp = new TestDatePerf((int)iterations/threads);
tdp.start();
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: java Date related classes synchronization bottlenecks
David, I didn't see an attachment that time. Thanks as this is interesting stuff for Java development of any kind, not just Tomcat! Jamey James Courtney InPhonic, Inc. -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 8:34 AM To: [EMAIL PROTECTED] Subject: Re: java Date related classes synchronization bottlenecks David Cassidy said: > > I've done some tests with the below code > hope this helps David, Could you give this version a try, and run it for 1 million iterations instead of just 10k? I'll be posting my results shortly for a couple of different machines shortly. The new version keeps the theoretical overall run time constant by keeping the overall amount of work the same while you vary the thread count. So if you supply arguments 1 and 1 million, and then 2 and 1 million, in the first case 1 thread will go through 1 million iterations, in the second case each of the two threads will only go throgh 500,000 iterations. Saves you division. ;-) Glenn, it would be interesting for you to modify the code to remove the synchronization issue and then re-run the quick benchmark. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
Here are the results from the last version of the TestDatePerf program I sent out. Below are the results from 3 different systems when run for 1 million iterations. Here's how I interpret the results: The program verifies the synchronization performance issue. Dual-CPU machines take a huge performance hit when going from 1-2 processes fighting for the same synchronized lock. The dual processor machine always performs worse than the single processor with more than 1 thread running and doesn't start catching up until 16 threads are running. I did a few test runs when running 2 threads and watching the output from top, I noticed that both CPUs were not kept busy (as expected). Out of curiosity, I also tweaked the progrom and took out the call to Timestamp.toString() and replaced it with some non-synchronized code. This code scaled almost perfectly when going from 1 to 2 threads on the dual-cpu systems (run-time cut very close to 1/2) and increasing the number of threads to 16 showed very little performance deviation over the 2 thread case. So it looks like the bottleneck is real and depending on CPU performance I would guess that you would start seeing when when you start making a few thousand calls a second to these methods. -Dave Each system ran the following: time java TestJavaPerf 100 with threads values of 1, 2, 4, 8, 16. All Linux systems on on kernel 2.4.20. It would interesting to see if recent 2.5.x kernels perform better as they reported have improved multi-thread performance in the latest development kernels. System 1: Duron 600MHz, Sun Java 1.4.2, RedHat Linux System 2: PIII 500MHz, Sun Java 1.4.2, RedHat Linux System 3: Dual PIII 500MHz, Sun Java 1.4.2, RedHat Linux System 4: Dual Mips R10k 225MHz, SGI Java 1.4.1 SGI IRIX Sys# Threads Real User Sys 1160.3 59.6 0.2 1278.2 72.8 5.3 14 122.0 93.1 28.8 18 152.1 105.0 47.0 116 184.4 121.6 62.7 Sys# Threads Real User Sys 2180.5 80.2 0.3 22 108.0 111.2 3.2 24 177.2 141.5 34.4 28 290.1 200.3 88.5 216 325.2 220.0 103.9 Sys# Threads Real User Sys 3180.4 80.2 0.4 32 249.3 221.3 94.8 34 289.8 244.0 124.8 38 309.8 257.6 130.5 316 325.4 264.4 132.2 Sys# Threads Real User Sys 41 197.0 186.9 1.5 42 289.7 487.5 8.9 44 1148.9 996.9 267.0 48 1734.8 1086.0 284.3 416 1717.2 1058.4 284.8 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
David Cassidy said: > > I've done some tests with the below code > hope this helps David, Could you give this version a try, and run it for 1 million iterations instead of just 10k? I'll be posting my results shortly for a couple of different machines shortly. The new version keeps the theoretical overall run time constant by keeping the overall amount of work the same while you vary the thread count. So if you supply arguments 1 and 1 million, and then 2 and 1 million, in the first case 1 thread will go through 1 million iterations, in the second case each of the two threads will only go throgh 500,000 iterations. Saves you division. ;-) Glenn, it would be interesting for you to modify the code to remove the synchronization issue and then re-run the quick benchmark. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java Date related classes synchronization bottlenecks
I've done some tests with the below code hope this helps David 10 Processor Sun Sparc 2i 400Mhz (Solaris 2.8) jdk 1.4.0-b92 time java TestDatePerf 1 1 real0m2.096s user0m1.901s sys 0m0.142s time java TestDatePerf 2 1 real0m4.848s user0m4.240s sys 0m1.372s time java TestDatePerf 3 1 real0m7.449s user0m6.530s sys 0m3.312s time java TestDatePerf 4 1 real0m11.140s user 0m8.661s sys 0m4.543s time java TestDatePerf 5 1 real0m13.194s user 0m11.001s sys 0m7.182s time java TestDatePerf 6 1 real0m17.981s user 0m12.381s sys 0m8.602s time java TestDatePerf 7 1 real0m20.659s user 0m15.271s sys 0m10.102s time java TestDatePerf 8 1 real0m22.540s user 0m17.501s sys 0m13.603s time java TestDatePerf 9 1 real0m26.457s user 0m19.991s sys 0m14.793s time java TestDatePerf 10 1 real0m32.006s user 0m22.451s sys 0m15.923s time java TestDatePerf 20 1 real0m57.951s user 0m43.660s sys 0m37.772s time java TestDatePerf 30 1 real1m23.016s user 1m6.050s sys 0m56.952s time java TestDatePerf 40 1 real1m52.507s user 1m28.651s sys 1m15.832s time java TestDatePerf 50 1 real2m21.881s user 1m49.161s sys 1m35.772s linux dual 2.8Ghz P4 (kernel 2.4.19 ) jdk1.4.1_03-b02 time java TestDatePerf 1 1 real0m0.453s user0m0.410s sys 0m0.020s time java TestDatePerf 2 1 real0m1.411s user0m1.390s sys 0m0.410s time java TestDatePerf 3 1 real0m3.119s user0m2.890s sys 0m1.610s time java TestDatePerf 4 1 real0m3.690s user0m3.040s sys 0m1.780s time java TestDatePerf 5 1 real0m4.630s user0m3.330s sys 0m2.360s time java TestDatePerf 6 1 real0m5.410s user0m4.530s sys 0m2.480s time java TestDatePerf 7 1 real0m6.310s user0m5.030s sys 0m3.000s time java TestDatePerf 8 1 real0m7.330s user0m5.510s sys 0m3.590s time java TestDatePerf 9 1 real0m8.682s user0m6.970s sys 0m4.060s time java TestDatePerf 10 1 real0m9.648s user0m7.730s sys 0m4.760s time java TestDatePerf 20 1 real0m19.270s user0m15.500s sys 0m9.210s time java TestDatePerf 30 1 real0m32.570s user0m26.940s sys 0m14.740s time java TestDatePerf 40 1 real0m42.492s user0m35.130s sys 0m20.560s time java TestDatePerf 50 1 real0m57.209s user0m47.040s sys 0m25.330s David Rees <[EMAIL PROTECTED]To: Tomcat Developers List <[EMAIL PROTECTED]> .com>cc: Subject: Re: java Date related classes synchronization bottlenecks 11/07/2003 02:52 Please respond to "Tomcat Developers List" 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: &g
Re: java Date related classes synchronization bottlenecks
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
import java.sql.*;
import java.util.*;
public class TestDatePerf
extends Thread
{
int iterations;
Timestamp date = null;
public TestDatePerf(int iterations) {
this.iterations = iterations;
date = new Timestamp(System.currentTimeMillis());
}
public void run() {
for (int i = 0; i < iterations; i++) {
date.toString();
}
}
public static void main(String args[]) {
for (int i = 0; i < Integer.parseInt(args[0]); i++) {
TestDatePerf tdp = new TestDatePerf(Integer.parseInt(args[1]));
tdp.start();
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
java Date related classes synchronization bottlenecks
David Rees wrote:
Glenn,
This is quite interesting. How many concurrent threads need to be
running before this bottleneck starts to become a significant issue?
The worst case we have seen so far is when a JDBC query was made which
returned 100's of result sets where one of the fields was of type
DATE, TIME, or DATESTAMP. A java.sql.(Date|Time|Timestamp) would get
created for each row in the result as you iterated over it. This was
with the MySQL Connector/J JDBC driver, other JDBC drivers might perform
better.
It doesn't take too many conncurrent requests doing this before the app
server starts bogging down. Especially when there are other things using
Date related classes like web application code and Loggers.
Here is an example of what happens with the org.apache.catalina.logger.FileLogger:
public void log(String msg) {
// Construct the timestamp we will use, if requested
Timestamp ts = new Timestamp(System.currentTimeMillis());
String tsString = ts.toString().substring(0, 19);
String tsDate = tsString.substring(0, 10);
...
}
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.
Each of the six get methods used in Timestamp.toString() trigger one or two
synchronizationsin in the underlying java.util.Date object. Each of those get
methods end up calling a synchronized block on a static object in java.util.Date
and a call to the static synchronized TimeZone.getDefault() method,
or one to two calls to the static synchronized TimeZone.getDefault() method.
So when the FileLogger logs it ends up hitting a synchronized block a minimum of
six times, but usually twelve times.
To verify this look at the source for java.util.Date.getField().
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
> 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.
Regards,
Glenn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
