More comments inline... On Wed, Jan 28, 2009 at 12:13 PM, is_maximum <mnr...@gmail.com> wrote:
> > Hi Kevin > Thanks for your reply > > >>How are you invoking the enhancer? > First I tried to set the javaagent in my App server but there was a > NoClassDefFoundError so I leave it out and in OpenJPA manual I found that > the enhancer in Java EE 5 will be automatically enabled. Thus actually I am > relying on App server. and container-managed persistence Right. If you are using Container managed persistence, then allowing the hook between the app server and openjpa is the easiest way to go. I have not confirmed that the Sun application server is doing the proper classloader integration, but let's assume they are for the time being. I suppose if you wanted to, you could turn on the OpenJPA trace and verify that the Entity classes are being enhanced during load. > > >>The methods that you mention below are very minor, from a processing > viewpoint. > each call is minor but when I see the JProbe reports it shows that a single > save() method in which we used em.persist() have taken say 200000 millis > and > almost 60 percent of this time is taken cumulatively by methods used by > enhancer rather than the call to persist() method. Agree. Every little thing adds up when doing performance evaluations. It's just none of the analysis we have ever done within WebSphere has shown a problem in these "persistence capable" inserted methods. Nada. > > > > >>Are your Entities "versioned"? > No. Actually we don't use optimistic locking purposely because the number > of > update to the records are really high and also the number of requests is > really high as well. Let me tell you this is a banking system and this > business method we are testing is one of the critical methods that supposed > to have high performance. By optimistic locking, all other requests will > face problem and we need to ask the users to retry their request and > neither > the users nor the bank managers will accept this. This is interesting. Not sure what you mean that you don't use optimistic locking. JPA use optimistic locking inheritantly. The only thing you can do is override it with pessimistic locking. But, you haven't indicated that you are using OpenJPA's pessimistic lock manager. And, the JPA spec itself doesn't even define pessimistic locking. So, if you are not using Versioned Entities, then you are paying a huge overhead because we are still required to check for optimistic collisions. The only way to do that without the Version field is to read in all of the fields and see if any changes have been done. From the discussion thus far, this would seem to be your area of concern. As a test, you could turn on the SQL trace and see what kind of interactions are happening with the database. Based on the discussion thus far, I would think you are going to see a ton of wasted SQL interactions. > > >>Are you using Lazy or Eager fetching of attributes and relationships? > well generally we are using lazy relationships but in this specific case, > we > don't need any eager fetching and the entities are single fortunately. > > >>I see in your persistence.xml that you have turned off statement batching > for your Oracle database > Well I didn't get attention to it and I'll ask my colleagues in the team if > they had any reason to turn it off. > > >>And, turning on the data cache should also help, not cause you to go > backwards. You do mention that you are using the 1.2.0 release. Have you > tried moving to a later revision in the 1.2.x service stream? Or, even the > 1.3.x branch? Just to help narrow down whether something has already been > discovered and resolved for your environment. > > No I didn't try later versions and yes I have to test it > But regarding the data cache, I am wondered why using that we got lower > performance!!! > We set the data cache with a size of 2000 and soft cache enabled with a > size > of 100. However I am a bit scared of getting unusual results using data > cache due to frequent update we make into the tables. Right. Turning on the caches should not degrade performance. > > > finally I appreciate your reply and trying to help me. thanks > > > Kevin Sutter wrote: > > > > Hi is_maximum, > > The results you are experiencing are atypical. Normally, when the Entity > > classes are enhanced, OpenJPA's performance is one of or the best, > > depending > > on the specific benchmark. Let's start with a few questions to see if we > > can narrow in on the problem. > > > > o First off, you mention the enhancer. How are you invoking the > > enhancer? > > Are you statically pre-enhancing the Entity classes? Or, are you using > > the > > -javaagent jvm parameter? Or, are you relying on the Container > > classloader > > integration? I see that you are using the Sun Application Server, but > are > > you relying on the container-managed persistence or are you using > > application-managed persistence? > > > > o The methods that you mention below are very minor, from a processing > > viewpoint. So, I really don't think the slow-down is due to enhancement. > > > > o Are your Entities "versioned"? That is, are you using an @Version > > field > > in your Entities? Due to the optimistic locking that JPA does by > default, > > determining whether a given Entity is different from the database > contents > > is much, much more efficient if we can just check the @Version field > > instead > > of comparing all of the individual fields. > > > > o Are you using Lazy or Eager fetching of attributes and relationships? > > Depending on the type of the attribute and/or relationship, the default > > fetch type may be different. For example, if you have a relationship > > defined as having a Lazy fetch type, but you are constantly accessed the > > contents of that relationship, then instead of waiting until you touch > > that > > relationship to get the contents from the database (lazy), you should > > probably change that to eager to allow us to get the data on the first > > trip > > to the database. The default values for the fetch type are meant to fit > > the > > 80/20 rule, but depending on your application, they may not fit your > > needs. > > > > o I see in your persistence.xml that you have turned off statement > > batching > > for your Oracle database. That's kind of surprising since under normal > > circumstances, statement batching can only help your performance > concerns. > > Unless you are hitting some condition that forced you to turn it off? > > > > o And, turning on the data cache should also help, not cause you to go > > backwards. You do mention that you are using the 1.2.0 release. Have > you > > tried moving to a later revision in the 1.2.x service stream? Or, even > > the > > 1.3.x branch? Just to help narrow down whether something has already > been > > discovered and resolved for your environment. > > > > Let's start with that and see where these questions and answers take us. > > > > Kevin > > > > On Wed, Jan 28, 2009 at 7:41 AM, is_maximum <mnr...@gmail.com> wrote: > > > >> > >> Hi > >> > >> We have a big problem in performance. We are using JProbe to inspect > what > >> happens in our code and there is a critical business method which is > >> required to have a high TPS but unfortunately this method is doing its > >> job > >> really slow. > >> > >> Using JProbe, we found out that in a simple query or persist methods > >> (merger() / persist()...) those methods related to OpenJPA's enhancer > >> such > >> as pcReplaceField(int), pcNewInstance() and generally pc* methods have > >> long > >> duration in compare to our methods. > >> > >> As I read in OpenJPA manual the enhancer is engaged to obtain higher > >> performnce but in action we see a different result. > >> > >> Do we missed something that make enhancer not work properly or is there > >> anything else we should consider? > >> > >> I also enabled the data caching but strangely the performance has been > >> decreased!!! > >> > >> Please share your exprience with me. > >> > >> OpenJPA 1.2.0 > >> Sun Java Application Server 9.1 > >> > >> ----- > >> > >> persistence.xml > >> > >> <property name="openjpa.jdbc.DBDictionary" > >> value="oracle(batchLimit=0)"/> > >> <property name="openjpa.jdbc.SubclassFetchMode" > value="join"/> > >> --> > >> <property name="openjpa.jdbc.SynchronizeMappings" > >> > >> value="buildSchema(foreignKeys=true,schemaAction='none')"/> > >> > >> <property name="openjpa.jdbc.MappingDefaults" > >> > >> > >> > value="ForeignKeyDeleteAction=restrict,JoinForeignKeyDeleteAction=restrict"/> > >> <property name="openjpa.RestoreState" value="all"/> > >> > >> > >> -- > >> View this message in context: > >> http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2232295.html > >> Sent from the OpenJPA Users mailing list archive at Nabble.com. > >> > >> > > > > > > -- > View this message in context: > http://n2.nabble.com/-URGENT--performance-issues-tp2232295p2233824.html > Sent from the OpenJPA Users mailing list archive at Nabble.com. > >
