This chapter is from the book
This chapter is from the book
This chapter is from the book
23.7 HTTP Front-End Handlers for WebSphere
Other chapters such as the Plug-in chapter covered the options and "how-to" portions of getting workload to the WebSphere servers. This section focuses on performance implications of the various techniques. The factors we look at specifically are listed here, and a summary table at the end of the section provides concise analysis.
Impacts on performance, including usage of CPU resources
Reliability
Benefits/Functions
Costs
While the overall options for front-ending have many permutations, including hardware, software, and so on, we are going to focus on just a few. Clearly, in some cases, these can be combined, and other options exist, but these are some of the most commonly used options. You will note that the older WebSphere V4 plug-in using RMI/IIOP is not considered as its performance is not as good as other options, and it is not supported in WebSphere V5.
23.7.1 Browser/Workload Direct to Controller HTTP/HTTPS Transport
The simplest setup is to have the source of the workload (usually browsers) pointed directly to the HTTP or HTTPS transport in the WebSphere Controller. This will likely provide the fastest solution, but with few options and functions available. In WebSphere V5, there will be no http logging performed (access, agent, referrer, ...), although V5.1 does provide this (this is supported on distributed platforms, but not in the current HTTP Transport on z/OS ). For the standard dynamic WebSphere workload, where everything is served out of WebSphere on z/OS, this uses minimal CPU time for routing. Functionally, however, it limits options relative to distributing the work and/or caching results. All requests are handled by WebSphere, which is not the low-cost solution for serving or caching static Web content. This is a reliable solution as there are fewer components involved. It is also a low-cost solution since no additional software is necessary.
23.7.2 z/OS IHS HTTP/HTTPS Plug-in Forwarding
This is a recent z/OS IBM HTTP Server (IHS) function modeled after the plug-in functionality on distributed Web servers. It has a minimal impact on performance since IHS is efficient, but it will use CPU resources in the front-end, so, if your system is under high utilization, it could compete with WebSphere for cycles. It is highly reliable and, for those who have historically used IHS, configuration is quite easy. If it is being used for several Server Instances, it will keep session affinity intact. It allows for all of the logging and debug features of IHS to be used in conjunction with those provided by WebSphere V5 . Since it is part of z/OS, IHS does not incur additional financial costs. This infrastructure allows for splitting workload (i.e., serving static content directly from IHS with or without caching). It is usually the case that serving static files from a Web server is faster than serving them out of an application server, and this will also avoid some TCP hops.
23.7.3 Distributed HTTP/HTTPS Plug-in Forwarding
This is a simple and efficient way to front-end the WebSphere z/OS HTTP transport. Weighted averages can be used to select z/OS and non-z/OS servers. Setting up the plugin-cfg.xml for a z/OS server is no different than setting it up for a distributed server and WebSphere V5 on z/OS can generate plug-in-cfg.xml files as well. It is important to be sure that there is enough available bandwidth on the machine running IHS to avoid creating a bottleneck in presenting workload to z/OS. As with the z/OS IHS, this allows for the workload to be split out as needed. Further information on the plug-in can be found in chapter 10 (The WebServer Plug-in) and the plugin-cfg.xml appendix.
23.7.4 WebSphere Edge Components
WebSphere Edge Components (formerly known as "The Edge Server") provides a superset of the facilities that the distributed IHS plug-in provides. With WebSphere V5, the Edge Components can be exploited for all of their capabilities such as caching Web content, routing, and so on. Full discussion of the Edge Components is beyond the scope of this chapter, but the Edge Components can be used to reduce workload on back-end servers, reduce network latency and distance, improve response time to the browser, and much more. It can be especially valuable in scenarios where the back-end servers are highly utilized.
23.7.5 Note About Sysplex Distributor
Sysplex Distributor can play a role in many of the scenarios mentioned. In using Dynamic Virtual IP Addressing (DVIPA) or Distributed DVIPA, it is simple to vary servers on and off with little or no impact to clients. In addition, this can be used as a workload distributor. Sysplex Distributor and Distributed DVIPA do not consume a great deal of resources.
Table 23.6 is a summary of HTTP front-end handlers.
Table 23.6 Summary Table of HTTP Front End Handlers
|
|
Performance |
Reliability |
Benefits |
Costs |
|
Browser Direct to Controller |
Optimal for dynamic workload, inflexible in that all work is done out of WebSphere AppServer. Can provide lowest Response Times. |
Highly Reliable, no additional points of failure introduced. |
Low, little logging, no splitting up workload. |
Low |
|
z/OS IHS Plug-in |
Very good, extra TCP hop, but ability to serve static requests out of IHS is a plus. Some extra CPU cost. |
Highly Reliable. One extra feature, but IHS is stable. |
Logging, static caching, splitting load. |
Low |
|
Distributed Plug-in |
Very good, similar to z/OS IHS but does require extra z/OS CPU resources. Make sure IHS box has sufficient available bandwidth. |
Highly reliable. Extra hop over network, but IHS highly reliable. |
Same as for z/OS IHS but can place boxes closer to clients. |
Low to Mid |
|
Edge Server |
Very good, including dynamic caching |
Highly reliable, many features to avoid single point of failure. |
Can be complex setup, but dynamic caching features are worth it. |
Mid |