Interceptor stack kills CMP performance

[giorgio42]

Big picture:
Solaris 2.8/Oracle8.1.7/JBoss 3.0.2
JSP -> SLSB -> EB
Transaction settings: Required
Logging level: INFO (no logging occurs)
CMP Configuration: Instance Per Transaction.
Default eager loading (*)
Read-ahead on find, page size sufficient to load all entities in memory during finder.

Reading 1000 EBs into value objects using CMP2.0 vs. JDBC result set:

CMP2.0 : ~10 ms/EB
JDBC : ~1 ms/EB

Most interesting: the time the CMP2.0 version takes does almost not depend on how many properties are read/set (7 properties). The time is lost in the interceptor stack when the loadValues() method on the EB is called
(see code below).

Removing the security interceptor and the logging interceptor speeds up things by about 10%.

Which of the other interceptors can be left out without breaking things, especially on the client side?

Code snippets:

CMP version:
...
Iterator entities = myLocalHome.findSome().iterator();
for (;entities.hasNext();)
{
MyEBLocal entity = (MyEBLocal)entities.next();
entity.loadValues(someValueObject);
}
...

MyEBClass.java:
public void loadValues(MyValueObject valueObject)
{
valueObject.setProp1( getProp1() );
...
}

JDBC code:
while (rows.next()) {
MyValueObject valueObject = buildFromRow(rows.next());
...
}

buildFromRow(CachedRowSet rows)
{
...
valueObject.setProp1( rows.getString( 1 ) );
...
}

It seems I am loosing about 1 ms per interceptor per entity bean instance.
What can be done to get through the interceptors more quickly?

Regards
Georg

[giorgio42]

I explored the topic a bit further, and I detected, that my previous performance comparison was a bit unfair, because it included a 'find' on each instance for the CMP version.

After I changed this (simply doing a findAll() and then creating a value object for each instance), the CMP performance is still at least 3, most of the time however 5 - 10 times worse than using direct JDBC calls.

I tried the following options to improve speed:
1) declaring all getters and the loadAttributes() method read-only in jboss.xml
2) shrinking the interceptor stack.

Option 1) leads to a slightly, but almost not noticeable better performance.

For option 2) I removed one interceptor after the other, re-running the performance test each time.

The most interesting outcome is, that even removing almost all interceptors does not lead to a significant performance improvement, except the EntityMultiInstanceSynchronisation interceptor. Removing this interceptor reduces the time to read the 1000 test entities by 50%, AS LONG AS no attributes or only the primary key field is accessed. Copying four of the seven attributes leads to the same performance as before (when the EntityMultiInstanceInterceptor is included), and copying all attributes doubles the time required for reading the test entities.

After researching this topic for two days I did not find any convincing possibility to improve the CMP reading performance to tolerable values. Therefore I have to implement the reporting part of my application using direct JDBC calls. What a shame!

Regards
Georg

[dsundstrom]

To be honest, JBossCMP has not been heavly preformce tested by me. Other have and posted patches that gave us major improvements. Considering what you are doing, JDBC will always be faster, so you have a choice to make raw speed vs maintance cost. It is you choice based on you situation.

Just a quick question. Are you using a single wrapping transaction? Did you try the value class pattern where you load all the values you are interested in. This usually gives a preformance boost.

[giorgio42]

Dain,

- yes, I am using a single wrapping transaction. Using commit option A instead of B has no noticeable effect on performance.

- yes, I am loading all values into a value object inside a loadAttributes() method of the EB.

Of course CMP will always be slower than raw JDBC. The point is: how much slower?

With the current performance, I cannot build an interactive application that lists more than a few hundred (~300) value objects created from EBs in a page or window, otherwise the window will take too long to build up. This is a severe limitation.

I have read that you want to do a CMP-based forum for the JBoss web site. It would be interesting to see how it performs. And also how you solve the concurrent access problems.


Regards
Georg

[giorgio42]

I include an Excel spreadsheet of my performance test results, exported as tab-separated ascii file and the (stripped-down) code of my test EB.

And the jboss.xml as well.

If you could give any hints on how to speed up the EB performance, this would be greatly appreciated.

Regards
Georg

[giorgio42]

Dain,

I decided to remove the Excel spreadsheet.
I'd like to send it to you directly.

Georg

[dsundstrom]

Send it to me [e-mail]. I am super busy right now so I won't be able to look at it right away.

[hunterhillegas]

Just curious whatever happened with this thread... Did anything ever come of this stuff?

[giorgio42]

I sent the stuff to Dain, but never got an answer so far.

Regards
Georg