Yes, one pool and allocation by weight.
Cheers,
/Jesper
2007/11/22, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com>:
>
> Salut,
>
> Jesper Söderlund wrote:
> > Hmm, yes those two articles certainly point the way.
> >
> > Any idea when a RCM functionality would be a supported option in
> Glassfish?
>
> It is a supported options in v2, but not enabled by default. The
> configuration part needs to be improved (via admin-gui)..I agree :-)
>
>
> >
> > Some comments on the policies:
> > - reservation - This means that we have to over-allocate resources which
> > are then partitioned into separate "pools", this way to allocating a
> > percentage to each app is rather cumbersome to manage (even if there was
> > a snazzy GUI instead of the system properties) since the balance will
> > need to be reconfigured with each new application deployed.
>
> Indeed. Every request to a newly deployed application will be rejected
> (503) if the other deployed applications have reserved 100% of the
> thread pool. But you can always leave a small amount of the thread count
> available (let's say 10%).
>
> >
> > - ceiling - Unfortunatly I did not fully understand the semantics of the
> > ceiling policy, but I venture a guess that it's a common pool and that
> > an app is maximally allowed a certain percentage allocation from that
> > pool, else it will block for a while, this seems quite restrictive but
> > is effective at blocking "run-away" applications so it could be useful
> > to set the ceiling quite high to prevent DDoS type of attacks (or bugs
> > with the similar effect)
>
> Right. The main difference between the two is with reservation, if App A
> has 30% allocated threads, App B 50%, and 20% left for other
> application, if App A needs more that 30%, it can always use the 20%
> unallocated. With ceiling, if 30% of the threads are used, then requests
> to App A will not be executed (but instead parked...similar to a
> continuation).
>
> >
> > I'd also like to see a pool with a weighted policy where each app is
> > allocated a weight and the resources allocated according to that weight,
>
> If I understand you correctly, one thread pool but a dispatcher that
> pick up threads from the pool using the weight?
>
>
> > that would be much more robust, in terms of administration at least,
> > incidentally this is also one of the algorithm available in Solaris
> > resource management, perhaps some lessons can be learned from that?
>
> Agree. The RCM stuff is probably really similar to zones as well.
>
> The
> > weight per application should be configurable in the deployment
> > description as well as in the admin GUI to override the deployment
> > descriptor value. Applications which don't have a value would be
> > assigned a default value.
> >
>
> Agree. I've filled this but never has a chance to fix it:
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=3058
>
> > Though I understand the motivation for having a default policy which
> > optimizes on performance as that is quite visible in benchmarks, etc,
> > but I think it would better if an policy which would prioritize fairness
> > between applications would be just as easily configured or maybe even
> > the default and the performance policy the exception which is configured
> > for benchmark tests.
>
> Agree. You should reply to the v3 discussion in GlassFish asking to have
> rcm enabled by default and better supported. I will speak on my side as
> well :-)
>
> A+
>
> -- Jeanfrancois
>
> >
> > cheers,
> > /Jesper
> >
> >
> >
> > 2007/11/21, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com
> > <mailto:Jeanfrancois.Arcand_at_sun.com>>:
> >
> > Salut,
> >
> > Jesper Söderlund wrote:
> > > I wonder if somebody could enlighten me with regards to the
> > fairness of
> > > processing requests in Glassfish / Grizzly under load.
> >
> > By default, same fairness for every requests are applied, meaning
> the
> > first requests that comes in is always the first executed (something
> > Tomcat doesn't do). This is quite important and one of the reason
> why we
> > have good score with specJ2004: all requests have the same chance to
> be
> > executed. This is the SEDA part of Grizzly that allow use to do that
> :-)
> >
> > >
> > > Is there some some guarantee that one heavily loaded application
> will
> > > not hog all the resources from another using the same grizzly
> > instance?
> >
> > By default, if an application takes more CPU/resources than the
> other,
> > Grizzly doesn't have a mechanism to isolate the application by
> default.
> > I said by default because Grizzly have a extension (with both 1.0and
> > 1.5) that allow resource consumptions management [1]. This is
> something
> > you should take alook.
> >
> > >
> > > Is the only way to "partion" the resources to create separate
> HTTP
> > > listeners?
> >
> > No, see [2] for a good example.
> >
> > >
> > > Will these threads configured for the HTTP-listener run through
> the
> > > servlet container and down into the EJB-container?
> >
> > Yes.
> >
> > >
> > > It would be great to be able to specify a weight for an
> > application in
> > > the deployment descriptor and have the request processing
> scheduled
> > > accordingly.
> >
> > Look at [1][2] :-) This is exactly what you need. 4homemedia.com
> > <http://4homemedia.com>
> > combined [2] with Grizzly Comet for their application and they told
> me
> > their performance has improved by isolating applications.
> >
> > Thanks!
> >
> > -- Jeanfrancois
> >
> > [1]
> >
> http://weblogs.java.net/blog/jfarcand/archive/2006/04/resource_consum.html
> > <
> http://weblogs.java.net/blog/jfarcand/archive/2006/04/resource_consum.html
> >
> > [2]
> >
> http://weblogs.java.net/blog/jfarcand/archive/2007/06/improving_ajax_1.html
> >
> > >
> > > /Jesper
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> > <mailto:users-unsubscribe_at_grizzly.dev.java.net>
> > For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> > <mailto:users-help_at_grizzly.dev.java.net>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>