tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David kerber <>
Subject Re: Performance with many small requests
Date Fri, 08 May 2009 13:18:20 GMT
Pid wrote:
> Peter Crowther wrote:
>>> From: David Kerber []
>>> The synchronized section doesn't do a whole lot, so it
>>> doesn't take long to process.
>> Indeed.  So take a thread dump and see what's happening before making *any* changes
to this key part.
>>> My question is, what kinds of operations need to be
>>> synchronized?  All I do is decrypt the data from the POST,
>>> send a small
>>> acknowledgement response back to the site, and write the line
>>> to the log
>>> file.  Does that sound like something that would need to be
>>> synchronized?  If not, pulling that out would be a really easy test to
>>> see if it helps my performance issue.
>> Decrypt: parallel.
>> Send ack: parallel.
>> Increment counters: synced.
>> Write to log file: synced (or you'll have some very odd stuff happening).
> Would a single thread executor service alongside an atomic counter be
> useful here?  (my concurrency knowledge isn't so hot).
> I'm not sure if a) this is suitable or b) if it would solve the problem,
> as you may still end up with a delayed write to the log during peaky
> periods - at least they'd be in the right order though.
The order is the only thing that's important; a short delay (up to a few 
tens of seconds) is no problem.

Also, right now I'm doing a .flush() after the .write() to the log 
file.  Is that usually necessary, other than to avoid losing data lines 
in case of a system failure?  A few lost lines, while not desirable, 
isn't too big of a problem in this particular application.  How would a 
.flush() affect the speed of returning from a synchronized .write()?

> You could be dumping runnables into it during the post which would
> return quickly for the next request.  You'd have to consider
You lost me here...

> exec.shutdown() & exec.shutdownNow() in your servlet destroy to ensure
> you didn't drop data during a shutdown or app restart


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message