Pooling EJB Session Beans per default

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Pooling EJB Session Beans per default

Ralph Soika
Hi,

I want to discuss the topic of Session Bean Pooling in WildFly. I know that there was a discussion in the past to disable pooling of EJB Session Beans per default in WildFly.
I understand when you argue that pooling a session bean is not faster than creating the bean from scratch each time a method is called. From the perspective of a application server developer this is a clear and easy decision. But from the view of an application developer this breaks one of the main concepts of session beans - the pooling.
As a application developer I suppose my bean is pooled and I can use one of the life-cycle annotations to control my bean. This is a basic concept for all kind of beans. First I thought it could be a compromise to pool only these beans which have a life-cycle annotation. But this isn't a solution.
Knowing that my bean will be pooled allows me - as a component developer - to use this as a caching mechanism. For example time intensive routines can also cache results in a local variable to be used next time a method is called. This isn't a bad practice and can increase performance of my component depending on the pool settings.

So my suggestion is to pool also stateless session ejbs in the future. I guess form the specification there is no duty to pool beans. So there is nothing wrong when not pooling beans. And again I don't want to criticize. But at the end not pooling will decrease the performance of WildFly. Not the container itself but the applications running in WildFly.
It takes me a long time to figure out why my application was a little bit slower in WildFly than in GlassFish until I recognized the missing pooling. I can activate pooling and everything is cool. But I guess some other application developers will only see that there application is slower in WildFly than on other application servers.
And this will effect their decision. That is the argument to activate the pool per default.

best regards
Ralph


--
Imixs...extends the way people work together
We are an open source company, read more at: www.imixs.org

Imixs Software Solutions GmbH
Agnes-Pockels-Bogen 1, 80992 München
Web: www.imixs.com
Office: +49 (0)89-452136 16 Mobil: +49-177-4128245
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsfuehrer: Gaby Heinle u. Ralph Soika

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Wolf-Dieter Fink
Hi Ralph,

as I said in your community thread (https://community.jboss.org/thread/242999) it is not only the problem to add a pool for it.
At the moment there is only the strict-max-pool which limit the total number of beans pooled - and also the total number of beans which can be used in parallel.
So that means adding the pool is a performance issue, which can make the situation better or worse depend on the application.
So you need to adjust it depend on your needs.

If there is another implementation of a pool, i.e.  which allow to have x pooled instances and more if needed, the pool might be back as default.
For the moment it is makes no difference or is faster (in most cases) without pooling.

- Wolf

On 21/07/14 18:16, Ralph Soika wrote:
Hi,

I want to discuss the topic of Session Bean Pooling in WildFly. I know that there was a discussion in the past to disable pooling of EJB Session Beans per default in WildFly.
I understand when you argue that pooling a session bean is not faster than creating the bean from scratch each time a method is called. From the perspective of a application server developer this is a clear and easy decision. But from the view of an application developer this breaks one of the main concepts of session beans - the pooling.
As a application developer I suppose my bean is pooled and I can use one of the life-cycle annotations to control my bean. This is a basic concept for all kind of beans. First I thought it could be a compromise to pool only these beans which have a life-cycle annotation. But this isn't a solution.
Knowing that my bean will be pooled allows me - as a component developer - to use this as a caching mechanism. For example time intensive routines can also cache results in a local variable to be used next time a method is called. This isn't a bad practice and can increase performance of my component depending on the pool settings.

So my suggestion is to pool also stateless session ejbs in the future. I guess form the specification there is no duty to pool beans. So there is nothing wrong when not pooling beans. And again I don't want to criticize. But at the end not pooling will decrease the performance of WildFly. Not the container itself but the applications running in WildFly.
It takes me a long time to figure out why my application was a little bit slower in WildFly than in GlassFish until I recognized the missing pooling. I can activate pooling and everything is cool. But I guess some other application developers will only see that there application is slower in WildFly than on other application servers.
And this will effect their decision. That is the argument to activate the pool per default.

best regards
Ralph


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Ralph Soika
Hi Wolf,

thanks for your answer. Ok I will no longer ask for this default setting ;-)
As long as it is possible to configure the pool according to the requirements of a deployed application there is not problem. WildFly now works great and really fast in my case.

Thanks again.

===
Ralph

