Sizing Guidelines For AS/400 - IBM

flashyfarctateInternet and Web Development

Jul 30, 2012 (5 years and 2 months ago)

236 views


Sizing Guidelines

For AS/400



Larry Loen

IBM Rochester Lab

December 15, 1999

Introduction

WebSphere is a new and exciting product for AS/400. It p
rovides much of the infrastructure for setting
up and managing a web
-
based search, browse, and shopping system for AS/400 customers, especially
in a Java and servlets context. IBM
WebSphere Appli
cation Server

is intended for organizations that
want to take advantage of the productivity, performance advantages, and portability that Java provides
for dynamic Web sites. It includes the following:





Java runtime support for server
-
side Java servlets



Industry
-
standard object
-
request brokers to handle requests for data and

other services from client
-
server applications



High
-
performance connectors to many common back
-
end database to

reduce the coding effort required to link dynamic Web pages to real

li
ne
-
of
-
business data



Application services for session and state management



In an attempt to estimate resource consumption, we have begun working with various scenarios and
benchmarks which we hope are good predictors for resource consumption by actual AS
/400 customers.
We selected a benchmark using a reasonable amount of WebSphere function.

One should note many important cautions with this work:



The measurements behind these recommendations were made using WebSphere 2.02.
Preliminary work showed WebSphe
re 2.031 was similar. However, these results should not be
used to estimate earlier or later versions of WebSphere.



It is very early in the evolution of WebSphere. It is timely to "say something" and make
estimates so that bids can be entered, but it is al
so sufficiently early that exact usage patterns
could be very different from what is now assumed. This paper is no replacement for a proper
risk assessment by IBM and its partners.



The deployment environment is rich in choices. The developers on AS/400 who

wish to deploy
a WebSphere solution can make many trade
-
offs between using WebSphere function
(shortening developent) and "rolling their own" code (improving performance).



There is nothing better than some sort of working prototype
, even a partial prototy
pe, for
making estimates. Such information, if it is available, should be used in lieu of this set of
guidelines.



The market is immature. Buy versus Browse is a key variable and is largely unknown at
present. Moreover, the buy/browse ratio will probably va
ry between businesses.



It is not yet clear what the dominant technologies within WebSphere will be. At the present time,
we have isolated one significant factor
--

whether Java Server Pages (JSPs) are used or not.
Because JSPs tend to have a greater amount

of dynamic content, we expected some penalty to
produce dynamic content versus a more static deployment that simply "served up" existing data
with greater frequency. There could be others with comparable influence we are not yet aware
of.



It is early in o
ur evaluation and tuning process. We are giving very conservative guidance
because we do not know, yet, whether we can "turn some knobs" and improve performance.
The recommendations are based on very early results. Historically, we would expect to see
sign
ificant performance gains as we improve the application environment and the marketplace
adjusts its functional expectations to the available horsepower. However, if you are selling a
machine today, this improvement is not something you can count on.



It is
plausible that the web
-
based environment, by its nature, may lend itself to customer
inquiries of a more substantial nature. Historically, order entry systems get input from an order
entry clerk who, by definition, puts in orders that someone has already d
ecided upon. Here,
customers start off by entering or re
-
entering a set of web pages and may rely entirely on its
contents to make the purchase decision. The nature of the difference is not clear, but one likely
outcome is larger, more complex queries for
the e
-
commerce environment.



Our selected transaction model is a common one in the industry and the performance
community: An on
-
line book sales operation. Besides being widely known as an e
-
business
success story, selling books on
-
line is similar to sellin
g many other commodities and consumer
goods on
-
line. It offers rich possibilities in terms of search and selection criteria and so
enables a great number of potential transactions to be defined. In addition, the content of each
transaction type can be easi
ly varied to a wide variation in resource consumption. Not all of the
available variability has been exploited in the benchmark, however.


Results

Reading the bottom line without an understanding of the rest of this paper is risky. A "transaction" is, in
itself, meaningless in terms of comparability. There is a natural tendency to ignore this and compare
transaction rates between some existing benchmark and some entirely new one as if the "transactions"
in both represented a finite, comparable amount of wo
rk. This is decidedly not true here.

System

JSPs used /
not used

CPU
utilization

Thruput in

hits per
second


Number of
Users
--

Simple

Number of
Users
--

Complex

Logical DB I/O
per second
--

Simple

4
-
way :
730
-
2067
2000
CPW

NonJSP

92%

402

3270

1090




1053.8

4
-
way :
730
-
2067
2000
CPW

JSP

93%

146

1630

540

1053.8

1
-
way :
170
-
2385
460
CPW

NonJSP

94%

87%

110

104

930

700

310

230

318.5

1
-
way :
170
-
2385
460
CPW

JSP

95%

85%

52

50

480

470

160

155

318.5

As can be seen, the use of JSPs

