----- Original Message -----
From: "Jason Greene" <jason.greene(a)redhat.com>
To: "Andrig Miller" <anmiller(a)redhat.com>
Cc: "Bill Burke" <bburke(a)redhat.com>, wildfly-dev(a)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(a)redhat.com>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "James Livingston" <jlivings(a)redhat.com>
>> Cc: wildfly-dev(a)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,
>>>> to no
>>> It also can cause massive memory leaks if invoked from threads
>>> aren't re-used, like timer threads, and precautions aren't taken.
>>> 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
>> their per-request objects. Also, in an average application, there
>> multiple orders of magnitude more non component classes that are
>> 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
>> make things much easier to maintain then the hand-coded parsers
>> Wildfly uses to parse config. And much faster and less memory at
>> runtime for SOAP and JAX-RS request that currently rely on java
>> You could go research perfect hashing algorithms for URL matching
>> servlets and JAX-RS.
>> You could go do some perf analysis of all of our frameworks to
>> memory reduction and speed recommendations or even Pull Requests.
>> You could visit each major project and make sure our automated
>> 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
>> 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
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat