CCAPRINT: A Newsletter for Model 204® and System 1032® Users	June, 10, 2002

• Insight 204 - Reminder to Register for Insight 204!
• Model 204 - Tracking Transactions for Performance: Part 3
• System 1032 - On the Road with Open VMS

Model 204
Tracking Transactions for Performance: Part 3

By James Damon

Measuring Performance Based on Transaction Definition

In the Part 2, May 2002 edition of CCAPRINT, I described four different definitions of what might constitute a transaction in a particular environment. Once you've decided on a definition, you can easily estimate end-user response times and calculate the cost of a transaction in terms of CPU, physical I/O and memory. These calculations also enable you to measure changes in performance as a result of CCAIN-parameter changes, application and file changes, and changes in numbers of users.

For instance, you might be interested in the performance effects resulting from doubling the size of the buffer pool from MAXBUF=20000 to MAXBUF=40000. Did that change result in a decrease or an increase in CPU consumption, DKRD, DKWR, or transactions per second? Did a change to NSERVS change CPU per transaction or transactions per second or server swaps per transaction?

Establishing Baseline Information

I'll illustrate how to estimate end-user response times using the system final statistics from the May 2002 edition of CCAprint. I'll also use the SCREENS statistic as my definition of a transaction, knowing full well that I'm including work in an average screen transaction that may have actually occurred in a non-full-screen transaction, such as a DUMP command issued from a BATCH2 thread. Nevertheless, if the work performed by this Online tomorrow and next week is roughly comparable to the work performed today, I have a baseline against which I can measure changes.

Figure 1. System final statistics

AUDIT=15660446 OUT=9529 IN=3005 OUTXX=6 INXX=37 DEV5=6837931 DEV6=67996267 DEV7=2141929 DEV8=1929003 DEV9=127 DEV10=15112424 DEV11=2 OUTTTY=4299 INTTY=1600 DEV27=53083 OUTCRAM=1135897 INCRAM=500205 INVMIO=161176 OUTVMFS=10230 DEV52=6651 WAIT=8106555 DKRD=36266057 DKWR=11685665 SVRD=743691 SVWR=745091 CPU=79821116 REQ=8185582 MOVE=48509988 SLIC=44942 CNCT=53999 SWT=21107 RECADD=919226 RECDEL=466850 BADD=99576166 BDEL=22841834 BCHG=9375376 IXADD=2590184 IXDEL=1797337 FINDS=46901235 SORTS=422989 RECDS=242113417 STRECDS=3948097 DKAR=245872253 . . . WAIT=38636654 STPOST=613668 LKWAIT=2617658 LKPOST=2617864 RSXCOMP=5 SCREENS=1837763 STIMERS=45163 SVPAGES=137409786 COMMITS=660243 BACKOUTS=4101 . . .

Transaction Response Time

The three main components of response time that Model 204 can measure are:

Using the statistics from Figure 1, the average full-screen response time, inflated by resources consumed by non-full-screen transactions, is as follows:

Note: The DKWR statistic is not included because writes are asynchronous and do not contribute to response time.

Before we can convert this to an estimate of response time in seconds, we first need to make two estimates for the average elapsed time to:

• Read one 6184-byte database page into memory
• Read or write 0.8 of a server into or out of memory

Estimating Database I/O

For database I/O, if we assume that most Model 204 files are allocated on cache-controlled devices, and we also assume that there will be read misses which require access to the physical volume, 10 ms per database page is probably a worst-case estimate for I/O service times.

Estimating Server I/O

For server I/O we need to know, on average, how many bytes are transferred in one server swap. This can be calculated starting with the SVPAGES statistic, which counts the number of 4-kilobyte pages swapped to and from CCASERVR. If we divide that number of bytes by the number of server reads, plus server writes, we have an average number of bytes transferred per server I/O:

(SVPAGES*4096)/(SVRD+SVWR)=378,047 bytes per server I/O

Assuming that all server I/O requires access to Model 3390 disk, that one track rotation requires12 ms of elapsed time, and that track capacity is 56,664 bytes as per engineering specifications, then one server I/O requires:

(bytes per server/track capacity) * track-rotation in ms

or

(378,047/56664) * 12 ms = 80 ms

Internal Response Time

Now we can compute average, Model 204 internal response time as follows:

If we assume that the CPU is not 100% available--say it's 80% available--and that some I/O takes longer than the estimate, it is not difficult to see that this average response time could be closer to 330 to 350 ms, in some cases.

Other Response Time Delays

Other factors which add to response time are network delays, protocol conversion, and delays for record or resource locking conflicts in Model 204. These delays can only be approximated. However, based on empirical evidence I've collected running numerous benchmarks and analyzing performance at many customer sites, a multiplication factor of roughly four accounts for most of those additional delays. This gives an average response time as experienced by end users in this system, of approximately 4 * 350 ms = 1.4 seconds.

Figuring out transaction cost

To compute cost per transaction, we can still use SCREENS as the definition of a transaction. We can also use CPU / SCREENS for the average CPU per transaction. However, we'll also need to calculate average EXCPs performed and average real-memory occupied per transaction to get a true cost per transaction.

Calculating Average EXCPs

Total EXCPs are often provided as end-of-step statistics by the operating system and, if available, that number should be used. Alternatively, the following formula provides a reasonably close approximation:

