To be clear, I wasn't recommending that we remove synchronized from the begin method in OFBiz, just that they remove it temporarily and then redo their performance tests to see if that really is the problem.
You're absolutely right that more work will be necessary to localize the synchronization to avoid bottlenecks on a larger block of code. BTW, the three sub-method calls you mentioned should all only deal with thread-local variables... aren't those thread-safe to use? -David On Jun 1, 2010, at 12:42 AM, Deyan Tsvetanov wrote: > I take my words back about the workaround. > It's much more complicated. > > On Tue, 2010-06-01 at 09:23 +0300, Deyan Tsvetanov wrote: >> Hi guys, >> >> removing synchronized from begin( int timeout) will cause issues. >> The problematic code is the following: >> (starting from line 180 in TransactionUtil.java - trunk ) >> >> // reset the transaction stamps, just in case... >> >> clearTransactionStamps(); >> // initialize the start stamp >> getTransactionStartStamp(); >> // set the tx begin stack placeholder >> setTransactionBeginStack(); >> >> So the synchronized begin() is a huge bottleneck and imho it can't be >> solved without coding. Caching is not a solution. >> I think the transaction timestamps and the transaction begin stack have >> to be moved to the UserTransaction so they are not static anymore. >> In general TransactionUtil needs some rework. >> >> Cheers, >> Deyan >> >> On Mon, 2010-05-31 at 14:34 -0600, David E Jones wrote: >>> The theory that Martin mentioned is interesting, and quite possible. Have >>> you tried removing the synchronized keyword from the begin method to see if >>> it helps? >>> >>> That would just be to test the theory, and if that does turn out to be the >>> bottleneck then the sensitive parts of the method should be synchronized >>> (or put into separate synchronized methods) instead of snycing the whole >>> method. >>> >>> -David >>> >>> >>> On May 31, 2010, at 2:24 PM, Karl Pitrich wrote: >>> >>>> Hi, >>>> >>>> I'm working with Martin on this project. >>>> >>>> We have commented the various cache options as described in the Wiki (and >>>> mailing list), >>>> EXPIRE TIME is 0 in all except for product.* when viewing >>>> /webtools/control/FindUtilCache >>>> >>>> Logging is disabled, as are several components. >>>> Also, we have disabled several content elements from the template, such as >>>> recommendations or polls, etc. >>>> >>>> >>>> Any help is appreciated, >>>> Greetings, >>>> >>>> - Karl >>>> >>>> On 31.05.2010, at 22:07, Jacques Le Roux wrote: >>>> >>>>> 1st level of answer, did you set caches? >>>>> https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-CacheSettings >>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Scaling+and+Performance+Plan >>>>> >>>>> Jacques >>>>> >>>>> From: "Martin Kreidenweis" <martin.kreidenw...@tngtech.com> >>>>>> Hi, >>>>>> >>>>>> we are currently evaluating Apache OFBiz for use in one of our projects. >>>>>> >>>>>> We expect a high load on our application. So we did a test with jMeter >>>>>> on the sample ecommerce application with 100 parallel sessions and in >>>>>> average 400 msec (randomized) wait time between requests. >>>>>> >>>>>> During profiling we experienced that >>>>>> org.ofbiz.entity.transaction.TransactionUtil.begin() is by far the >>>>>> dominating method invoked and the application spends about 75% of total >>>>>> time in this method. >>>>>> This results in page load times over 10 seconds and growing. >>>>>> >>>>>> Many threads are blocked because the method is defined as static and >>>>>> synchronized. >>>>>> >>>>>> We are using MySQL as a database backend in our test setup and >>>>>> deactivated all informational logging (even server hit statistics), and >>>>>> most of the sidebar widgets. >>>>>> >>>>>> Any suggestions/ideas are highly appreciated. >>>>>> Thanks. >>>>>> >>>>>> Best regards, >>>>>> Martin >>> >> >> > >
