Re: EJBUtils.cloneObject tkes up 40% of the time
What happens if you set in orion-ejb-jar.xml? See: http://www.orionserver.com/docs/orion-ejb-jar.xml.html Kirk Yarina At 08:55 PM 3/12/01 -0500, you wrote: >Hello, > >I had posted a similar message a while back but never got any response. >Now, it has become critical. Hopefully, someone can help me understand >this. > >While profiling my server, I'm noticing that the server is spending >approximately 40% of the time in >com.evermind.server.ejb.EJBUtils.cloneObject() (Apparently, the method >serializes/deserializes an Object to clone it). The method is invoked >each time a SLSB calls another SLSB that returns a value. Aparently, >the to be returned value is cloned before being returned to the caller. >Both the SLSB are on the same server and deployed in the same >application. The returned value is Cloneable and Serializable. Have I >mis-configured something? Has anyone else experienced a similar >performance penalty? > >This has become quite a critical performance issue for me and I would >appreciate any feedback. > >Thanks, >Vidur
Re: EJBUtils.cloneObject tkes up 40% of the time
That seems like a rather large percentage, but a lot of things depend on the mix of code and data structures you have in your app. According to the spec, this is correct behavior because all call values should be cloned via serialization. There are some tricks to speed up serialization, such as using constant version ids to avoid a hash compute, but I personally prefer to keep things as simple since there's enough complexity in an app without tinkering at a low level. The best optimization strategy is to minimize the number of ejb-to-ejb calls if possible. If your call parameters are complex, you may want to refactor those, as serialization performs a deep-copy by default. I guess the bottom line is that the serialization can't be avoided. The bottleneck is clearly identified, so from the point, you'll just have to decide what tradeoffs to make. It may be better just to throw more hardware at it... In my experience, hardware is much cheaper than debugging, so I always hedge on the side of correctness. Your mileage may vary, but I hope that this helps out a bit. As a side note, have you tried running you app in a different appserver? If this is an Orion-specific issue, I'd be very amazed. Come to think of it, I'd be very interested in hearing about everyone's experiences with the relative performance of appservers. It seems to me that Orion performs quite admirably, although the limiting factor is often network I/O. - Original Message - From: "Vidur Dhanda" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Monday, March 12, 2001 5:55 PM Subject: EJBUtils.cloneObject tkes up 40% of the time > Hello, > > I had posted a similar message a while back but never got any response. > Now, it has become critical. Hopefully, someone can help me understand > this. > > While profiling my server, I'm noticing that the server is spending > approximately 40% of the time in > com.evermind.server.ejb.EJBUtils.cloneObject() (Apparently, the method > serializes/deserializes an Object to clone it). The method is invoked > each time a SLSB calls another SLSB that returns a value. Aparently, > the to be returned value is cloned before being returned to the caller. > Both the SLSB are on the same server and deployed in the same > application. The returned value is Cloneable and Serializable. Have I > mis-configured something? Has anyone else experienced a similar > performance penalty? > > This has become quite a critical performance issue for me and I would > appreciate any feedback. > > Thanks, > Vidur > > >
RE: EJBUtils.cloneObject tkes up 40% of the time
At 07:43 13.03.2001 , you wrote: >This is probably because orion is trying to keep to the EJB spec where >parameters and return values must be passed to a EnterpriseBean must be by >value. This way orion doesnt have to implement RMI, but still complies to >the spec. > >This is probably far cheaper than RMI. > >Noel If you know what you are doing and you can live with the cosequences you can always disable the pass-by-value semantics on a per-ejb basis. Look at the orion-ejb-jar.xml dtd. HTH robert (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: EJBUtils.cloneObject tkes up 40% of the time
Title: RE: EJBUtils.cloneObject tkes up 40% of the time This is probably because orion is trying to keep to the EJB spec where parameters and return values must be passed to a EnterpriseBean must be by value. This way orion doesnt have to implement RMI, but still complies to the spec. This is probably far cheaper than RMI. Noel -Original Message- From: Vidur Dhanda [mailto:[EMAIL PROTECTED]] Sent: 13 March 2001 03:56 To: Orion-Interest Subject: EJBUtils.cloneObject tkes up 40% of the time Hello, I had posted a similar message a while back but never got any response. Now, it has become critical. Hopefully, someone can help me understand this. While profiling my server, I'm noticing that the server is spending approximately 40% of the time in com.evermind.server.ejb.EJBUtils.cloneObject() (Apparently, the method serializes/deserializes an Object to clone it). The method is invoked each time a SLSB calls another SLSB that returns a value. Aparently, the to be returned value is cloned before being returned to the caller. Both the SLSB are on the same server and deployed in the same application. The returned value is Cloneable and Serializable. Have I mis-configured something? Has anyone else experienced a similar performance penalty? This has become quite a critical performance issue for me and I would appreciate any feedback. Thanks, Vidur