DKRD + DKWR + SVRD + SVWR + DUMP + REST + CCAJRNL I/O

Message M204.1939 in CCAAUDIT at the end of the run provides the EXCP count to CCAJRNL, in this case:

M204.1939: NUMBER OF JOURNAL BLOCKS WRITTEN = 258219

Using the previous formula for this Online, total EXCPs is the sum of:

36,266,057 + 11,685,665 + 743,691 + 745,091 + 0 + 0 + 258,219 =49,698,723

The average number of EXCPs per transaction is the total number of EXCPs divided by the value of the SCREENS statistic, or:

49,698,723 / 1,837,763 = 27

Calculating Average Real Memory Per Transaction

Average memory occupied per transaction can be determined from the sum of STORINIT, plus STORMAX, plus the size of the Online load module, which is close to three megabytes:

The average virtual storage required per transaction is total virtual storage bytes divided by the SCREENS statistic, or:

560,000,000 / 1,837,763 = 305 bytes.

Calculating Charges for Memory Use

On most systems where a charge is incurred for memory use, that charge is applied to real, central storage frames occupied per unit of time. A Model 204 Online, as in this case, may require 560 megabytes of virtual storage, but average only half of that amount, or less, in real storage occupied over the course of the entire run. This is especially likely if the run is active for 23 hours, but the majority of transaction processing occurs between 9 AM and 5 PM. In this case then, an average of 150 bytes of real memory occupied per transaction should be used in cost determination.

Given these formulas, depending on the accounting practices used at your site, such as which machine resources incur a cost and at what rate, you could now calculate a cost per transaction.

Summary

Whether you're interested in average response time or cost per transaction, these measurements provide a baseline for future performance monitoring. Now, when parameters are changed in CCAIN, the new Version 5.1 features are enabled, fields are converted from KEY to ORDERED, files are reorganized to eliminate extension records or to improve on number of records per page (BRECPPG), the change in performance can be determined using these baseline measurements.

System 1032
On the Road with OpenVMS

By Tym Stegner

On 20 May 2002, Steve Nelson and I attended the Compaq (now HP) OpenVMS Partner Training and Ambassadors Roundtable held in Nashua, New Hampshire. HP Sales/Marketing organized this one-day event to expose the OpenVMS Ambassadors to the solutions and services of the attending Independent Software Vendors (ISV).

The OpenVMS Ambassadors Program provides a liaison between customers, the HP OpenVMS System Software Group, and experts field organization in sales support, systems integration, technical consulting, and benchmarking. With worldwide and cross-organizational representation, OpenVMS Ambassadors are pre- and post-sales experts, supporting and influencing a majority of OpenVMS customers on a daily basis.

The Roundtable is where HP Partners and ISVs can be brought up to date on the current status of OpenVMS and its futures, as well as an opportunity to display their products for the Ambassadors. In addition to a couple of hundred HP Ambassadors (all or most of them, I understand), there were representatives from 42 other companies offering one or more OpenVMS programs, products, and/or services. It was exciting to be in a place where the language spoken was VMS.

We heard from eight HP executives and managers about the market HP plans to pursue, the releases of OpenVMS, and chip releases. Starting with my notes, I collected a list HP Web sites you might find especially informative.

• The bulk of the technical content presented at the Roundtable is available in the presentations of the OpenVMS Technical Update Days, last held in Vienna and London in April 2002.

• The HP continuing support for Alphaserver systems and the EV7 chip are discussed in the Alphasystems roadmap.

• How HP plans to ease in the use of the Itanium Processor Family (IPF) architecture, with specific information on what functionality and which layered products will be available in each release is described in the HP White Paper "Porting OpenVMS(tm) Applications to Intel(r) Itanium(tm) Architecture".

• The OpenVMS Strategy Overview introduces OpenVMS 7.3-1, which features security, TCP/IP V5.3, UNIX portability, and release quality.

• If you want to focus on future features and improvement in OpenVMS, have a look at the OpenVMS solutions.

• Selling ISV software and OpenVMS, involving direct and indirect sales channels, is reviewed in the Application/Provider Matrix, available on the OpenVMS web site.

• An finally, to promote awareness of OpenVMS, an internal-external newsletter exists, formerly known as the OpenVMS Times, now known as the HPS Times.

Promoting System 1032

Following the seminars was the ISV mini trade show. We, the ISVs, were the vendors showing our wares, and the OpenVMS Ambassadors became the customers.

Surrounded by the other 40 or so ISVs, Steve and I answered three solid hours of questions from Ambassadors responsible for only a few sites and others with hundreds of sites. I did a few feature demonstrations of the System 1032 command environment --one lasted 45 minutes for one very enthusiastic Ambassador. An HP executive, who dates himself back to the Digital Equipment days, ported a MUMPS application to System 1032. In fact many of the Ambassadors had either used System 1032 or were at least familiar with it.

In Summary

In all, it was a worthwhile experience. It was heartening to be in the company of so many people who support OpenVMS, and are doing their best to sell and promote it. With support like this from HP, System 1032 has a long life yet on Alpha and continuing on into the IPF environment.

Copyright © 2008 Computer Corporation of America.
All right reserved. Published in the United States of America.

HomeDownloadsownFeedback

Contact CCA Webmaster
Copyright 2008