Using the HVWS Simulator

 < Day Day Up > 



You complete a series of steps on separate panels to define the application, hardware, software, and performance objectives, as depicted in Figure 9-2.

click to expand
Figure 9-2: Overview of using the HVWS Performance Simulator

You can see the primary panels used to input information at the end of the chapter.

The model is designed to estimate the configuration to meet specific performance objectives. The estimated configuration does not include servers such as back up machines. You adjust the configuration by adding other servers that may be required.

Examples of how the HVWS Simulator is used

This section describes four customer engagements where the HVWS Simulator was used to guide the customer's selection.

Online shopping

A large retailer forecast a six-fold increase in demand for their online shopping application during the next holiday season. They asked IBM to estimate what would be needed to meet that demand. They also asked us to predict how much more workload the existing configuration would support. Their application server hardware was near "end of life" and their database server was at capacity.

The current login rate was 30 per second. Using the HVWS Simulator's online shopping model against a login rate of 180 per second, we determined the current configuration would handle a login rate of 45 per second.

We recommended new equipment (pSeries 690s) that provided the capacity needed, reduced the footprint size, and reduced the total cost of ownership.

Online betting

Our customer sought IBM's advice while selecting from three platforms they were considering for their online betting applications (AIX on pSeries vs. Linux or Win32 on xSeries). The platform must handle as many as 7400 concurrent users and make heavy use of caching. Seventy percent of the pages are classified as static or periodically changing static. The remaining thirty percent are dynamic or represent work needed to address cache invalidation events.

We based the data collection on assumptions rather than actual measurements. The workload was a composite of publish/subscribe, shopping, self-service, and brokerage, so we used a three scenario user-defined workload pattern.

Table 9-1 shows the specified workload characteristics and demonstrates how the effects of cache hits were removed from the workload.

Table 9-1: How the effects of cache hits are removed

Scenario

Pg/Sec

% page hits

Cache hit %

App pg / sec

% app pages

CPU secs

SSL

Login, betting, and account details

77

23

0

77.0

76.6

0.40

Y

Informational

134

40

90

13.4

13/3

0.15

N

User customized

101

30

90

10.1

10.0

0.20

N

The CPU seconds and SSL values were used in the three scenario definitions and % App pages were used to specify the scenario ratios of the workload. Think time was elongated to compensate for cache satisfaction of up to 70% of the page hits.

We applied the workload to each platform to determine how many components each required for a cost of ownership evaluation. We tuned each configuration to provide a two-second response time (90th percentile) with SSL turned on. We ran follow-on simulations using the pSeries infrastructure to determine equipment needs for environments with partial and no caching.

The simulator based results recommended 2 x p630 4-way machines with 4G RAM to handle the top end of the workload with less than 80% CPU utilization and subsecond response at over 100 page views per second. The uncached solutions required up to two more p630s.

Fast-food chain

A fast-food chain consisting of thousands of stores worldwide asked IBM to size an in-store order processing application based on WebSphere. The application runs in standalone mode except when linking occasionally to regional servers for inventory and human resource applications. The customer required that the application run on a single xSeries.

For the simulator, we specified the online shopping workload because the chain's workload pattern is similar to the buy scenario in online shopping. We used a measure of 12-24 concurrent users in 1.8 minutes.

We populated the model as follows:

  • Set the workload pattern to online shopping with 100% buy transactions

  • 0.15 minutes per page view, total 12 page views and 1.8 minute think time

  • Performance target: user arrival rate: 0.1~0.2 user visits / sec

Based on results returned from the simulator, we recommended an xSeries 350 4-way machine with 2G RAM to handle the top end of the workload with less than 70% CPU utilization.

Online voting

The customer was considering a design for an online voting application and asked IBM to estimate the cost of a WebSphere implementation.

We based the data collection on assumptions rather than actual measurements. Using expected voter turnout, the customer estimated that 230 voters per second will be visiting the Web site, with an anticipated surge that can be ten times greater during short periods. We selected the quote scenario of the online trading workload pattern as appropriate for the proposed application.

The recommended configuration: 3 x 4-way pSeries 640-B80s for Web/WAS Tier and 1 x 4 way pSeries 660 for the database tier. This configuration was estimated to satisfy anticipated voter turnout and give subsecond response time to voter's action.



 < Day Day Up > 



High-Volume Web Sites Team - More about High-Volume Web Sites
High-Volume Web Sites Team - More about High-Volume Web Sites
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 117

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net