is, very roughly, a 2
-
to
-
1 performance penalty over not using JSPs,
with the penalty possibly greater in larger configurations. Some of this penalty is not due to JSPs
per
se
, but include items like less use of prepared SQL statements and more WebSphere f
unction. There is
some reason to believe, despite the large uncertainty, that JSPs might also bring with them higher
development productivity but lower performance.

Because of the nature of the benchmark selected, the number of users from that benchmark i
s
artificially low. The value given above for "Number of Users
--

Simple" is not the raw measure of
users from the benchmark (the other numbers are). The value given above was adjusted assuming,
more realistically in our view, that human beings would study

the previous result for an average of 14
seconds before sending in another request. This adjustment is under the "Simple" heading as we
believe this application is less complex than many might actually deploy. A further adjustment,
assuming a more complex

scenario, gives what may be a more "typical" user count based on higher
function. While we have some real customer data points between these values, the number of
comparison points are few and it may be that some will observe results substantially better
or
substantially worse than the above user counts. Moreover, the "hits per second" is probably a higher
precision prediction, even though "number of users" is more traditional. These issues suggest why
actual prototypes are likely to yield better estimates
.

Brief Description of the Transactions

1.

New user browse. 9% of the transactions add a new user and the new user does some
subtantial browsing.

2.

New user browse and buy. 9% of the transactions add a new user, but perform different
browsing and finishes with

a purchase.

3.

Existing user browse and search. 9% of the time books are searched for by subject and nothing
purchased.

4.

Existing user browse and purchase. 36% of the time a browse occurs and three books are
purchased.

5.

Existing user complex search, browse and

purchase. 9% of the time a fairly complex search
precedes a purchase.

6.

Existing user multiple search, purchase, and browse. 27% of the time a complex series of
searches is followed by a purchase and further browsing.

Sophisticated users can measure result
s of the above workload in "hits per second", a measure of
HTML pages produced and responded to. For such a measure to have meaning, the relative size and
distributions of various transaction types have to be known, as in the simplified benchmark transacti
ons
above. None the less, it is common in the industry and some customers' programmers will be able to
estimate "hits."

A more traditional measure is active users per machine, which is partly a transactional measure and
partly a capacity measure. It, too,

must understand the relative size and distributions of the various
transaction types.

If there is no prototype, adjusting the above numbers to an actual application is more art than science.
The number of logical DB I/Os for the "Simple" case could be a
useful departure point for any needed
adjustments
.

Aspects of these transactions of interest to web developers with other AS/400
experience

1.

All of the above presume that SQL and dynamic SQL is being used. This is the most expensive
way to access an AS/400

data base. Moreover, the searches are relatively sophisticated, so
that the typical "trip" to the data base represents what might have formerly been a fairly
substantial RPG job performing the same task discretely.

2.

Substantial state is managed outside of
the standard AS/400 job structures. Because of how the
web works, there is no permanent connection between a user and the system. Jobs are not
thereby rendered useless, but many things which formerly were attached to jobs now must be
attached to something
else. In the case of this benchmark, a "shopping cart" is the application
-
level object selected to perform this role.

3.

The application proper is written in Java, but the WebSphere function is used to create Java
Virtual Machines (which are server jobs) and
to distribute work between the various threads
created and available as part of the various jobs.

4.

One serious flaw in the current application is that users respond without "thinking" first. This
artificially depresses the number of users supported, though
the transaction amounts can still
be realistic. We have made our best stab at adjusting for this in our reported results.

5.

Another potential difference of interest: Most searches are compound and all return a relatively
small number of results (circa 30 to
100). This puts a proper emphasis on data base query logic
and potentially under
-
rates some WebSphere and application function that would have to handle
a larger number of results, which might or might not affect the costs of dynamic HTML
generation (at th
e least, more data would need to be laying about, awaiting "rendering" in a
page).

Additional sources for WebSphere information


An excellent white paper on


AS/400 WebSphere



may be found at
the AS/400 WebSphere internet
site at:
http://www.as400.ibm.com/WHPAPR/websphere.htm

. Specific
WebSphere 2.02 Performance
Tips and Considerations

are available at the following
URL:


http://www.as400.ibm.com/tstudio/websphere/product/WSA202Pe
rformanceConsiderations.html

.




General cross platform


information is available on the
IBM WebSphere

site at:
htt
p://www.as400.ibm.com/products/websphere/index.htm

. For additional information on IBM
WebSphere product offerings

and multiple processor platform implementations check internet at:
http://www
-
4.ibm.com/software/webservers/

.

Copyright by International Business Machines, 1998. All rights reserved. Questions regarding this
material should be directed to Larry Loen,
lwloen@rchland.vnet..ibm.com

or Richard Odell,
rjodell@us.ibm.com

IBM Rochester Lab. Last update to this document was:
.