1. Web Server/App Server Connectivity
SEMINAR TO BEGIN MOMENTARILY…Thank You For Your Patience.
To Join the Audio Portion of Today’s Seminar:
U.S./Canadian Participants - Dial 800-531-3250
Conference ID: 1055076
2. Web Server/App Server Connectivity
Speaker: Jim Jagielski Speaker: Filip Hanik
CTO: Covalent Technologies Sr. Engineer: Covalent Technologies
Director/Member/Developer: Apache Member/Developer: Apache Software
Software Foundation Foundation
Questions can be submitted by clicking on the
Submit Question button above.
3. The Source for Apache, Tomcat,
Geronimo & Axis
Covalent is the Leading Provider of Support
for Apache Software Foundation Open
Source Projects, Namely Tomcat, Geronimo,
Axis, & Apache, the World's Leading Web
Server*
Covalent is One of the Few Sources of Full
Commercial Support for Apache, Axis,
Geronimo & Tomcat on a Global Basis
Covalent Currently Supports More Than 50%
of Fortune 500 and 20% of Global 2000
Companies
*62% global Web server marketshare ~Netcraft April 2006 Web Server Survey 3
4. Web Server/App Server Connectivity
Agenda
Why Common Practice is also Best Practice
Overview of AJP (Apache JServ Protocol)
Connectivity Methods
Advantages / Disadvantages
4
5. Typical Web/App Server Implementation
Apache Tomcat
Apache HTTPD
Firewall
Follows 3-tier architecture
Tiers isolated by firewalls
Tomcat fronted by Apache Web Server
5
6. Common Practice == Best Practice
Apache Tomcat
Apache HTTPD
Firewall
Security
Business logic protected
Web server provides choke point
Web server designed to be in DMZ
Authentication done at Web server layer,
access to wider range of auth options
Fast, centralized SSL/security
6
7. Common Practice == Best Practice
Apache Tomcat
Apache HTTPD
Firewall
Flexibility
General purpose Web servers are
designed to be flexible
Can re-implement backend with no
outward changes
Load balancing well insulated
Apache’s MPM implementation
7
8. Common Practice == Best Practice
Apache Tomcat
Apache HTTPD
Firewall
Performance
Web servers are optimized for HTTP
“Easy” to tune Web server and OS for
peak performance
Scalability is inherent in design
Separation of tasks and overhead: your
app server only handles dynamic content
8
9. Common Practice == Best Practice
Apache Tomcat
Apache HTTPD
Firewall
But what about Tomcat’s APR and NIO
Connectors?
Yes, Tomcat is now a capable HTTP server
But that doesn’t make it an ideal HTTP
server
But we can, and should, still use that
capability
More in a few slides
9
10. AJP - Apache JServ Protocol
Apache Tomcat
Apache HTTPD
Firewall
In a typical implementation, the
communication protocol between Apache and
Tomcat is AJP
Apache used mod_jk to talk AJP to Tomcat
AJP was originally designed to simplify the
communication between Apache and Jserv,
an older servlet implementation
10
11. AJP Design and History
AJP is a binary, packet-based protocol
Main Design Considerations:
Text is slow; binary is fast
Opening/closing sockets is very slow;
persistent sockets are fast
Plus, creating your own protocol means you
can simply things (don’t need to worry about
HTTP compliance)
11
12. AJP Design and History
mod_jserv was the 1st Apache module to
implement AJP (c1997)
mod_jk designed to better integrate Apache
and Tomcat
Warp and mod_webapp were attempts to fix
most of the problem with AJP and mod_jk. It
was shortly deprecated
mod_jk2 was an attempt to “upgrade” mod_jk
for Apache 2, and take advantage of JMX-like
setup. It was deprecated in Nov. 2004 12
13. AJP Design and History
Note that all protocol translations (HTTP>AJP
and reverse) are done at the Apache module
layer
With mod_jk2 gone, the Apache proxy code
was updated to include native AJP capability
(to compliment the existing HTTP, HTTPS
and FTP capability)
In parallel, Apache 2.2’s Proxy upgraded to
provide load balancing, etc…
13
14. AJP The Dark Side
Persistent connections – Tomcat blocking IO
Must match maxThreads with the
maximum possible connection count
Each thread takes up system resources
Not Firewall friendly
Silently drop connections – no FIN packets
mod_jk unable to properly handle such
connection
mod_jk reconnect can cause a thread
increase/spike on Tomcat
14
15. AJP The Dark Side
Very difficult to debug
Binary protocol
Packet size limitations
Minor build releases become incompatible
with existing configuration
And is marshalling into binary really faster
than sending HTTP straight through?
To most of these issues
There is a cure
Or there is a workaround 15
16. AJP on the Tomcat Side
Three AJP Connectors
Java connector
Blocking IO
One thread per connection
APR connector
Supports polling
Allows more connections than threads
Java NIO Connector
Not seen much use
May not be battle tested 16
17. Alternatives?
OK, so AJP can be bothersome…
What alternatives do I have?
To answer, let’s look at some of the latest
Tomcat and Apache developments
17
18. Tomcat’s HTTP Connectors
NIO and APR connectors
Extremely capable and finely tuned
connectors
More options, more control
Asynchronous servlets
Send file support
Can replace AJP specific features
Custom httpd headers – httpd
Custom valves - tomcat 18
19. Tomcat’s HTTP Connectors
Blocking Java Connector (BIO)
Works well with previous mod_proxy since
connections are not persistent
The fastest connector when not using
persistent connections – no polling
overhead
HTTP Connectors are easy to debug
HTTP is text based, just sniff it
19
21. Apache 2.2: Proxy Balancer
mod_proxy now implements native load
balancing with connection pooling
Support for HTTP, HTTPS and AJP13 protocols
(no more mod_jk)
Can weight traffic by request counting or traffic
counting (lbmethod)
Can adjust load factor preferences (loadfactor)
Support for hot-standby and cluster sets (v2.2.4)
Embedded manager application
21
25. Recommendation Time!
Now that we know about AJP and HTTP, it’s
time to make some recommendations
When tradeoffs exist, it’s always best to be
functional, even if a little bit slower (or
potentially slower)
It’s noteworthy that most of the problems
seen involves the AJP layer, and not Apache
or Tomcat themselves
25
26. mod_jk - AJP
Advantages:
Incorporates many fixes/hacks to address
problems with AJP
Disadvantages:
Directives, config and behavior frequently
change between patch-level point releases
(1.2.x -> 1.2.(x+1))
Most common native code does not use
APR
Uses AJP
26
27. mod_jk - AJP
Use Cases:
AJP is mandated
Setup is very complex (firewalls, etc…) but
“local”
Score:
B
27
28. mod_proxy_ajp - AJP
Advantages:
Consistent with normal Apache config
Under the Apache HTTP PMC
Uses APR
Disadvantages:
Lacks parity with mod_jk for some of the
workaround/hacks
Uses AJP
28
29. mod_proxy_ajp - AJP
Use Cases:
AJP is mandated
Setup is straight forward (no firewalls or
firewall-related problems, etc…) and
“local”
Score:
B- (but increasing)
29
30. mod_proxy_http - HTTP
Advantages:
No longer uses AJP, but HTTP
Native, protocol-level support for
authentication and SSL !
Much more battle tested (mod_proxy used
all over the place)
Disadvantages:
Method relatively unknown or
unconsidered
30
31. mod_proxy_http - HTTP
Use Cases:
“Everyplace”
Setup is simple to complex
Required encryption between Apache and
Tomcat
Score:
A
31
32. Summary
HTTP is now extremely viable alternative
mod_proxy in Apache 2.2 offers both AJP
and HTTP, as well as expected, required
features (load-balancing, sticky sessions…)
Advances in Tomcat HTTP connectors allow
total HTTP infrastructure design
32
33. How you can help
Battle test Apache 2.2 mod_proxy (both
HTTP and AJP)
Battle test Tomcat APR and NIO HTTP
connectors
Provide feedback, patches, etc… to Apache
and Tomcat PMCs or even Filip/Jim directly
33
37. Q&A
Any further questions can be submitted by clicking
on the Submit Question button above.
To request a copy of the slides, get the URL for the archived Webcast,
or to send feedback,
e-mail seminars@covalent.net
What is the next Webinar you’d like to see? Let us know:
e-mail seminars@covalent.net
Thank You.
37
38. The Most Trusted Source
for Complete Enterprise Open Source Solutions
38
