Hmm, yes those two articles certainly point the way.
Any idea when a RCM functionality would be a supported option in Glassfish?
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.
- 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)
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,
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? 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.
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.
cheers,
/Jesper
2007/11/21, Jeanfrancois Arcand <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.0 and
> 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
> 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
> [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
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>