[wildfly-dev] Pooling EJB Session Beans per default

[Andrig Miller]

----- Original Message -----
> From: "Jason Greene" <jason.greene at redhat.com>
> To: "Andrig Miller" <anmiller at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, wildfly-dev at lists.jboss.org
> Sent: Tuesday, August 5, 2014 8:15:47 AM
> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
> 
> 
> On Aug 5, 2014, at 8:43 AM, Andrig Miller <anmiller at redhat.com>
> wrote:
> 
> > 
> > 
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "James Livingston" <jlivings at redhat.com>
> >> Cc: wildfly-dev at lists.jboss.org
> >> Sent: Tuesday, August 5, 2014 7:32:04 AM
> >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
> >> 
> >> 
> >> 
> >> On 8/4/2014 8:44 PM, James Livingston wrote:
> >>> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote:
> >>>> I always liked the ThreadLocal pool.   No synchronization,
> >>>> little
> >>>> to no
> >>>> allocations.
> >>> 
> >>> It also can cause massive memory leaks if invoked from threads
> >>> which
> >>> aren't re-used, like timer threads, and precautions aren't taken.
> >>> AS/EAP
> >>> 5 suffered from that problem with the default ThreadLocalPool.
> >>> 
> >> 
> >> Which is also something that could be mitigated by a common thread
> >> facility.  Something AS/EAP 5 didn't have.
> >> 
> >> Honestly though, I think this talk of EJB pooling is ridiculous.
> >> Component layers like CDI and JAX-RS don't have pooled
> >> architectures
> >> for
> >> their per-request objects.  Also, in an average application, there
> >> are
> >> multiple orders of magnitude more non component classes that are
> >> being
> >> instantiated per request.  Just think of all the Strings created
> >> by a
> >> simple HTTP request.
> >> 
> >> You want a better focus?  How about JSON/XML marshalling?  Which
> >> could
> >> make things much easier to maintain then the hand-coded parsers
> >> that
> >> Wildfly uses to parse config.  And much faster and less memory at
> >> runtime for SOAP and JAX-RS request that currently rely on java
> >> reflection.
> >> 
> >> You could go research perfect hashing algorithms for URL matching
> >> with
> >> servlets and JAX-RS.
> >> 
> >> You could go do some perf analysis of all of our frameworks to
> >> make
> >> memory reduction and speed recommendations or even Pull Requests.
> >> 
> >> You could visit each major project and make sure our automated
> >> builds
> >> have and can run automated stress tests and are measured against
> >> previous versions.
> >> 
> >> Or you could just focus on these silly benchmarks that test no-op
> >> HTTP
> >> and EJB requests.
> >> 
> > 
> > Those silly benchmarks, are indeed silly.  Any workload that
> > doesn't actually do anything with the requests is not very
> > helpful.  You can be really fast on them, and be really slow on a
> > workload that actually does something.  We have already seen this
> > in one case recently.
> 
> It’s all about precision, and limiting variables. I know its fun to
> criticize micro benchmarks (obviously micro is indeed relative
> because a great deal of processing goes on even when you have EJB
> and HTTP requests that don’t do much), however micro benchmarks,
> provided they are measured correctly, are quick to run and make it
> easy to tell what you have to fix. Large gigantic apps on the other
> hand are difficult to analyze, and do not necessarily represent
> activity that a differently architected app would show. To use an
> example, if you have pattern matching code, and you want it to be
> fast, it’s much easier (and accurate) to benchmark the pattern
> matching code then it is to benchmaark a full EE app that happens to
> use pattern matching in a few places.
> 

I know micro benchmarks can be useful, and the performance has actually written a couple ourselves.  They have to be very carefully designed, so that the results transfer to larger complex workloads.

> Arguing against targeted benchmarks is like arguing that you should
> never write a test case, because only real production load will show
> problems…. To some extent thats true, but that doesn’t mean that the
> problems you catch in simulations won’t affect production users.
> 

I don't argue against them, in principal, just that most of the ones I have seen haven't actually exposed problems we continue to find with our larger more complex workloads.

Andy

> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
>