Zentraler Punkt dieses Beispiels ist die Konfiguration eines Apache Webserver (1.3 Branch) für die Arbeit als Eintrittspunkt und Frontend für einen dahinterliegenden Tomcat (5.0.18) Servlet Container. Augenmerk lag dabei auf selektiver Verwendung von mod_proxy und mod_jk, um die Webanwendungen nach außen zur Verfügung zu stellen.
Warum der Unterschied in Vorgehensweise (Verwendung von mod_proxy und mod_jk für den nahezu gleichen Zweck)?
- Im hinter dem Apache Webserver stehenden Tomcat liegen sowohl "normale" Servlet bzw. JSP Webanwendungen vor als auch ein Coremedia Generator.
- Diese sollen einheitlich über das gleiche Frontend erreichbar sein.
- "Normale Webanwendungen" koennen problemlos ueber mod_jk genausogut wie über mod_proxy oder mod_rewrite angesprochen werden. Wobei die Ansprache über mod_jk meist performanter sein sollte, wenn die Web-Anwendungen eine deutliche Tendenz zur dynamischen Inhaltsgenerierung haben.
- Ein Coremedia Generator Servlet soll nach Herstelleraussage am besten über mod_rewrite angesprochen werden, da dieses die stärkste Entlastung des Generator-Prozesses durch die Benutzung des Generator Cache im Filesystem gewährleistet. Im vorliegenden Fall ist der Anteil der vom Generator Servlet erzeugten Daten jedoch dynamisch (es ist eine Zielgruppensteuerung eingebunden), d. h. direkte Cache Hits für Top Level Ressource auf den Generator Cache sind sehr unwahrscheinlich.
- Überdies gehören die Anwendugen zu einem Extranet, auf das die meisten Benutzer aus Sicherheits- und anderen Gründen über eine ISDN mit 64 KBit zugreifen, d.h. für letztendliche Geschwindigkeit gegenüber dem Benutzer spielt nicht nur die Abwendungsperformance eine Rolle, sondern auch die Download-Rate. Aus diesem Grund empfiehlt sich die Übertragung des Content in einem komprimierten Format (z.B. GZIP).
- Dabei besteht das Problem daß mod_gzip, das zu Kompression verwendet werden kann, nur schlecht mit mod_rewrite zusammenarbeitet.
Konsequenzen: Es wurde momentan dahingehend entschieden, anstelle mod_rewrite mod_proxy zu verwenden, da für Inhalte die durch mod_proxy von anderen Systemen bezogen werden die mod_gzip Kompression problemlos funktioniert. Dadurch entseht eine etwas höhere Last auf dem Coremedia Generator Servlet da dessen File System Cache umgangen wird. Dieses ließe sich durch die Arbeit mit zwei Apache-Instanzen (eine direkt vor dem Coremedia Generator mit mod_rewrite, um den File system Cache zu nutzen, eine nach außen, die alle Inhalte über mod_proxy bezieht und komprimiert) umgehen. Diese Möglichkeit offen zu halten ist der Grund für die Verwendung von mod_proxy anstelle mod_jk für den Zugriff auf das Coremedia Generator Servlet.
Die dargestellte Konfiguration bildet die Lösung mit direktem Durchgriff durch mod_proxy und mod_jk auf den Tomcat Servlet Container und Kompression durch mod_gzip ab (Siehe ab Zeile 532 in der Source Datei).
Dokumentation zu den verwendeten Apache 1.3 Modulen:
mod_proxy
mod_jk
mod_gzip
mod_rewrite
The main point of this example is the configuration of a Apache webserver (1.3 branch) to work with a Tomcat (5.0.18) servlet container as it's backend. Attention has been on the selective use of either mod_proxy or mod_jk to make the web applications in the Tomcat container available publicly.
So, how come the difference (using mod_proxy or mod_jk for almost identical purposes)?
- In the Tomcat container behind the Apache Webserver are two types of wen aps deployed. "Ordinary" servlet and JSP applications as well as a Coremedia Generator:
- These shall be reachable by the user o a unified frontend
- "Ordinary web apps" can be easily accessed using mod_jk as well as mod_proxy or mod_rewrite. There is a bias towards mod_jk in case the addessed web app has a stron tendency to output dynamically generated content. For this case mod_jk has a promise of better performance.
- A Coremedia Generator Servlet is according to the manufacturer best acces using mod_rewrite, since this provides best use of the Coremedia Generator Servlet file system cache an decreases load. In the case documented here most of the content is generated dynamically, because a system for targetted delivery of output is implemented. Therefore hits for top level resources to the Generator file system are very unlikely.
- Furthermore the web apps in discussion belong to an extranet to which most users for security and other reasons have access only through a 64 Kbit digital phone line. Which means that for the actual user experience not only server performance but also download rate is essential. To deliver content to the users in a compressed form (as e.g. GZIP) seems to be strongly advised.
- One problem with this is that mod_zip which would be responsible for content compression does not collaborate very well with mod_rewrite.
Consequences: It was decided to use mod_proxy instead of mod_rewrite, because mod_proxy is able to hand over content it has retrieved from other systems to mod_gzip for compression.
By using mod_proxy there will be higher load on the Coremedia Generator Servlet to some degree, because it's file system cache is circumvented. This effect could be eliminated by using two Apache webserver instances (one directly in front of the Coremedia Generator Servlet acessing the servlet with mod_rewrite to use the full file system caching capabilities, another one accessible from the outside that uses mod_proxy and compression).
The potenial of this variant is the prime reason for the current use of mod_proxy to access the Coremedia Generator Servlet instead of mod_rewrite.
The configuration on display shows the solution with direct access to the Tomcat servlet container and the Coremedia Generator Servlet therein with compression through mod_gzip (see line 532 and below in the source file).
Documentation for the Apache 1.3 modules discussed above:
mod_proxy
mod_jk
mod_gzip
mod_rewrite