If the majority of the objects being created are
beans, couldn't the minimal creation time be at least partly attributable
to AppServer object pooling?
Gene Chuang wrote:
> Rickard and Lawrence,
>
> Rickard is right; with modern JVM (>= 1.3)and HotSpot 2.0, object creation
> and GC are performance red herrings.
>
> I have done extensive load-generating profiling of our architecture. We a
> lot of our entity beans are fine-grained (1 bean = 1 row) and represent
> nodes in giant tree structures. Even with the potential to create an
> overwhelming amount of objects (beans), our application spends over 80% of
> the time hitting the database, which leaves 20% of our application up-time
> in Java land. And of this 20%, I would say a good 18% is spent on actual
> intense processing, which leaves roughly less than 2% on background noise
> (object creation, GC, etc...).
>
> Gene
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> To: [EMAIL PROTECTED]
> Sent: 3/1/01 6:03 AM
> Subject: Re: Entity Beans
>
> Disclaimer: This is a tricky subject, and I do not in any way claim to
> have the final answer on this one.
>
> Now, on with the show..
>
> > What you say is true, but I thought the main savings were in object
> creation
> > and garbage collection. That is why stateless session beans (which
> normally
> > will have no state whatsoever) are pooled isn't it?
>
> Well, a year ago that might have been true, but now I'm not so sure,
> since doing manual object pooling in Java code might actually counter
> the memory management algorithms of modern JVMs. This is what I have
> been told anyway (by JRockit engineers).
>
> So, if this is actually true, then there would be no point in doing
> pooling of stateless session beans either. Just instantiate as needed,
> and don't bother with it. I have no problem seeing why this could be
> true, but I haven't done any extensive testing of this.
>
> Again, though, this assumes that setEntityContext is cheap. If you have
> a case where that callback actually does heavy operations, then all bets
> are off, or at least the above reasoning.
>
> regards,
> Rickard
>
> --
> Rickard Öberg
>
> Email: [EMAIL PROTECTED]
>
> ========================================================================
> ===
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
