Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Huge performance issue with @Transactional [SPR-15909] #20463

Open
spring-projects-issues opened this issue Aug 30, 2017 · 2 comments
Open

Huge performance issue with @Transactional [SPR-15909] #20463

spring-projects-issues opened this issue Aug 30, 2017 · 2 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 30, 2017

Ács Ádám opened SPR-15909 and commented

Enabling @Transaction on a spring service makes a method execution time 100x slower. I set up a minimum example, it shows the following:

1 spring bean + 1 pojo, both has a trivial method to execute. Mesured with spring stopwatch.

Without transaction:
pojo: 1ms
bean: 1ms

With transaction:
pojo: 1ms
bean: 89ms


Affects: 4.3.10

Attachments:

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 30, 2017

Ács Ádám commented

https://dzone.com/articles/cacheable-overhead-spring-0 article covers the issue. It's about caching, but the problem is identical in my opinion.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 30, 2017

Juergen Hoeller commented

As far as I can tell - and as far I can measure -, this is simply the transaction processing overhead that you're measuring against an essentially empty method there. There's also some general overhead of reflective invocations but most time is actually spent in the transaction management itself. Since most transactions are declared at service boundaries, the overhead only occurs in specific spots, not for each level of invocation in a call stack.

None of this usually matters with real-life transactions since such actual service method code involves a degree of I/O which outweighs the transaction overhead by far. And if you really care, there's always programmatic transaction management a la TransactionTemplate as an alternative, with somewhat reduced overhead. That's also what I would recommend for plain cache access: If you care about hotspot overhead, use programmatic cache access.

Of course, if we can identify specific optimizations here, we're happy to consider them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.