[
https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476438
]
John Stecher commented on OPENJPA-160:
--------------------------------------
So here is a thought. Basically this benchmark is performing 5 interactions
with the database doing a simple FBPK in this scenario. Thus the tps numbers
above really need to be multiplied by 5 to get the total number of times we
pass into the JPA code base. So that really means that we are doing 7000
invocations per second spread across 50 runtime threads in the appserver. This
could lead to a heck of a lot of contention on any single sync point which is
what we saw in the earlier improvements we worked on with Kevin and company.
Now someone can correct me if I am wrong here but isnt the JVM specification
clear that when initializing a class the class object must be synchronized on.
Thus possibly making this the single most contended point in the codebase now
that we have removed all the other sync points in the earlier performance work?
We are doing CPU sampling based profiling to cut overhead to a minimum so that
would show something like this as a hotspot I would think as the actually sync
point is in C code and happens under the newintsance method.
Anyway just throwing that out there for a reason this could be happening. I am
still baffled. Need to think about a test case to prove this as well.
> Reuse BrokerImpl objects
> ------------------------
>
> Key: OPENJPA-160
> URL: https://issues.apache.org/jira/browse/OPENJPA-160
> Project: OpenJPA
> Issue Type: Sub-task
> Reporter: Michael Dick
> Assigned To: Patrick Linskey
> Attachments: newprofile.jpg, openjpa-160-patch.txt,
> openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt,
> perf2.jpg, perf3.jpg, profile_explicitclass.jpg
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
