I have a method that I was testing the performance of that can be called about 500,000 times a second from within my testing servlet. If the code is synchronized it runs slightly slower, say 1.5 seconds(I don't recall the percentage). However, I wanted to see how synchronization affected performance when I had 5 simultaneous servlets accessing the same method (each servlet gets the same instance variable).
Running the unsynchronized code on 5 simultaneous servlets on a windows box took about 5 seconds. I would have expected hte unsynchronized code not to not execute as if each servlet was performing sequentially.
The synchronized code slowed down to about 30 seconds for the 5 pages too complete. I am surprised that the worse case for the multithreaded test wouldn't just be 5 threads times 1.5 seconds = 9 seconds.
Speaking in general terms, you can't really draw exact linear metrics from the behavior of a web application in terms of response time and scaling. The application server will be doing all sorts of throttling and balancing to make sure it is as responsive with 100 clients as with 5. You can't just say that if 5 clients took 9 seconds, then your application takes 1.5 seconds a page. I'll bet the cpu on your server was nowhere near 100% use while that app ran and that is by design. Furthermore, when you synchronize your code, depending on where you synchronize it, you may be forcing the app server to serialize activities which it can do in parallel with unsynchronized code, like IO. This, with the fact that serializing code has the overhead of locking objects and determining which object gets the lock once released, should account for the non-linear performance of your synchronized code.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Also if you need better concurrency control in older versions of the jdk check out doug leas threading classes. He also has a nice book on the topic. The author of the articles mentioned above (Brian Goetz) is coming out with a book on java concurrency/threading too.