On 21.07.2014 19:39, Wolf-Dieter Fink wrote:
Hi Ralph,

as I said in your community thread (https://community.jboss.org/thread/242999) it is not only the problem to add a pool for it.
At the moment there is only the strict-max-pool which limit the total number of beans pooled - and also the total number of beans which can be used in parallel.
So that means adding the pool is a performance issue, which can make the situation better or worse depend on the application.
So you need to adjust it depend on your needs.

If there is another implementation of a pool, i.e.  which allow to have x pooled instances and more if needed, the pool might be back as default.
For the moment it is makes no difference or is faster (in most cases) without pooling.

- Wolf

On 21/07/14 18:16, Ralph Soika wrote:
Hi,

I want to discuss the topic of Session Bean Pooling in WildFly. I know that there was a discussion in the past to disable pooling of EJB Session Beans per default in WildFly.
I understand when you argue that pooling a session bean is not faster than creating the bean from scratch each time a method is called. From the perspective of a application server developer this is a clear and easy decision. But from the view of an application developer this breaks one of the main concepts of session beans - the pooling.
As a application developer I suppose my bean is pooled and I can use one of the life-cycle annotations to control my bean. This is a basic concept for all kind of beans. First I thought it could be a compromise to pool only these beans which have a life-cycle annotation. But this isn't a solution.
Knowing that my bean will be pooled allows me - as a component developer - to use this as a caching mechanism. For example time intensive routines can also cache results in a local variable to be used next time a method is called. This isn't a bad practice and can increase performance of my component depending on the pool settings.

So my suggestion is to pool also stateless session ejbs in the future. I guess form the specification there is no duty to pool beans. So there is nothing wrong when not pooling beans. And again I don't want to criticize. But at the end not pooling will decrease the performance of WildFly. Not the container itself but the applications running in WildFly.
It takes me a long time to figure out why my application was a little bit slower in WildFly than in GlassFish until I recognized the missing pooling. I can activate pooling and everything is cool. But I guess some other application developers will only see that there application is slower in WildFly than on other application servers.
And this will effect their decision. That is the argument to activate the pool per default.

best regards
Ralph



--
Imixs...extends the way people work together
We are an open source company, read more at: www.imixs.org

Imixs Software Solutions GmbH
Agnes-Pockels-Bogen 1, 80992 München
Web: www.imixs.com
Office: +49 (0)89-452136 16 Mobil: +49-177-4128245
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsfuehrer: Gaby Heinle u. Ralph Soika

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Andrig Miller
In reply to this post by Wolf-Dieter Fink
Considering our benchmarking work through our performance team we have actually discovered that we actually need pooling of Stateless Session beans, because of memory allocation rates being too high.

Allocating objects is fast in the latest JVM's, that's for sure, but you can easily create a situation where the memory allocation rate becomes too high, and you start getting excessive GC overhead.

With that in mind, we have recently created (John O'Hara did the work from the middle-ware performance team), a new implementation of the StrictMaxPool.  That implementation uses a ConcurrentLinkedQueue as the underlying data structure, as the original used a simple LinkedList with synchronization, so essentially all accesses to the pool were serialized.  So, this didn't scale.  The new implementation is upstream in Wildfly 9.  There is no configuration change necessary, as it replaces the old implementation and is compatible.

Like everything, there are tradeoffs, and the mantra that has spread recently that pooling is bad, is simply not the case.  In some cases, allocating an object everytime is the best approach, in others cases pooling will be the best approach.

Fortunately, you can do either in Wildfly (and EAP).  Like always, you have to test your specific application, in the properly configured environment to know for sure.

Andy


From: "Wolf-Dieter Fink" <[hidden email]>
To: "Ralph Soika" <[hidden email]>, [hidden email]
Sent: Monday, July 21, 2014 11:39:12 AM
Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default

Hi Ralph,

as I said in your community thread (https://community.jboss.org/thread/242999) it is not only the problem to add a pool for it.
At the moment there is only the strict-max-pool which limit the total number of beans pooled - and also the total number of beans which can be used in parallel.
So that means adding the pool is a performance issue, which can make the situation better or worse depend on the application.
So you need to adjust it depend on your needs.

If there is another implementation of a pool, i.e.  which allow to have x pooled instances and more if needed, the pool might be back as default.
For the moment it is makes no difference or is faster (in most cases) without pooling.

- Wolf

On 21/07/14 18:16, Ralph Soika wrote:
Hi,

I want to discuss the topic of Session Bean Pooling in WildFly. I know that there was a discussion in the past to disable pooling of EJB Session Beans per default in WildFly.
I understand when you argue that pooling a session bean is not faster than creating the bean from scratch each time a method is called. From the perspective of a application server developer this is a clear and easy decision. But from the view of an application developer this breaks one of the main concepts of session beans - the pooling.
As a application developer I suppose my bean is pooled and I can use one of the life-cycle annotations to control my bean. This is a basic concept for all kind of beans. First I thought it could be a compromise to pool only these beans which have a life-cycle annotation. But this isn't a solution.
Knowing that my bean will be pooled allows me - as a component developer - to use this as a caching mechanism. For example time intensive routines can also cache results in a local variable to be used next time a method is called. This isn't a bad practice and can increase performance of my component depending on the pool settings.

So my suggestion is to pool also stateless session ejbs in the future. I guess form the specification there is no duty to pool beans. So there is nothing wrong when not pooling beans. And again I don't want to criticize. But at the end not pooling will decrease the performance of WildFly. Not the container itself but the applications running in WildFly.
It takes me a long time to figure out why my application was a little bit slower in WildFly than in GlassFish until I recognized the missing pooling. I can activate pooling and everything is cool. But I guess some other application developers will only see that there application is slower in WildFly than on other application servers.
And this will effect their decision. That is the argument to activate the pool per default.

best regards
Ralph


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

David Lloyd-2
Yeah I think we don't necessarily want the takeaway here to be that
pooling is, in general, bad.  It's just that our implementations needed
(and still need) some more thought.  I believe there are still a few
stones yet unturned in this area.

On 08/04/2014 05:59 PM, Andrig Miller wrote:

> Considering our benchmarking work through our performance team we have
> actually discovered that we actually need pooling of Stateless Session
> beans, because of memory allocation rates being too high.
>
> Allocating objects is fast in the latest JVM's, that's for sure, but you
> can easily create a situation where the memory allocation rate becomes
> too high, and you start getting excessive GC overhead.
>
> With that in mind, we have recently created (John O'Hara did the work
> from the middle-ware performance team), a new implementation of the
> StrictMaxPool.  That implementation uses a ConcurrentLinkedQueue as the
> underlying data structure, as the original used a simple LinkedList with
> synchronization, so essentially all accesses to the pool were
> serialized.  So, this didn't scale.  The new implementation is upstream
> in Wildfly 9.  There is no configuration change necessary, as it
> replaces the old implementation and is compatible.
>
> Like everything, there are tradeoffs, and the mantra that has spread
> recently that pooling is bad, is simply not the case.  In some cases,
> allocating an object everytime is the best approach, in others cases
> pooling will be the best approach.
>
> Fortunately, you can do either in Wildfly (and EAP).  Like always, you
> have to test your specific application, in the properly configured
> environment to know for sure.
>
> Andy
>
> ------------------------------------------------------------------------
>
>     *From: *"Wolf-Dieter Fink" <[hidden email]>
>     *To: *"Ralph Soika" <[hidden email]>, [hidden email]
>     *Sent: *Monday, July 21, 2014 11:39:12 AM
>     *Subject: *Re: [wildfly-dev] Pooling EJB Session Beans per default
>
>     Hi Ralph,
>
>     as I said in your community thread
>     (https://community.jboss.org/thread/242999) it is not only the
>     problem to add a pool for it.
>     At the moment there is only the strict-max-pool which limit the
>     total number of beans pooled - and also the total number of beans
>     which can be used in parallel.
>     So that means adding the pool is a performance issue, which can make
>     the situation better or worse depend on the application.
>     So you need to adjust it depend on your needs.
>
>     If there is another implementation of a pool, i.e.  which allow to
>     have x pooled instances and more if needed, the pool might be back
>     as default.
>     For the moment it is makes no difference or is faster (in most
>     cases) without pooling.
>
>     - Wolf
>
>     On 21/07/14 18:16, Ralph Soika wrote:
>
>         Hi,
>
>         I want to discuss the topic of Session Bean Pooling in WildFly.
>         I know that there was a discussion in the past to disable
>         pooling of EJB Session Beans per default in WildFly.
>         I understand when you argue that pooling a session bean is not
>         faster than creating the bean from scratch each time a method is
>         called. From the perspective of a application server developer
>         this is a clear and easy decision. But from the view of an
>         application developer this breaks one of the main concepts of
>         session beans - the pooling.
>         As a application developer I suppose my bean is pooled and I can
>         use one of the life-cycle annotations to control my bean. This
>         is a basic concept for all kind of beans. First I thought it
>         could be a compromise to pool only these beans which have a
>         life-cycle annotation. But this isn't a solution.
>         Knowing that my bean will be pooled allows me - as a component
>         developer - to use this as a caching mechanism. For example time
>         intensive routines can also cache results in a local variable to
>         be used next time a method is called. This isn't a bad practice
>         and can increase performance of my component depending on the
>         pool settings.
>
>         So my suggestion is to pool also stateless session ejbs in the
>         future. I guess form the specification there is no duty to pool
>         beans. So there is nothing wrong when not pooling beans. And
>         again I don't want to criticize. But at the end not pooling will
>         decrease the performance of WildFly. Not the container itself
>         but the applications running in WildFly.
>         It takes me a long time to figure out why my application was a
>         little bit slower in WildFly than in GlassFish until I
>         recognized the missing pooling. I can activate pooling and
>         everything is cool. But I guess some other application
>         developers will only see that there application is slower in
>         WildFly than on other application servers.
>         And this will effect their decision. That is the argument to
>         activate the pool per default.
>
>         best regards
>         Ralph
>
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email]
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Bill Burke
In reply to this post by Andrig Miller
I always liked the ThreadLocal pool.   No synchronization, little to no
allocations.

On 8/4/2014 6:59 PM, Andrig Miller wrote:

> Considering our benchmarking work through our performance team we have
> actually discovered that we actually need pooling of Stateless Session
> beans, because of memory allocation rates being too high.
>
> Allocating objects is fast in the latest JVM's, that's for sure, but you
> can easily create a situation where the memory allocation rate becomes
> too high, and you start getting excessive GC overhead.
>
> With that in mind, we have recently created (John O'Hara did the work
> from the middle-ware performance team), a new implementation of the
> StrictMaxPool.  That implementation uses a ConcurrentLinkedQueue as the
> underlying data structure, as the original used a simple LinkedList with
> synchronization, so essentially all accesses to the pool were
> serialized.  So, this didn't scale.  The new implementation is upstream
> in Wildfly 9.  There is no configuration change necessary, as it
> replaces the old implementation and is compatible.
>
> Like everything, there are tradeoffs, and the mantra that has spread
> recently that pooling is bad, is simply not the case.  In some cases,
> allocating an object everytime is the best approach, in others cases
> pooling will be the best approach.
>
> Fortunately, you can do either in Wildfly (and EAP).  Like always, you
> have to test your specific application, in the properly configured
> environment to know for sure.
>
> Andy
>
> ------------------------------------------------------------------------
>
>     *From: *"Wolf-Dieter Fink" <[hidden email]>
>     *To: *"Ralph Soika" <[hidden email]>, [hidden email]
>     *Sent: *Monday, July 21, 2014 11:39:12 AM
>     *Subject: *Re: [wildfly-dev] Pooling EJB Session Beans per default
>
>     Hi Ralph,
>
>     as I said in your community thread
>     (https://community.jboss.org/thread/242999) it is not only the
>     problem to add a pool for it.
>     At the moment there is only the strict-max-pool which limit the
>     total number of beans pooled - and also the total number of beans
>     which can be used in parallel.
>     So that means adding the pool is a performance issue, which can make
>     the situation better or worse depend on the application.
>     So you need to adjust it depend on your needs.
>
>     If there is another implementation of a pool, i.e.  which allow to
>     have x pooled instances and more if needed, the pool might be back
>     as default.
>     For the moment it is makes no difference or is faster (in most
>     cases) without pooling.
>
>     - Wolf
>
>     On 21/07/14 18:16, Ralph Soika wrote:
>
>         Hi,
>
>         I want to discuss the topic of Session Bean Pooling in WildFly.
>         I know that there was a discussion in the past to disable
>         pooling of EJB Session Beans per default in WildFly.
>         I understand when you argue that pooling a session bean is not
>         faster than creating the bean from scratch each time a method is
>         called. From the perspective of a application server developer
>         this is a clear and easy decision. But from the view of an
>         application developer this breaks one of the main concepts of
>         session beans - the pooling.
>         As a application developer I suppose my bean is pooled and I can
>         use one of the life-cycle annotations to control my bean. This
>         is a basic concept for all kind of beans. First I thought it
>         could be a compromise to pool only these beans which have a
>         life-cycle annotation. But this isn't a solution.
>         Knowing that my bean will be pooled allows me - as a component
>         developer - to use this as a caching mechanism. For example time
>         intensive routines can also cache results in a local variable to
>         be used next time a method is called. This isn't a bad practice
>         and can increase performance of my component depending on the
>         pool settings.
>
>         So my suggestion is to pool also stateless session ejbs in the
>         future. I guess form the specification there is no duty to pool
>         beans. So there is nothing wrong when not pooling beans. And
>         again I don't want to criticize. But at the end not pooling will
>         decrease the performance of WildFly. Not the container itself
>         but the applications running in WildFly.
>         It takes me a long time to figure out why my application was a
>         little bit slower in WildFly than in GlassFish until I
>         recognized the missing pooling. I can activate pooling and
>         everything is cool. But I guess some other application
>         developers will only see that there application is slower in
>         WildFly than on other application servers.
>         And this will effect their decision. That is the argument to
>         activate the pool per default.
>
>         best regards
>         Ralph
>
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email]
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

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

The major problem I've seen in support cases related to StrictMaxPool is
the very arbitrary default size. I believe it used to be 30, and almost
no-one knew that they might need to tune it to fit their applications'
usage patterns and workload. Having a rising wait-time metric for the
pool indicates that it may be too small, but I believe the statistics
are disabled by default for performance reasons.


InfinitePool obviously doesn't have that problem, but it would have been
nicer if it had an idle period with expiry, like the JCA pools.

--
James "Doc" Livingston
JBoss Support Engineering Group

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Stuart Douglas
I have often thought that a possible solution would be an unbounded pool
that always keeps n instances around, but just creates new instances
instead of blocking if the pool is exhausted. In the majority of cases
new instance creation will be way more performant than blocking.

Stuart

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.
>
> The major problem I've seen in support cases related to StrictMaxPool is
> the very arbitrary default size. I believe it used to be 30, and almost
> no-one knew that they might need to tune it to fit their applications'
> usage patterns and workload. Having a rising wait-time metric for the
> pool indicates that it may be too small, but I believe the statistics
> are disabled by default for performance reasons.
>
>
> InfinitePool obviously doesn't have that problem, but it would have been
> nicer if it had an idle period with expiry, like the JCA pools.
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Andrig Miller
Your idea is something that I like as well.  You have a min, but no max, and no blocking for an instance if there isn't one immediately available.  The downside is its unbounded (I have also had customers tell me they needed a strict max option because they were delivering an application to their customers, and wanted to have strict control of the resources used), but it would be a nice compliment to what we have now.

On the old InfinitePool, using ThreadLocal, it was actually faster than the old StrictMaxPool, and it actually wasn't unbounded, because it would be bound by the thread pool size of the calling thread to the EJB instance.  While it was faster than the old StrictMaxPool, it was probably because of the serialized nature of the old implementation.

There is definitely room for additional implementations here.

Andy

----- Original Message -----

> From: "Stuart Douglas" <[hidden email]>
> To: "James Livingston" <[hidden email]>
> Cc: [hidden email]
> Sent: Monday, August 4, 2014 7:51:15 PM
> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
>
> I have often thought that a possible solution would be an unbounded
> pool
> that always keeps n instances around, but just creates new instances
> instead of blocking if the pool is exhausted. In the majority of
> cases
> new instance creation will be way more performant than blocking.
>
> Stuart
>
> 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.
> >
> > The major problem I've seen in support cases related to
> > StrictMaxPool is
> > the very arbitrary default size. I believe it used to be 30, and
> > almost
> > no-one knew that they might need to tune it to fit their
> > applications'
> > usage patterns and workload. Having a rising wait-time metric for
> > the
> > pool indicates that it may be too small, but I believe the
> > statistics
> > are disabled by default for performance reasons.
> >
> >
> > InfinitePool obviously doesn't have that problem, but it would have
> > been
> > nicer if it had an idle period with expiry, like the JCA pools.
> >
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Darran Lofthouse


On 05/08/14 14:07, Andrig Miller wrote:
> Your idea is something that I like as well.  You have a min, but no max, and no blocking for an instance if there isn't one immediately available.  The downside is its unbounded (I have also had customers tell me they needed a strict max option because they were delivering an application to their customers, and wanted to have strict control of the resources used), but it would be a nice compliment to what we have now.

Probably a decision that will vary depending on the deployment but if we
can limit the number of threads processing requests then having a second
limit on the pool could be argued as being redundant for many cases.

> On the old InfinitePool, using ThreadLocal, it was actually faster than the old StrictMaxPool, and it actually wasn't unbounded, because it would be bound by the thread pool size of the calling thread to the EJB instance.  While it was faster than the old StrictMaxPool, it was probably because of the serialized nature of the old implementation.
>
> There is definitely room for additional implementations here.
>
> Andy
>
> ----- Original Message -----
>> From: "Stuart Douglas" <[hidden email]>
>> To: "James Livingston" <[hidden email]>
>> Cc: [hidden email]
>> Sent: Monday, August 4, 2014 7:51:15 PM
>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
>>
>> I have often thought that a possible solution would be an unbounded
>> pool
>> that always keeps n instances around, but just creates new instances
>> instead of blocking if the pool is exhausted. In the majority of
>> cases
>> new instance creation will be way more performant than blocking.
>>
>> Stuart
>>
>> 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.
>>>
>>> The major problem I've seen in support cases related to
>>> StrictMaxPool is
>>> the very arbitrary default size. I believe it used to be 30, and
>>> almost
>>> no-one knew that they might need to tune it to fit their
>>> applications'
>>> usage patterns and workload. Having a rising wait-time metric for
>>> the
>>> pool indicates that it may be too small, but I believe the
>>> statistics
>>> are disabled by default for performance reasons.
>>>
>>>
>>> InfinitePool obviously doesn't have that problem, but it would have
>>> been
>>> nicer if it had an idle period with expiry, like the JCA pools.
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Bill Burke
In reply to this post by James Livingston


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.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Jaikiran Pai-2
I think it's important to remember that the application developers use
the @PostConstruct and @PreDestroy on stateless EJBs for initialization
and destroying certain application specific resources. In a non-pooled
case this is going to affect the performance and as has been noted, it's
ultimately something that each application needs to review. So this
isn't exactly the same as per-request objects, as far as I see it and
isn't just a case of Java object instantiation.

-Jaikiran
On Tuesday 05 August 2014 07:02 PM, Bill Burke wrote:

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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

David Lloyd-2
In reply to this post by Andrig Miller
I have always contended that the most appropriate place for throttling
server usage is at the front end.  If the number of incoming web and EJB
requests can be limited, then everything else probably should just be
unbounded (else you enter a configuration nightmare because *everything*
has knobs).  This way you can limit configuration to total incoming
requests, and specific resources that have to be limited (like DB
connections), and be assured of reasonable performance instead of having
to read the encyclopedia to figure out all the tuning parameters you
have to futz with.

On 08/05/2014 08:07 AM, Andrig Miller wrote:

> Your idea is something that I like as well.  You have a min, but no max, and no blocking for an instance if there isn't one immediately available.  The downside is its unbounded (I have also had customers tell me they needed a strict max option because they were delivering an application to their customers, and wanted to have strict control of the resources used), but it would be a nice compliment to what we have now.
>
> On the old InfinitePool, using ThreadLocal, it was actually faster than the old StrictMaxPool, and it actually wasn't unbounded, because it would be bound by the thread pool size of the calling thread to the EJB instance.  While it was faster than the old StrictMaxPool, it was probably because of the serialized nature of the old implementation.
>
> There is definitely room for additional implementations here.
>
> Andy
>
> ----- Original Message -----
>> From: "Stuart Douglas" <[hidden email]>
>> To: "James Livingston" <[hidden email]>
>> Cc: [hidden email]
>> Sent: Monday, August 4, 2014 7:51:15 PM
>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
>>
>> I have often thought that a possible solution would be an unbounded
>> pool
>> that always keeps n instances around, but just creates new instances
>> instead of blocking if the pool is exhausted. In the majority of
>> cases
>> new instance creation will be way more performant than blocking.
>>
>> Stuart
>>
>> 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.
>>>
>>> The major problem I've seen in support cases related to
>>> StrictMaxPool is
>>> the very arbitrary default size. I believe it used to be 30, and
>>> almost
>>> no-one knew that they might need to tune it to fit their
>>> applications'
>>> usage patterns and workload. Having a rising wait-time metric for
>>> the
>>> pool indicates that it may be too small, but I believe the
>>> statistics
>>> are disabled by default for performance reasons.
>>>
>>>
>>> InfinitePool obviously doesn't have that problem, but it would have
>>> been
>>> nicer if it had an idle period with expiry, like the JCA pools.
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Andrig Miller
In reply to this post by Bill Burke


----- Original Message -----

> From: "Bill Burke" <[hidden email]>
> To: "James Livingston" <[hidden email]>
> Cc: [hidden email]
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Andrig Miller
In reply to this post by David Lloyd-2
I tend to agree with you.  It does get very complicated very quickly with all the resource related configuration.  The more complex the workload, the more complex the configuration becomes.

Andy

----- Original Message -----

> From: "David M. Lloyd" <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, August 5, 2014 7:40:35 AM
> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
>
> I have always contended that the most appropriate place for
> throttling
> server usage is at the front end.  If the number of incoming web and
> EJB
> requests can be limited, then everything else probably should just be
> unbounded (else you enter a configuration nightmare because
> *everything*
> has knobs).  This way you can limit configuration to total incoming
> requests, and specific resources that have to be limited (like DB
> connections), and be assured of reasonable performance instead of
> having
> to read the encyclopedia to figure out all the tuning parameters you
> have to futz with.
>
> On 08/05/2014 08:07 AM, Andrig Miller wrote:
> > Your idea is something that I like as well.  You have a min, but no
> > max, and no blocking for an instance if there isn't one
> > immediately available.  The downside is its unbounded (I have also
> > had customers tell me they needed a strict max option because they
> > were delivering an application to their customers, and wanted to
> > have strict control of the resources used), but it would be a nice
> > compliment to what we have now.
> >
> > On the old InfinitePool, using ThreadLocal, it was actually faster
> > than the old StrictMaxPool, and it actually wasn't unbounded,
> > because it would be bound by the thread pool size of the calling
> > thread to the EJB instance.  While it was faster than the old
> > StrictMaxPool, it was probably because of the serialized nature of
> > the old implementation.
> >
> > There is definitely room for additional implementations here.
> >
> > Andy
> >
> > ----- Original Message -----
> >> From: "Stuart Douglas" <[hidden email]>
> >> To: "James Livingston" <[hidden email]>
> >> Cc: [hidden email]
> >> Sent: Monday, August 4, 2014 7:51:15 PM
> >> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
> >>
> >> I have often thought that a possible solution would be an
> >> unbounded
> >> pool
> >> that always keeps n instances around, but just creates new
> >> instances
> >> instead of blocking if the pool is exhausted. In the majority of
> >> cases
> >> new instance creation will be way more performant than blocking.
> >>
> >> Stuart
> >>
> >> 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.
> >>>
> >>> The major problem I've seen in support cases related to
> >>> StrictMaxPool is
> >>> the very arbitrary default size. I believe it used to be 30, and
> >>> almost
> >>> no-one knew that they might need to tune it to fit their
> >>> applications'
> >>> usage patterns and workload. Having a rising wait-time metric for
> >>> the
> >>> pool indicates that it may be too small, but I believe the
> >>> statistics
> >>> are disabled by default for performance reasons.
> >>>
> >>>
> >>> InfinitePool obviously doesn't have that problem, but it would
> >>> have
> >>> been
> >>> nicer if it had an idle period with expiry, like the JCA pools.
> >>>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

jtgreene
Administrator
In reply to this post by Andrig Miller

On Aug 5, 2014, at 8:43 AM, Andrig Miller <[hidden email]> wrote:

>
>
> ----- Original Message -----
>> From: "Bill Burke" <[hidden email]>
>> To: "James Livingston" <[hidden email]>
>> Cc: [hidden email]
>> 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.

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.

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.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Bill Burke


On 8/5/2014 10:15 AM, Jason Greene wrote:
>> 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.
>
> 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'm more worried about focus rather than the actual benchmarks
considering how resource strapped every project seems to be.  I'd like
to see a discussion started on what are the most important and *ripe*
areas for optimization and then have the performance team validate and
make recommendations on any priority list that this discussion generates.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

Bill Burke


On 8/5/2014 10:32 AM, Bill Burke wrote:

>
>
> On 8/5/2014 10:15 AM, Jason Greene wrote:
>>> 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.
>>
>> 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'm more worried about focus rather than the actual benchmarks
> considering how resource strapped every project seems to be.  I'd like
> to see a discussion started on what are the most important and *ripe*
> areas for optimization and then have the performance team validate and
> make recommendations on any priority list that this discussion generates.
>

Furthermore, if we put efforts into a particularly ripe area for
optimization and there exists no popular benchmark to showcase these
efforts, then create one, open source it, and promote it.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

jtgreene
Administrator
In reply to this post by Bill Burke

On Aug 5, 2014, at 9:32 AM, Bill Burke <[hidden email]> wrote:

>
>
> On 8/5/2014 10:15 AM, Jason Greene wrote:
>>> 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.
>>
>> 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'm more worried about focus rather than the actual benchmarks considering how resource strapped every project seems to be.  I'd like to see a discussion started on what are the most important and *ripe* areas for optimization and then have the performance team validate and make recommendations on any priority list that this discussion generates.

The pooling concerns (aside from the occasional expensive post constructs) actually came from a large app/benchmark that the perf team was testing, and they were seeing an optimized strict max pool outperform no pooling at all, and it wasn’t post construct. Their theory is/was GC pressure, because this benchmark/app spends a lot of time in GC, and they see higher GC activity with no pooling. It’s possible it could be an indirect difference though, like the fact that strict max pool acts as a throttle might prevent the system from degrading as a result of no longer being able to keep up with the benchmark load.

Another possibility to look into is that I see we do:
   interceptorContext.setContextData(new HashMap<String, Object>());

*AND*

    private Map<Object, Object> instanceData = new HashMap<Object, Object>();


Aside from the unnecessary overhead, since JDK7, HashMap construction uses the murmur algorithm which requires using a random number generation under global locking. There were plans to optimize this, but it might not be in JDK7 yet. In a few places we use alternative map implementations to work around the issue.


--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pooling EJB Session Beans per default

jtgreene
Administrator

On Aug 5, 2014, at 9:51 AM, Jason Greene <[hidden email]> wrote:

>
> On Aug 5, 2014, at 9:32 AM, Bill Burke <[hidden email]> wrote:
>
>>
>>
>> On 8/5/2014 10:15 AM, Jason Greene wrote:
>>>> 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.
>>>
>>> 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'm more worried about focus rather than the actual benchmarks considering how resource strapped every project seems to be.  I'd like to see a discussion started on what are the most important and *ripe* areas for optimization and then have the performance team validate and make recommendations on any priority list that this discussion generates.
>
> The pooling concerns (aside from the occasional expensive post constructs) actually came from a large app/benchmark that the perf team was testing, and they were seeing an optimized strict max pool outperform no pooling at all, and it wasn’t post construct. Their theory is/was GC pressure, because this benchmark/app spends a lot of time in GC, and they see higher GC activity with no pooling. It’s possible it could be an indirect difference though, like the fact that strict max pool acts as a throttle might prevent the system from degrading as a result of no longer being able to keep up with the benchmark load.
>
> Another possibility to look into is that I see we do:
>   interceptorContext.setContextData(new HashMap<String, Object>());
>
> *AND*
>
>    private Map<Object, Object> instanceData = new HashMap<Object, Object>();
>
>
> Aside from the unnecessary overhead, since JDK7, HashMap construction uses the murmur algorithm which requires using a random number generation under global locking. There were plans to optimize this, but it might not be in JDK7 yet. In a few places we use alternative map implementations to work around the issue.
>

Looks like a fix for this is actually in u40+, although we still should reduce those allocations.

http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b03bbdef3a88


--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
123