200 Maximum Performance with WebSphere Application Server V5.1 on iSeries
6.1 Web server performance
Anytime you surf the Web, you access several Web sites, each of which contains one to many
components. The great cloud of the Internet can definitely be hazy and obscure, just as long
as you can still order your DVDs or buy a new shoes via the Web. In any case, the
components of a Web serving environment can be boiled down into three parts: a client, a
network, and a server. It can be way more complicated than that, but in essence these are the
parts that are involved.
And where does the HTTP server fit into this? The HTTP server fits on the back side as the
server, unless you consider the HTTP server as a client, requesting information from another
server, which is also possible. For the sake of simplicity, think in terms of client, network, and
server. With this simple mind-set, the performance problems that may arise can be attributed
to one or all of these areas. See Chapter 1, “Performance concepts and factors” on page 1,
for more discussion about this topic.
6.1.1 The server
When you enter into the server arena, you face a challenge in attempting to come up with a
nice and simple plan to gain performance boosts. Why is this? Because the variables, flavors,
and complexities of the server are as varied as the patterns of a snowflake. That’s the point
about the server. The idea is to handle all sorts of applications, both large and small, dynamic
and static.
Still, you can narrow down your search for performance increases by remaining steadfast to
the common factors of application performance; resources, database, and the application
itself. In a more robust and complex environment, you have split this application workload into
several components: a Web server, an application server, and a database server. This
combination of servers can increase or decrease depending on the availability of the
application and the volume of transactions for it.
How does the HTTP server fit into this mix? Simple, it is the Web server portion. And the
application server is WebSphere. And for the iSeries, you can either have the database server
running locally or remotely, depending on the topology of your companies’ data layer.
As you may have guessed, the server layer is, in almost all cases, the layer in which you
spend the majority of your time debugging performance issues. It has the most volatile
components, the pieces and parts that you have created, tweaked, or plugged in, to provide
an effective and reliable application or Web site.
6.2 Caching
Caching is one area of interest when it comes to increasing performance. In particular,
caching allows resources and pages to be available in memory, as opposed to having to be
retrieved from disk. In most cases, this can save a considerable amount of response time for
the user.
Caching on the iSeries is setup using a hash table. Each object (GIF, HTML, XML, JavaScript,
or any file required for a page) in the HTTP request is indexed within the hash table. For each
request, a lookup is done on the hash table to determine if you set the object to be cached
static caching). If so, the object is retrieved from memory via the hash table lookup and
returned to the user. If the object has not been already used, then further processing is done
to retrieve the object from its original location. After this is done, the object is then cached for
future use (
dynamic caching).

Get Maximum Performance with WebSphere Application Server V5.1 on iSeries now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.