We are evaluating EJB3 performance and observed a progressive performance downgrade during query operations within a transaction:
1. Reading 20 simple EntityBean-POJOs in a single transaction, each by unique key, results in an average elapsed time of about 10 msecs per query operation (OK so far!)
2. Reading 1000 simple EntityBean-POJOs the same way (identical code, just changing the number of unique key query calls), results in an average of over 130 msecs (!!) per query operation (factor 13 and sometimes even higher!).
The negative progression is more or less directly related to the number of queries which are called during one transaction, i.E. for 500 queries, the average for one query is about 50-60 msecs (always the same query, just reading different entities).
Having studied the "ejb-3_0-fr-spec-persistence.pdf" we found the possibility to manage the PersistenceContext by the application itself. So, when we changed the code to application managed PersistenceContext and cleared the EntityManager (em.clear()) after each query (detaching the query-resulting EntityBean-POJO immediately after it has been processed), the query time was finally constant, irrespective of the number of queries within the transaction.
The EntityBean-POJO which was looked up by the query is a very simply and small Class with just a few attributes and relations, but just 4 String attributes have got a few characters allocated and none of the relations was filled. We therefore don't think that we had a memory related problem nor have we been able to identify any such memory related problem (memory parameters and indicators have been quite constant all the time).
It looks like the PersistenceContext iteself creates very significant overhead as more Beans become attached (?). Though increasing overhead with a growing PersistenceContext may be ok, the concrete result seems not to be normal, particularly as we've always had quite constant response times in scenarios like this with EJB2 (despite an expectedly/normally growing EntityBean cache during such transactions).
Any idea? We would hope that we don't need to manage the PersistenceContext on our own just to reach acceptable query performance in such simple scenarios.