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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org