Re: [wildfly-dev] Pooling EJB Session Beans per default

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: wildfly-dev(a)lists.jboss.org > Sent: Wednesday, August 6, 2014 9:30:06 AM > Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default > > > > On 8/6/2014 10:50 AM, Andrig Miller wrote: >> >> >> ----- Original Message ----- >>> From: "Radoslaw Rodak" <rodakr(a)gmx.ch&gt; >>> To: wildfly-dev(a)lists.jboss.org >>> Sent: Tuesday, August 5, 2014 6:51:03 PM >>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default >>> >>> >>> Am 06.08.2014 um 00:36 schrieb Bill Burke <bburke(a)redhat.com&gt;: >>> >>>> >>>> >>>> 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. >>>> >>> >>> Scenarion 1 ) >>> ------------------ >>> Let say we have a pool of 100 Stateless EJBs and a constant Load >>> of >>> 50 Requests per second proceeded by 50 EJBs from the pool in >>> one >>> second. >>> After 1000 seconds how many new EJB Instances will be created >>> having >>> a pool? answer 0 new EJBs worst case 100 EJB’s in pool… of course >>> object allocation is much higher as of course 1 EJB call leads to >>> many Object from one EJB but…let see situation without pool. >>> >>> 50 Request/s * 1000 seconds = worst case 50’ 000 EJB Instances on >>> Java heap where 1 EJB might have many objects… as long as >>> Garbage >>> Collection was not triggered… which sounds to me like faster >>> filling >>> JVM heap and having ofter GC probable depending on GC Strategy. >>> >>> Scenarion 2) >>> ------------------ >>> Same as before, Load is still 50 Requests per second BUT EJB >>> Method >>> call takes 10s. >>> after 10s we have 500 EJB Instances without pool, after 11s 550 - >>> 10 >>> = 540EJB Instances , after 12s 580 EJBs … after some time very >>> bad >>> perf…full GC …and mabe OutOfMemory.. >>> >>> So… performance advantage could also turn in to disadvantage :-) >>> >>> >>>> Whoever is investigating StrictMaxPool, or EJB pooling in general >>>> should >>>> stop. Its pointless. >>> >>> Agree, pools are outdated…. but something like WorkManager for >>> min, >>> max Threads or even better always not less the X idle Threads >>> would >>> be useful :-) >>> >>> Radek >>> >> >> The scenarios above are what is outddated. Fifty requests per >> second isn't any load at all! We have 100's of thousands of >> clients that we have to scale to, and lots more than 50 requests >> per second. >> > What you mean to say is that you need to scale to 100's of thousands > of > clients on meaningless no-op benchmarks. :) I do know that that old > SpecJ Java EE benchmarks artifically made EJB pooling important as > process intensive calculation results were cached in these instances. > But real-world apps don't use this feature/anti-pattern. > I am not talking about a meaningless no-op benchmark, but a benchmark that does lots of work. We don't use meaningless no-op benchmarks on the performance team, with some exception for microbenchmarks that we have carefully crafted that model the interactions for a specific component within the context of how it is actually used for a real application. > Also however crappy it was, I did implement an EJB container at one > time > in my career. :) I know for a fact that there are a number of > per-request internal support objects that need to be allocated. > Let's > count: > > * The argument array (for reflection) > * Each argument of the method call > * The response object > * Interceptor context object > * The interceptor context attribute map > * EJBContext > * Subject, Principal, role mappings > * Transaction context > * The message object(s) specific to the remote EJB protocol > > Starts to add up huh? I'm probably missing a bunch more. Throw in > interaction with JPA and you end up with even more per-request > objects > being allocated. You still believe pooling one EJB instance matters? > See John O'Hara's post which shows our non-meaningless benchmark and the difference that pooling makes vs. non-pooling. It is a dramatic difference to say the least.

This conversation is a perfect example of misinformation that causes us performance and scalability problems within our code bases.