Suprises on performance of CMP read ahead caching on large r

[andrewgoedhart]

Just finished doing some testing on the preformance of the CMP read ahead cache. The result is suprising.When returning 10 000 beans from a find all, turning off read ahead caching results in a 5-8 time perfromance improvement when iterating over the returned collection . I.e. linear access. This is against both commit options A and B. In fact commit option A seems to make the perfromance worse and more eractic when read ahead is on. Using on-load or on-find doesn't seem to make any real difference to these results.

For a table of results for each setting as well as the results when running the server and client VMs see my post to the CMP forum: http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t=

[sverker]

Did you analyze the queries sent to the dbms? I noticed that at some point it looks like JBoss runs out of cache memory and then start doing selects like

select id from xxx where (id=1234) OR (id=1235) OR (id=1236) and so on

and then in the next query do
select id from xxx where (id=1235) OR (id=1236) OR (id=1237) and so on

i.e. it fetches data again that it already has fetched. I tested with both commit option A and B and the operation is done within a transaction.

It is the same behaviour as when doing read-ahead without a transaction.