From: "Bill Burke" <bburke@redhat.com>
To: "Andrig Miller" <anmiller@redhat.com>
Cc: wildfly-dev@lists.jboss.org, "Jason Greene" <jason.greene@redhat.com>
Sent: Tuesday, August 5, 2014 4:36:11 PM
Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
On 8/5/2014 3:54 PM, Andrig Miller wrote:
Its a horrible theory. :) How many EJB instances of a give type
are
created per request? Generally only 1. 1 instance of one object
of
one
type! My $5 bet is that if you went into EJB code and started
counting
how many object allocations were made per request, you'd lose
count
very
quickly. Better yet, run a single remote EJB request through a
perf
tool and let it count the number of allocations for you. It will
be
greater than 1. :)
Maybe the StrictMaxPool has an effect on performance because it
creates
a global synchronization bottleneck. Throughput is less and you
end
up
having less concurrent per-request objects being allocated and
GC'd.
The number per request, while relevant is only part of the story.
The number of concurrent requests happening in the server
dictates the object allocation rate. Given enough concurrency,
even a very small number of object allocations per request can
create an object allocation rate that can no longer be sustained.
I'm saying that the number of concurrent requests might not dictate
object allocation rate. There are probably a number of allocations
that
happen after the EJB instance is obtained. i.e. interception chains,
contexts, etc. If StrictMaxPool blocks until a new instance is
available, then there would be less allocations per request as
blocking
threads would be serialized.
Whoever is investigating StrictMaxPool, or EJB pooling in general
should
stop. Its pointless.