Maximum Performance with WebSphere Application Server V5.1 on iSeries

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).