Some things worth checking out:
- Overhead can be associated with a transaction managed by Spring at the application level. See which transaction manager you are using (look for a bean named
transactionManager ). If you use JTA, probably where your problem is. Since this is fast with JDBC, the bottleneck does not seem to be db. - Depending on how your application uses this transaction, it may contain everything in memory before it completes all 1,500 requests and completes the transaction. Do you see a big difference in memory usage (Spring needs to be much taller)?
- Which database connection pool do you use in any of the cases?
A quick way to profile your application:
Get pid - "jps -l"
Memory: jmap -histo PID (check if there is any form of memory leak)
Check what happens under the hood: jstack PID (look for slow or recursive method calls)
Felipe oliveira
source share