Hi,
we probably found a simple solution for the synchronized begin()
problem. We set the TransactionUtil.debugResources flag to false; so no
more DebugXaResources are created in the begin() method, which seems to
be the problematic (performance-wise) part.
Now this method is a lot less problematic, judging from the profiler output.
I'm not exactly sure what the code does that's not run any more. But
judging from its name ("debug") it shouldn't have any adverse effects in
a production setting, should it?
Best Regards
Martin
On 01.06.2010 08:23, 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
>>
