Request based Priority Queues

[Bernhard Froehlich]

Hi List.

Has anyone of you guys ever played with Request based Priority Queues [1]
using Helma? Common cases where you need that are mostly to reduce latency
for some Sessions (admins, ...) or URIs (webservices, ajax ...) under high
load.

There are various places where connections are pooled when using Apache
and mod_jk so an absolutely correct solution might need to modify mod_jk,
jetty and helma but i really want to avoid hacking all of them.


* AFAIK mod_jk only has the functionality to route specific URIs to
different workers but that seems a bit hackish to me because you would
need an mostly idle worker to get good results.

* On the Jetty side it would be possible to write an Filter [2] that
respects that priority but i am not sure how much that would help because
it heavily depends on the ratio of the mod_jk and jetty poolsize and seems
to need Jetty 7.0 which is experimental at this time.

In Helma the only thing that is left to do is to include the priority
somewhere in the cookies to help the Filter making the right decision.


Maybe someone with a better knowledge of the architecture could shed some
light on a good solution.

Kind regards,
Bernhard Fröhlich

[1]
http://weblogs.java.net/blog/jfarcand/archive/2007/06/improving_ajax_1.html
[2]
http://svn.codehaus.org/jetty/jetty/trunk/modules/extra/jetty-servlet/src/main/java/org/mortbay/servlet/QoSFilter.java

_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user

[Joshua Paine]

On Wed, 2008-06-04 at 00:44 +0200, Bernhard Froehlich wrote:
> ever played with Request based Priority Queues [1]

No, I haven't--with Helma nor anything else. I have only the tiny, tiny
suggestion to add of looking at mod_proxy instead of mod_jk. It's a lot
easier to setup and seems pretty much to supersede mod_jk.

> * AFAIK mod_jk only has the functionality to route specific URIs to
> different workers but that seems a bit hackish to me because you would
> need an mostly idle worker to get good results.

mod_proxy can do the same, plus a host of powerful connection pooling
and load balancing things that I can't say I've yet had to deal with.
(Nor do I know if it's actually more than mod_jk has.) I'm not sure that
this materially differs from what's proposed in the article you linked,
though. They're mostly talking about setting aside X threads to serve
high-priority requests--it's still possible that you'll have too many
high-priority requests. Your only assurance is that they only have to
wait for other high-priority requests and not the lower-priority ones.

This is far from my area of expertise, so I apologize if this is all
blowing smoke.

--
Joshua Paine <joshua@...>

_______________________________________________
Helma-user mailing list
Helma-user@...
http://helma.org/mailman/listinfo/helma-user