Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 96825 invoked from network); 27 Feb 2007 23:07:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Feb 2007 23:07:27 -0000 Received: (qmail 701 invoked by uid 500); 27 Feb 2007 23:07:36 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 667 invoked by uid 500); 27 Feb 2007 23:07:36 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 658 invoked by uid 99); 27 Feb 2007 23:07:36 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Feb 2007 15:07:36 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Feb 2007 15:07:26 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 99C4E714042 for ; Tue, 27 Feb 2007 15:07:06 -0800 (PST) Message-ID: <24097913.1172617626349.JavaMail.jira@brutus> Date: Tue, 27 Feb 2007 15:07:06 -0800 (PST) From: "John Stecher (JIRA)" To: open-jpa-dev@incubator.apache.org Subject: [jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects In-Reply-To: <20132722.1172166545512.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ 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.