You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2006/05/27 15:58:54 UTC
conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
(ignore issues of support for particular versions of Apache)
google pretends to know a lot about this general question, but it
seems to be in discussions between general users with the same
curiosity and there is little or no developer input. OTOH, there is a
great indication that Tomcat connector FAQ and httpd documentation
could help a lot of people by presenting the same conclusion, whatever
that happens to be ;)
Are there key design issues which will make one better than the other
assuming each has enough developer attention to fix code bugs?
Are there still fundamental pieces missing from mod_proxy_ajp +
mod_proxy_balancer which have to be resolved before mod_proxy_ajp is
the natural solution for anybody on Apache >= 2.2?
When should somebody use mod_proxy_http [+ mod_proxy_balancer] instead
of one of these solutions?
The Tomcat connectors FAQ says this:
---snip----
# mod_jk is great and should be used for production. It is getting
fixes as needed (which is now rare).
# mod_proxy. A cheap way to proxy without the hassles of configuring
JK. This solution lacks sticky session load balancing. If you don't
need some of the features of jk, jk2 - this is a very simple
alternative.
# mod_proxy_ajp. With apache 2.2, mod_proxy was rewritten to support
load balancing as well as a new transport called mod_proxy_ajp. This
module is distributed with the Apache http server, not the Tomcat
server.
---snip---
Isn't pass-through of client SSL connection information another
problem with mod_proxy? (servlets can't access cipher or client
certificate)
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 31, 2006, at 9:59 AM, Graham Leggett wrote:
> On Wed, May 31, 2006 3:47 pm, Jim Jagielski wrote:
>
>> Of course, there is a growing school of thought that questions
>> whether the whole AJP stuff itself is worthwhile... just
>> proxy HTTP and be done with it. :)
>
> This was a question raised way back when before the ajp work
> started, the
> question was whether mod_jk or mod_proxy_http was faster. It turned
> out
> mod_jk was faster, and so we have mod_proxy_ajp, but that was in
> the days
> before mod_proxy_http had a connection pool and load balancing.
>
> It would be interesting to benchmark http and ajp again to see what
> the
> difference is today with the connection pool enabled on both.
>
AJP had 2 things going for it, IIRC:
1. It was binary, so there was the transmission savings
2. Tomcat could handle AJP faster and more efficiently than
HTTP (the AJP endpoints were quicker than the HTTP
endpoint implementations)
#2 has been the most changing, and is, at least IMO, not
a real factor nowadays. #1 is still nice, plus, of
course, not being holden to HTTP, there's stuff that
can be added at the protocol level to make
the WebServer->Tomcat interaction more efficient
(so maybe that's reason #3 :) ).
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Posted by Graham Leggett <mi...@sharp.fm>.
On Wed, May 31, 2006 3:47 pm, Jim Jagielski wrote:
> Of course, there is a growing school of thought that questions
> whether the whole AJP stuff itself is worthwhile... just
> proxy HTTP and be done with it. :)
This was a question raised way back when before the ajp work started, the
question was whether mod_jk or mod_proxy_http was faster. It turned out
mod_jk was faster, and so we have mod_proxy_ajp, but that was in the days
before mod_proxy_http had a connection pool and load balancing.
It would be interesting to benchmark http and ajp again to see what the
difference is today with the connection pool enabled on both.
Regards,
Graham
--
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 31, 2006, at 10:07 AM, Mladen Turk wrote:
> Jim Jagielski wrote:
>> I guess it depend on what we mean by "healthy"... We could
>> ping the socket and make sure there's a response at the network
>> stack layer, which would be protocol agnostic. Or, each
>> proxy module would need to implement some protocol specific
>> "ping/pong" test.
>>
>
> Right, the cping/cpong is a missing feature.
> I didn't implement it initially because it existed only
> for ajp protocol, so a common mechanism should be used
> perhaps a socket liveness test on ftp/http and standard
> cping/cpong messages on ajp.
>
As we (hopefully) add more protocols into the proxy
framework, we will run into more and more cases
where there are some things that simply can't be
"generic" enough to avoid protocol specific items...
I'm looking at some sort of provider interface
for that.
>
> The balancer misses few features from mod_jk that would
> be great to have, like hot standby and a new bybussines
> lb method.
>
These are expected to be added in soonish :)
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Posted by Mladen Turk <mt...@apache.org>.
Jim Jagielski wrote:
>
> I guess it depend on what we mean by "healthy"... We could
> ping the socket and make sure there's a response at the network
> stack layer, which would be protocol agnostic. Or, each
> proxy module would need to implement some protocol specific
> "ping/pong" test.
>
Right, the cping/cpong is a missing feature.
I didn't implement it initially because it existed only
for ajp protocol, so a common mechanism should be used
perhaps a socket liveness test on ftp/http and standard
cping/cpong messages on ajp.
> Of course, there is a growing school of thought that questions
> whether the whole AJP stuff itself is worthwhile... just
> proxy HTTP and be done with it. :)
>
If some day we implement the http-ng and web-mux then
ajp will be obsolete. Until that it performs much faster
when compared to http (with some limitations).
We have some protocol enhancements on the schedule, like
programmable message size, graceful shutdown, client
break notification, and local headers, that will preserve
backward compatibility with AJP/1.3.
> Anyway, I've done some testing and mod_proxy_ajp works at
> least as well as mod_jk...
>
Same here :)
The balancer misses few features from mod_jk that would
be great to have, like hot standby and a new bybussines
lb method.
Regards,
Mladen.
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On May 28, 2006, at 4:59 PM, Ruediger Pluem wrote:
>
> 3. Currently connections are not checked if they are healthy
> *before* a request is send
> (something like mod_jk's connect_timeout, prepost_timeout). I
> think this would be nice to have,
> but I guess it is not easy to do this in a protocol independent
> way. So this might be only
> subject to implementation in mod_proxy_ajp.
>
I guess it depend on what we mean by "healthy"... We could
ping the socket and make sure there's a response at the network
stack layer, which would be protocol agnostic. Or, each
proxy module would need to implement some protocol specific
"ping/pong" test.
> 4. There is no match for mod_jk's recovery_options currently.
> Furthermore I think some research
> needs to be done about mod_proxy's current behaviour in this
> situation. I guess this is important
> to prevent things being twice in your basket :-).
>
+1.
Of course, there is a growing school of thought that questions
whether the whole AJP stuff itself is worthwhile... just
proxy HTTP and be done with it. :)
Anyway, I've done some testing and mod_proxy_ajp works at
least as well as mod_jk...
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/28/2006 03:18 PM, Jeff Trawick wrote:
> On 5/27/06, Ruediger Pluem wrote:
>
>>
>>
>> On 05/27/2006 03:58 PM, Jeff Trawick wrote:
>>
>> >
>> > Are there still fundamental pieces missing from mod_proxy_ajp +
>> > mod_proxy_balancer which have to be resolved before mod_proxy_ajp is
>> > the natural solution for anybody on Apache >= 2.2?
>>
>> Currently mod_proxy_balancer lacks the domain feature of mod_jk, but I do
>> not know if this is regarded as fundamental piece.
Other things I noticed that are different:
1. mod_jk's recycle_timeout and cache_timeout are not exactly matched by mod_proxy's
smax and ttl. But from my current personal point of view this does not matter.
2. mod_proxy_ajp does miss mod_jk's secret options. Again not critical from my point of view.
3. Currently connections are not checked if they are healthy *before* a request is send
(something like mod_jk's connect_timeout, prepost_timeout). I think this would be nice to have,
but I guess it is not easy to do this in a protocol independent way. So this might be only
subject to implementation in mod_proxy_ajp.
4. There is no match for mod_jk's recovery_options currently. Furthermore I think some research
needs to be done about mod_proxy's current behaviour in this situation. I guess this is important
to prevent things being twice in your basket :-).
>> > Isn't pass-through of client SSL connection information another
>> > problem with mod_proxy? (servlets can't access cipher or client
>> > certificate)
>>
>> AFAIK not with mod_proxy_ajp. It seems to pass all these information
>> to Tomcat.
>
>
> oops, I meant "... problem with using generic HTTP support with
> mod_proxy -- mod_proxy_http"; I agree, the functional problem doesn't
I do not know if there is any standard in passing such information to the backend
via HTTP, but I think you can pick up all SSL information that is available as env
variables and add them as request headers to the backend request via mod_headers.
Is this a sufficient solution for the problem?
Regarding mod_proxy_http the following TODO's come up to my mind:
1. Currently we cannot handle keepalive connections to SSL backends.
2. There are some problems if the backend closes a keepalive connection by itself
due to a timeout. See also:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/%3c20060220135107.GA4335@redhat.com%3e
http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/%3c43F0FBFD.6040403@apache.org%3e
and PR3770 (http://issues.apache.org/bugzilla/show_bug.cgi?id=37770).
Regards
Rüdiger
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Posted by Jeff Trawick <tr...@gmail.com>.
On 5/27/06, Ruediger Pluem <rp...@apache.org> wrote:
>
>
> On 05/27/2006 03:58 PM, Jeff Trawick wrote:
>
> >
> > Are there still fundamental pieces missing from mod_proxy_ajp +
> > mod_proxy_balancer which have to be resolved before mod_proxy_ajp is
> > the natural solution for anybody on Apache >= 2.2?
>
> Currently mod_proxy_balancer lacks the domain feature of mod_jk, but I do
> not know if this is regarded as fundamental piece.
shrug
> > Isn't pass-through of client SSL connection information another
> > problem with mod_proxy? (servlets can't access cipher or client
> > certificate)
>
> AFAIK not with mod_proxy_ajp. It seems to pass all these information to Tomcat.
oops, I meant "... problem with using generic HTTP support with
mod_proxy -- mod_proxy_http"; I agree, the functional problem doesn't
apply to mod_proxy_ajp
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/27/2006 03:58 PM, Jeff Trawick wrote:
>
> Are there still fundamental pieces missing from mod_proxy_ajp +
> mod_proxy_balancer which have to be resolved before mod_proxy_ajp is
> the natural solution for anybody on Apache >= 2.2?
Currently mod_proxy_balancer lacks the domain feature of mod_jk, but I do
not know if this is regarded as fundamental piece.
>
> Isn't pass-through of client SSL connection information another
> problem with mod_proxy? (servlets can't access cipher or client
> certificate)
AFAIK not with mod_proxy_ajp. It seems to pass all these information to Tomcat.
Regards
Rüdiger