Problem solve Get help with specific problems with your technologies, process and projects.

How to increase performance by grouping users into separate storage pools -- Part II

In this installment, Ron Turull shows you how to how to set the two parameters that govern the performance of jobs in a storage pool: activity levels and pool size.

In Part I we discussed the benefits of putting high-activity users in their own storage pool. (A high-activity user is someone who presses the Enter key all day long, such as an order-entry employee.) Such users alone can be responsible for a majority of the transactions that your system processes each day. Making sure these employees never have to wait on the CPU is key to making them efficient.

In Part I, we learned about private storage pools and shared storage pools and how to route users to the storage pool you want. Now, let's take a look at how to set the two parameters that govern the performance of jobs in a storage pool, activity levels and pool size. In particular, we will determine those two numbers for the example private storage pool for our order-entry personnel.

How to calculate the number of activity levels
The first parameter we need to determine is the activity level for the pool. (This number is shown under the "Max Active" heading on the WRKSYSSTS screen). The trick here is getting a clear picture of the number of transactions per second executed by the order-entry users (i.e., the number of times per second they press the Enter key or one of the other Function keys) and the amount of CPU time required to process each transaction. Note: Click here for a worksheet that summarizes the following calculations.


Ron Turull

The first step is to estimate the average total number of interactions per second for all the order-entry users. Do this by using the Int column on the WRKACTJOB screen. (See "How to track response time with the WRKACTJOB tool" for more information on the WRKACTJOB screen and the Int column.)

Observe the Int column on the WRKACTJOB for a sufficient amount of time to take a good sample. (Taking the sample during peak usage -- peak usage for order-entry users, that is -- will ensure good performance throughout the day.) At the end of the measurement period, total the numbers in the Int column for all the order-entry users. (Note: Save this number for use in later calculations.) Then divide this sum by the number of seconds in the measurement period. That will produce the average total number of interactions per second for the order-entry users.

Next, estimate the average amount of CPU time required to process an order-entry transaction. Again, use the WRKACTJOB screen to accomplish this by totaling the numbers in the CPU % column for all the order-entry users. (Do this the same time you total the numbers in the Int column.) That will give you the total percentage of CPU used by all order-entry users. Multiply this total percentage by number of seconds in the measurement interval, producing the total amount of CPU time used by the order-entry users over the measurement period.

Finally, divide this result by the total number of interactions (as calculated above as an intermediate step in the calculation of the average total number of interactions per second). That will produce the average amount of CPU time required to process an order-entry transaction. (If that number is not less than 1, you may want to consider simplifying the processing of the order-entry programs before doing anything else.)

To calculate an initial activity level for the storage pool, multiply these two figures (i.e., average total number of interactions per second multiplied by average amount of CPU time required to process a transaction). For example, if the average total number of interactions per second is 4 and the average amount of CPU time required to process a transaction 0.5 second, the initial activity level would be 2 (4 * 0.5).

What that does is determine the number of activity levels necessary so that when a job starts a transaction (i.e., when the user presses Enter or an F-key), an activity level will be available -- statistically speaking. The major assumption here is that transactions are started at a constant rate of 1 every 1/x seconds (where x is the average total number of interactions per second). Of course, that is not what happens in real-life, but it does ease the calculations considerably. Plus, if you took your samples during peak usage as suggested, you should have more than enough activity levels for the rest of the day.

Tip: To cover yourself during peak usage for those times when 10 users hit Enter at the same time, set the number of activity levels to 1.5 times the number calculated above (e.g., 3 for the above example).

How to calculate the initial pool size
Calculating the initial size of the "order-entry" pool is somewhat easier. If you can spare the memory, shoot for 640 KB per order-entry user. That is, try to set the pool size so that every active job in the pool (active job means the user is signed on) has about 640 KB. That will provide good protection against excessive page faulting. For example, if there are 32 order-entry users, set a pool size of 20MB (32 * 640KB, rounded).

You may need to estimate the average number jobs active at any given moment. To do that you can take random samples at different times throughout the day by counting the number of interactive order-entry jobs on the WRKACTJOB screen. Alternatively, you can simply determine the number of order-entry personnel assigned to the "peak-time" shift (usually the day shift) and use that as the estimate.

Correction: There are 64 predefined shared pools
In Part I, I reported that there were a total of 14 predefined shared pools, with 10 of those being general-purpose shared pools (identified as *SHRPOOL1 -- *SHRPOOL10). This information is correct for OS/400 V4R2 and earlier; however, V4R3 increased the number of general-purpose shared pools to 60 (identified as *SHRPOOL1 -- *SHRPOOL60) and, therefore, the total number of predefined shared pools in V4R3 and later is 64.

-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years experience programming for and managing AS/400-iSeries systems.

==================================
MORE INFORMATION
==================================


Dig Deeper on Performance

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataCenter

Close