[wildfly-dev] Pooling EJB Session Beans per default

[Andrig Miller]

----- 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.

I also don't like most of the "performance test suites/benchmarks" we have developed internally.  They all suffer from some of the same issues.  They don't model real application interactions and they also tend to have data sizes that are static (like 1KB payloads, or in some cases not within middle-ware, payloads that are as small as 8 bytes!).  

Developing benchmarks is not a trivial exercise.

Andy

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>