Mailing-List: contact user-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@ofbiz.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: Performance issue:
 org.ofbiz.entity.transaction.TransactionUtil seems to be bottleneck
From: Deyan Tsvetanov <deyan_ofbiz@flexbrix.com>
To: user@ofbiz.apache.org
In-Reply-To: <1275373439.31555.4.camel@ghost-laptop>
References: <4C03EEDA.8060304@tngtech.com>
	 <1635F74F1A7C4811BB5B128A04195F71@inspiron530>
	 <3F3A55DB-209A-4C52-A3EE-15A1988E07A3@lusini.com>
	 <E066CEA7-BDD7-4744-A69C-A3AD36646FC7@me.com>
	 <1275373439.31555.4.camel@ghost-laptop>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 01 Jun 2010 09:42:52 +0300
Message-ID: <1275374572.31555.5.camel@ghost-laptop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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.kreidenweis@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
> > 
> 
>