You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Gianny Damour <gi...@optusnet.com.au> on 2006/06/05 15:06:03 UTC
Re: Results of testing Gianny's TranQL Performance Improvements for
CMP entity beans
Hi Matt,
Thanks for posting these results :)
Matt Hogstrom wrote:
> Gianny,
>
> I applied your changes to fix the double execution. It looks like the
> modifications you made overall improved performance by about 10% (from
> 1445 to 1591). However, I still see the double execution of the SQL
> for the Quote bean. So we can still eek out some extra performance.
> The best number on the servers I tested has been about 2000 so we're
> almost there :)
When you say double execution, do you mean:
1. SELECT Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ?; followed by
2. SELECT Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high,
Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ?
as reported under the *With TranQL Changes:* section?
If yes, then I am not sure how this can be fixed without caching. The
first query maps to the findByPrimaryKey method. After its execution,
the transactional cache is being flushed as all the methods of QuoteEJB
have a CMT set to "Required" and PingServlet2EntityLocal does not
demarcate tx. As a consequence, the transactional cache is now empty.
The second query maps to a row-fault event when getDataBean is invoked.
There is a row-fault because the transactional cache is empty.
With caching of CMP across transactions, the row-fault event does not
happen: the cache is queried and a record is found.
>
> Here are the stats from the testing I did tonight.
>
> *Before TranQL Change:*
> 06/04/2006 22:02:25 IWL0060I Page throughput = *1445.272 /s*
>
> This data is already in the JIRA.
>
> *With TranQL Changes:*
> 06/04/2006 22:50:45 IWL0060I Page throughput = *1591.233 /s*
>
<snip>
>
>
> *With TranQL CMP Caching Option:*
> 06/04/2006 23:01:09 IWL0060I Page throughput = *1988.110* /s
>
> These are the queries that are being executed while caching is
> enabled. Note the difference between the queries. I'm not sure why
> this is.
The first query, 973 exec, is a row-fault query. The second query maps
to findByPrimaryKey; it is the result of a transformation of "SELECT
Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ?" to fetch a group of fields
at the same time than the primary key. In this case, the group to be
prefetched is pretty simple: all the QuoteEJB CMP fields. However, the
engine can fetch a graph of objects in a single pass.
Thanks,
Gianny
>
> Number of executions = 973
> Number of compilations = 1
> Total execution time (sec.ms) = 0.052875
> Total user cpu time (sec.ms) = 0.015625
> Total system cpu time (sec.ms) = 0.015625
> Statement text = SELECT Q.symbol, Q.low, Q.open1,
> Q.volume,
> Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE
> Q.symbol = ?
>
> Number of executions = 221945
> Number of compilations = 1
> Total execution time (sec.ms) = 12.888160
> Total user cpu time (sec.ms) = 9.843750
> Total system cpu time (sec.ms) = 1.515625
> Statement text = SELECT Q.symbol, Q.symbol,
> Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1
> FROM QuoteEJB Q WHERE Q.symbol = ?
>
> Matt
>
>
Re: Results of testing Gianny's TranQL Performance Improvements for
CMP entity beans
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Inline
Gianny Damour wrote:
> Hi Matt,
>
> Thanks for posting these results :)
>
> Matt Hogstrom wrote:
>
>> Gianny,
>>
>> I applied your changes to fix the double execution. It looks like the
>> modifications you made overall improved performance by about 10% (from
>> 1445 to 1591). However, I still see the double execution of the SQL
>> for the Quote bean. So we can still eek out some extra performance.
>> The best number on the servers I tested has been about 2000 so we're
>> almost there :)
>
> When you say double execution, do you mean:
>
> 1. SELECT Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ?; followed by
> 2. SELECT Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high,
> Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ?
>
> as reported under the *With TranQL Changes:* section?
>
> If yes, then I am not sure how this can be fixed without caching. The
> first query maps to the findByPrimaryKey method. After its execution,
> the transactional cache is being flushed as all the methods of QuoteEJB
> have a CMT set to "Required" and PingServlet2EntityLocal does not
> demarcate tx. As a consequence, the transactional cache is now empty.
> The second query maps to a row-fault event when getDataBean is invoked.
> There is a row-fault because the transactional cache is empty.
>
Perhaps the naive approach would be to define a set of columns to be faulted in when the FBK is
initially executed and save those values in the transactional cache. Subsequent attempts to retrive
the columns would be serviced from the Tx Cache and not result in another SQL to the DB. This is
how WebSphere and WebLogic do it I think.
So in the case of our implementation we would define the default behaviour to select all columns.
If someone wanted to limit the columns selected (like BEA does when they publish SPECj results) then
only the requested columns are fetched.
I expect regardless of how we proceed we'll not be able to make further changes to 1.1 but I'd like
to entertain this for TranQL 1.3.1 and perhaps a quick 1.1.1 turnaround.
> With caching of CMP across transactions, the row-fault event does not
> happen: the cache is queried and a record is found.
>
>>
>> Here are the stats from the testing I did tonight.
>>
>> *Before TranQL Change:*
>> 06/04/2006 22:02:25 IWL0060I Page throughput = *1445.272 /s*
>>
>> This data is already in the JIRA.
>>
>> *With TranQL Changes:*
>> 06/04/2006 22:50:45 IWL0060I Page throughput = *1591.233 /s*
>>
> <snip>
>
>>
>>
>> *With TranQL CMP Caching Option:*
>> 06/04/2006 23:01:09 IWL0060I Page throughput = *1988.110* /s
>>
>> These are the queries that are being executed while caching is
>> enabled. Note the difference between the queries. I'm not sure why
>> this is.
>
> The first query, 973 exec, is a row-fault query. The second query maps
> to findByPrimaryKey; it is the result of a transformation of "SELECT
> Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ?" to fetch a group of fields
> at the same time than the primary key. In this case, the group to be
> prefetched is pretty simple: all the QuoteEJB CMP fields. However, the
> engine can fetch a graph of objects in a single pass.
>
> Thanks,
> Gianny
>
>>
>> Number of executions = 973
>> Number of compilations = 1
>> Total execution time (sec.ms) = 0.052875
>> Total user cpu time (sec.ms) = 0.015625
>> Total system cpu time (sec.ms) = 0.015625
>> Statement text = SELECT Q.symbol, Q.low, Q.open1,
>> Q.volume,
>> Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE
>> Q.symbol = ?
>>
>> Number of executions = 221945
>> Number of compilations = 1
>> Total execution time (sec.ms) = 12.888160
>> Total user cpu time (sec.ms) = 9.843750
>> Total system cpu time (sec.ms) = 1.515625
>> Statement text = SELECT Q.symbol, Q.symbol,
>> Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1
>> FROM QuoteEJB Q WHERE Q.symbol = ?
>>
>> Matt
>>
>>
>
>
>
>
>