On 2016-10-03 07:56:34, Tullio Bettinazzi wrote:
> I've an application under tomcat.
> When only a one or two users works on it everithing is ok.
> When the number of users grows the application slows down.
> Is not a memory nor a cpu problem : using top I see the system resources 
> quite free.
> I don't see relevant garbage collection : heap size and permgen have correct 
> dimentions.
> No other applications are running on the system.
> I log more or less every relevant operation in my system (db query and so on) 
> and I see that every slowdown is concentered in a single operation.
> I mean all operations take "normal" time but one or two of them take 4 
> seconds more.
> The "slowing" operations are not the same in different executions, and theydo 
> not have a specific type (not only DB query, not only DB stored procedures, 
> not only.....).
> It seems like if the thread is frozen for a fixed amount fo time (4 seconds 
> more or less) and then it restarts.
> I don't think it's a "queue" problem because otherwise the wait time would be 
> unperdictable and not a "fixed" 4 seconds time.
> I don't know any parameter impacting on that behaviour.
> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
> Could someone suggest a solution for my problem or, at least, an 
> investigation strategy.
> Tks
> 
> Tullio
> 


The few examples that you mention are all database related (query/stored 
procedure).
Can it be that your connection pool (if used) combined with not closing 
connections is part of the problem.

I can imagine :
1)
Maybe you run out of conenctions, because connections are not properly closed.
And also the connection pool teminates connections when they are not used for 4 
seconds.
After 4 seconds the pool can recreate connections again.

or 2)
Maybe your connection pool has very limited connections.
With one or two users this limited number of connections in the pool will 
suffice.
If there are more users, the max. number of connections isn't enough.
The pool then has to wait for connections to become fee again.


(uhh....I'm not an expert at all, but the above came immediately to my mind)

-- 
Met vriendelijke groet,

Martijn Bos
+31 6 39477001

(Public pgp-key : http://maboc.nl/pubkey.maboc.asc)

Attachment: signature.asc
Description: Digital signature

Reply via email to