variable overhead of encryption/decryption, which is proportional to the number of bytes in the
transaction. Note the capacity factors in the tables above comparing non-secure and secure serving.
From Table 6.1, note that simple transactions (e.g., static page serving), the impact of secure serving
is around 20%. For complex transactions (e.g., CGI, servlets), the overhead is more watered down.
This relationship assumes that KeepAlive is used, and therefore the overhead of key processing can
be minimized. If KeepAlive is not used (i.e., a new connection, a new cached or abbreviated
handshake, more key processing, etc.), then there will be a hit of 7x or more CPU time for using
secure transaction. To illustrate this, a noncached SSL static transaction using KeepAlive has a
relative capacity of 1.481(from Table 6.1); this compares to 0.188 (not included in the table) when
KeepAlive is off. However, if the handshake is forced to be a regular or full handshake, then the
CPU time hit will be around 50x (relative capacity 0.03). The lesson here is to: 1) limit the use of
security to where it is needed, and 2) use KeepAlive if possible.
7.
Persistent Requests
and KeepAlive
: Keeping the TCP/IP connection active during a series of
transactions is called persistent connection. Taking advantage of the persistent connection for a series
of Web transactions is called Persistent Requests or KeepAlive. This is tuned to satisfy an entire
typical Web page being able to serve all imbedded files on that same connection.
a.
Performance Advantages: The CPU and network overhead of establishing and closing a
connection is very significant, especially for secure transactions. Utilizing the same connection
for several transactions usually allows for significantly better performance, in terms of reduced
resource consumption, higher potential capacity, and lower response time.
b. The down side: If persistent requests are used, the Web server thread associated with that series
of requests is tied up (only if the Web Server directive AsyncIO is turned Off). If there is a
shortage of available threads, some clients may wait for a thread non-proportionally long. A
time-out parameter is used to enforce a maximum amount of time that the connection and thread
can remain active.
8.
Logging:
Logging (e.g., access logging) consumes additional CPU and disk resources. Typically, it
may consume 10% additional CPU. For best performance, turn off unnecessary logging.
9.
Proxy Servers:
Proxy servers can be used to cache highly-used files. This is a great performance
advantage to the HTTP server (the originating server) by reducing the number of requests that it must
serve. In this case, an HTTP server would typically be front-ended by one or more proxy servers. If
the file is resident in the proxy cache and has not expired, it is served by the proxy server, and the
back-end HTTP server is not impacted at all. If the file is not cached or if it has expired, then a
request is made to the HTTP server, and served by the proxy.
10.
Response Time (general):
User response time is made up of Web browser (client work station) time,
network time, and server time. A problem in any one of these areas may cause a significant
performance problem for an end-user. To an end-user, it may seem apparent that any performance
problem would be attributable to the server, even though the problem may lie elsewhere. It is
common for pages that are being served to have imbedded files (e.g., gifs, images, buttons). Each of
these transactions may be a separate Internet transaction. Each adds to the response time since they
are treated as independent HTTP requests and can be retrieved from various servers (some browsers
can retrieve multiple URLs concurrently). Using Persistent Connection or KeepAlive directive can
improve this.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 6 - Web Server and WebSphere
85
