tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: AJP vs HTTP connectors?
Date Sat, 07 Feb 2009 21:40:49 GMT
On 02.02.2009 21:20, Eric B. wrote:
> I was listening to a webinar on spring source by Filip Hanik&  Mark Thomas
> regarding tuning Tomcat for production in which they indicate that the Http
> connector is recommended vs an AJP connector
> (http://www.springsource.com/node/555).
>
> My question, then becomes, if someone wants to use Tomcat to serve up pages
> behind Apache Httpd, how to configure it to use the http connector?  So far,
> the only thing I found is to use proxy/reverse proxy which is slow and can
> be problematic.  To date, I've always been using mod_jk with AJP connector,
> but is there a better/preferred way to do this?

I'll make a couple of comments, but keep in mind that I might be biased 
towards mod_jk.

Historically a few years ago Mladen Turk, who at that time more or less 
was the only remaining active committer on mod_jk and who is also a 
committer to httpd, initiated porting mod_jk to the mod_proxy framework, 
which he did as I remember mostly together with Jean Frederic Clere.

Some initial goals were:

a) creating a bigger developer community
b) making the module available by default with httpd
c) creating a more unified configuration style
d) making the code easier by using the APR libraries

Goals a), c) and d) have been achieved. Concerning b) one can have some 
doubts, because although all configuration is done in httpd style 
configuration files, you also end up with long attribute lists when 
actually defining the workers. The configuration complexity for complex 
production environments doesn't go away.

Another thing turned out to be more important: The porting to mod_proxy 
was done at about the time of version 1.2.15 of mod_jk and got its first 
production release with httpd 2.2.0. Now the release policy of httpd has 
to be very conservative. The thing runs the majority of the web and you 
really need to be very careful not breaking it. So any bundled evmodule 
can only improve very slowly once it is in a production release of 
httpd. This changes whenever httpd gets a major update, like expected 
this year (2.4 comes closer).

On the contrary I had the opportunity to join Mladen in the development 
of mod_jk shortly after the mod_proxy_ajp port, and together we were 
able to add a lot of features and to release a lot of versions. 
Triggered by this improved dynamics more developers contributed 
enhancements and patches. So we are now at version 1.2.27, though 
release pace somewhat slowed down recently.

So though mod_jk and mod_proxy_ajp/mod_proxy_balancer once were very 
close, mod_jk moved faster.

Don't get me wrong: a lot of people were happy with mod_jk 1.2.15 and 
are very happy with mod_proxy_ajp. Especially if your setup doesn't get 
too complex and if you already have some basic familiarity with 
mod_proxy, it's a good choice.

I hope we will find time to merge back our mod_jk improvements to 
mod_proxy before 2.4 gets released. mod_jk can still be the faster 
moving target, but it would be nice to merge back soon.

So what does all that mean? I expect that neither mod_proxy_http, nor 
mod_proxy_ajp or mod_jk do differ very much in performance on modern 
hardware. I think the differences in robustness are not very huge. 
mod_jk has some more features, but in simple setups you won't need them. 
Whichever way you go, for a good result you really need to read 
carefully through the various configuration options and try to 
understand the consequences. None of the modules provides an excellent 
result in a high-performance or complex architecture situation by 
default. At the end it comes down to knowledge.

BTW: This is the Tomcat users list. People here might be a bit more 
focused towards mod_jk. You can also ask around on the httpd list to 
check out the opinion of that community.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message