views:

69

answers:

3

I have EJB RESTEasy controller with CMT.

One critical method which creates some entities in DB works fine and quickly on single invocation.

But when i try to invoke it simultaneously by 10 users it works very slowly.

I've tracked time in logs and the most expanded place vs. single invocation is lag between exit from RESTeasy controller and enter into MainFilter.

So this lag grows from 0-1 ms for single invocation to 8 sec. for 10 simultaneously invocations!

I need ideas what could be a reason and how can I speed up it.

A: 

My immediate reaction is that it's a database locking problem. Can you tell if the lag occurs as the flow of control passes across the transaction boundary? Try the old technique of littering your code with print statements to see when things stop.

skaffman
What are the possible places to stick logging to after the exit out of the RESTeasy bean and before enter to the MainFilter?
artemb
Are there any tools to detect database locking problems? And how to tell if the lag occurs after the transaction commit? I am interested in that problem too.
artemb
It's a tricky problem, and very database dependent. Try sticking logging statements before and after each database operation, and and at the start and end of each of your classes. If the lag occurs between the end of one component and the start of another, then it's probably occuring inside the appserver, making database/transaction logging more likely.
skaffman
A: 

Lock contention over resteasy threads? database? It is very difficult to predict where the bottleneck is.

dfa
A: 

As per some of the comments above, it does sound like it could be a database locking problem. From what you said, the "lag" occours between the Controller and the Filter invoking the controller. Presumably that is where the transaction commit is occuring.

You say however that the code creates some entities in the database, but you don't say if the code does any updates or selects. Just doing inserts wouldn't normally create a locking problem with most databases, unless there are associated updates or selects (i.e. select for update in Oracle).

Check and see if there are any resources like a table of keys or an parent record that are being updated that might be causing the problem.

Also check your JDBC documentation. Most JDBC drivers have logging levels that should allow you to see the operations being performed on the database. While this may generate a sizeable log, if you include a thread identifier in the log, you should be able to see where problems are occuring.

Neal Maloney