<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div style=""><br><div>Anfang der weitergeleiteten Nachricht:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Von: </b></span><span style="font-family:'Helvetica';">Radoslaw Rodak <<a href="mailto:rodakr@gmx.ch">rodakr@gmx.ch</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Betreff: </b></span><span style="font-family:'Helvetica';"><b>Aw: [wildfly-dev] Pooling EJB Session Beans per default</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Datum: </b></span><span style="font-family:'Helvetica';">6. August 2014 19:14:18 MESZ<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>An: </b></span><span style="font-family:'Helvetica';">Jason Greene <<a href="mailto:jason.greene@redhat.com">jason.greene@redhat.com</a>><br></span></div><br><div><br>Am 06.08.2014 um 17:13 schrieb Jason Greene <<a href="mailto:jason.greene@redhat.com">jason.greene@redhat.com</a>>:<br><br><blockquote type="cite"><br>On Aug 5, 2014, at 7:51 PM, Radoslaw Rodak <<a href="mailto:rodakr@gmx.ch">rodakr@gmx.ch</a>> wrote:<br><br><blockquote type="cite"><br>Am 06.08.2014 um 00:36 schrieb Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>:<br><br><blockquote type="cite"><br><br>On 8/5/2014 3:54 PM, Andrig Miller wrote:<br><blockquote type="cite"><blockquote type="cite">Its a horrible theory. :) How many EJB instances of a give type are<br>created per request? Generally only 1. 1 instance of one object of<br>one<br>type! My $5 bet is that if you went into EJB code and started<br>counting<br>how many object allocations were made per request, you'd lose count<br>very<br>quickly. Better yet, run a single remote EJB request through a perf<br>tool and let it count the number of allocations for you. It will be<br>greater than 1. :)<br><br>Maybe the StrictMaxPool has an effect on performance because it<br>creates<br>a global synchronization bottleneck. Throughput is less and you end<br>up<br>having less concurrent per-request objects being allocated and GC'd.<br><br></blockquote><br>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.<br><br></blockquote><br>I'm saying that the number of concurrent requests might not dictate <br>object allocation rate. There are probably a number of allocations that <br>happen after the EJB instance is obtained. i.e. interception chains, <br>contexts, etc. If StrictMaxPool blocks until a new instance is <br>available, then there would be less allocations per request as blocking <br>threads would be serialized.<br><br></blockquote><br>Scenarion 1 )<br>------------------<br>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.<br>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.<br><br>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. <br></blockquote><br>If you think about a single Java EE request invocation that processes data with one EJB in the call, there is typically hundreds of temporary objects created (perhaps even thousands when you are pulling back many rows of data from JPA). Aside from the container API requirements (the container has to create a string for every http header name and value, which can easily be 20+ objects), just writing plain java code that does things like substring creates temporary objects. Now, I don’t have an exact object instance count for an SLSB creation, but glancing at the code it looks ~ 6 objects. So we are talking about a very small percentage of object space, probably around 1-2%.<br><br>On the other hand the percentage could be high if you have an ejb method that doesn’t do much (e.g. just returns a constant) and you call it in a big loop as part of a request. Then you could get 6 * N object churn, which could very well end up to be a high percentage (for a large enough value of N).<br><br></blockquote><br>This is exactly what I was trying to point! <br><br><br><br><blockquote type="cite">--<br>Jason T. Greene<br>WildFly Lead / JBoss EAP Platform Architect<br>JBoss, a division of Red Hat<br><br></blockquote><br></div></blockquote></div><br></body></html>