CMP Performance(not) slug.
Consider a CMP Bean deployed in 3.0.4 running against Mysql 3.23.53a.
The CMP It has finders etc that have required transaction, a read ahead of 100 and
and on-find strategy using local interfaces. 1 single user accessing server.
SQL Access to db is fine ( 100ms ). Since in a transaction with on-find I get 1 query. This is good. No further access to db is made when accessing the local interface from a session bean.
Where CMP appears deficient is that it is CPU bound by getXXX() methods.
A fetch of some 1000 records takes ~100ms of mysql time. And 6000ms of jboss time.
Consider the following:
Test case 1:
Objective: return collection objects.
ArrayList result = new ArrayList();
Collection c = findSomething(code);
Iterator i = c.iterator();
while ( i.hasNext() ) {
BeanLocal l = (BeanLocal)i.next();
result.add(something);
}
Total time 980ms. Not too bad even tho this is nearly 10 times longer than the time taken to fetch the data in the first place.
Test case 2:
Objective: return collection of values.
ArrayList result = new ArrayList();
Collection c = findSomething(code);
Iterator i = c.iterator();
while ( i.hasNext() ) {
BeanLocal l = (BeanLocal)i.next();
String goober = getGoober();
result.add(goober);
}
Total time 6000ms. Pathetic.
Adding more getXXX() slows down even more.
Whatever getXXX() is doing ( dynamic proxy etc, check for dirty read etc ) is way too complex. Even tho in my
case no further db reads are made it still takes too long.
The problem in performance of CMP is the time taken to access the getXXX() methods. If the
transaction and read ahead options are set correctly then the DB access part of the process seems to
work fairly well.
I have seen some postings on news groups that suggest you shouldn't use ejb's for bulk loads in CMP and should bulk load via jdbc or some such thing.
This argument is flawed; whether 1000 process requests in a loop or 1000 separate requests for a fetch the getXXX() process is cpu bound. It is a performance bottleneck. CMP while intending to save development time is hitting performance in same cases my factors of 30 times slower than JDO etc.
While CMP is said to be solving a different problem than JDO and EJB's provide some nifty features its not very usefull if it doesn't perform. Seems that CMP/EJB is over engineered? RDB/SQL persistence for Obects is a flawed concept and while it allows for some access to legacy systems. In its current form (many news postings and forum threads imply) it doesn't perform and not always because developers have stuffed up deployment options. CMP needs an OODB something like an Ozone to support CMP not SQL. In fact the encapsulation leakage you get with having to define or even care about SQL kinda defeats the purpose.
