1. Edward Jones IS Capacity Planning and Performance Management Jim Poletti October 23, 2007

2. About Edward Jones... Full service investment firm 10,000+ branches – US, Canada, UK 1 "broker" and 1 branch office administrator per branch Land-line WAN – DSL or T1 St Louis datacenter is hub for most traffic Tempe datacenter primarily DR for mainframe 21,000 users signed on to CICS at high-water

3. IS Capacity Planning & Performance Management Jim Poletti (MF Performance Analyst) Gerry Oliver (MF Performance Analyst) Greg Volk (Network Performance Analyst) Rick Pranger (Open Systems Performance Analyst) Dwayne Allen (Open Systems Performance Analyst) Tom Siech (Load Tester) Brandy Brown (Load Tester) Rich Unnerstall (Director – Data Center Operations) Art Morlock (Department Leader)

4. St. Louis Mainframe Hardware All LPARs run on 1 physical mainframe IBM Z9 2094-707 – 3516 MIPs – Z/os 1.7 80 GB memory 40 TB DASD – EMC Raid -1 and -7, 5 Ms Older symmetrix – replacing with DMX-4 Data replication to Tempe using SRDF

5. CPU by LPAR

6. Production Environment/LPAR 1 LPAR (no data-sharing SYSPLEX yet) 25 CICS regions – 19 AORs, 5 TORs,1 FOR 32 Million CICS transactions/day = 7 million user "enters" DB2 – 1 subsystem IDMS – 5 regions, 15 million run units/day RRDF replication in DB2 and IDMS to Tempe

7. Responsibilities Assure system performance and scalability. Provide capacity planning support for purchasing decisions. Tune the mainframe hardware "till the wheels come off", then buy capacity. Hotline, war room participation. Performance Testing.

8. Early Morning "System Checks" Check system "barometers" from yesterday Check performance graphs and reports CICS transactions – Volume, CPU, Response LPAR CPU Memory DASD DB2 IDMS Development response time – TSO, compiles

9. Houston, we have a problem ! Go into detective mode Start at high level, look at service classes within LPAR for abnormalities

10. Daily Workload Statistics For 9:30-10:30 on Wed, Oct 17, 2007 Compared to Prior 4 Wednesdays ServiceCPU Change%Real ClassUtil inChangeMemory 17-OctPrior 4CPU GbPrior 4 WednesdaysUtil Wednesdays BAT_HOT0.3 0-87.68.6 BAT_11.61.50.1520.115.7 BAT_23.6 0152126.2 CICS_111.811.20.661490 CICS_233.434.5-1.2-320372246 CICS_30.60.8-0.2-27315.5352.5 DB2_HI1.61.8-0.2-1166486636 DB2_LO0.6 -0.1-1121.925.5 IDMS11.311.9-0.6-513901398 MQSERIES0.30.20.135775418.7 NEWWORK000-440

11. Dig deeper into details of the workload ProgramSUM CPUCICS +DB2 CPU%DB2 PctResp NameTimeCPUTimeChangeCPUTimeChangeTime 9:30 toTimePrior 4CPUTimePrior 4DB2 Prior 4 10:30PerWeds PerWeds Tran CMSOC3008840.0025 10.0021 10.0760.078 DFHMIRS4240.0006 -200.0.0310.034 MYDOC0163910.00720.0075-30.0060.0062-30.3010.314 PRTOC5152840.01410.0145-30.01020.0104-30.1890.21 BRHOC0531900.0008 10.0006 10.0110.012 PRTOC6301880.01110.0116-40.00530.0056-50.070.077 CMSOC3201870.0052 10.0048 10.1490.153 CHSOC1201330.0025 -20.0006 -20.0520.057 CMSOC330950.0060.005920.00580.005720.1820.184 BRIOC022930.001 00010.0180.019 IAAOC222910.0156 00.0116 00.4820.485 PRTOC001840.005 00.0019 00.0740.08

12. Once problem is found, find cause Run strobe on CICS or batch job. Ask if program was changed. Was a system parm changed? Lurking problem surfaced when user patterns changed Did a new system go in?

13. Recommend change to fix problem Code fix Parameter change SQL or IDMS call change Run workload different time; smooth peaks Redesign database or add index Completely shutdown workload If you don't know how to fix it, ask others

14. It helps to make performance recommendations if… You were a programmer in a previous life You were a DBA in a previous life Knowledgeable in MVS,CICS, DASD etc.

15. Integrity matters Be right, study before you speak Go for tuning that gives a payback If the workload isn't measurable, put in mechanisms to measure it before doing the tuning change Do some PR work - Send tuning results to programmer and their management

16. Mainframe tools SAS MXG Strobe Jones built performance repositories Our performance website RMF 3 Omegamon

17. Capacity Management’s Prime Objective: When Do We Run Out? When do we need more of a resource? How much lead time do you need? –Approval cycle –Floor space –Vendor Delivery Time –Installation Time –Acceptable Risk

18. Forecasting Processes Performance Prediction Resource Utilization Trends Business Forecasts Resource Utilization Models Workload Models Performance and Workload Data Repositories Validate, Assess and Revise

19. Performance Tuning: We continually tune hardware and software, as well as their interrelationships, to improve the performance of systems. Shares ownership across multiple departments. Very highly iterative – never done! Why: –Direct positive impact upon end user experience. –Tuning  cost avoidance.

20. Performance Tuning: How do we improve programs? Divide and Conquer: –Which program in a batch job takes the longest? –Which program uses the most CPU? –Profile Code –Tune infrastructure (including network). –Prioritize process

21. Performance Tuning Which programs are slowest (Dawgs)? Which programs use the most resources (Hawgs)? Which programs are used the most? Business criticality: How important are they to the business? Identify Opportunities for Improvement – aka "Hawgs" and "Dawgs".

22. Performance Data Repositories We maintain many performance data repositories – these tend to be collections of statistics not detail data. For example, we will not retain CICS transaction detail, but we will calculate counts of transactions by region by transaction name as well as average, maximum and percentile statistics for a variety of variables and intervals. SAS is our primary tool.

23. Performance Data Repositories: Data Sources CICS – by day, by tran DASD Type 74 – by day, by LPAR, by VOLSER Jones application instrumentation MVS level – by day, by LPAR IDMS- by day, by program DB2 – by day, by tran Service and report classes – by day, by service class Proc summary, proc append

24. Business Metrics and Workloads Business Metrics typically use different time frames than workload metrics. Business doesn’t forecast in terms of megabytes of DASD, cpu seconds used, interactive sessions, concurrent users or paging rates. They refer to branches, IRs, customers, trades, purchases, $$$, payments, visits, exorbitant cost of IT,…

25. Loved Ones: Sorry, all apps are not equal What is the business importance of the application / workload? If there are diverse workloads on a system it is necessary to prioritize the work to ensure that the work is processed in an order that reflects its business priority. To understand priorities you have to understand the business. Capacity planning activities should also ensure that when work is constrained, the highest priority work is favored.

26. Performance testing Jones has clone environment of production Use Loadrunner tool to generate transactions Think time adjustable A few hundred users is usually enough All major system enhancements are loaded tested

27. Load Testing: Objectives Is End User Performance acceptable? Will the introduction of these new features threaten the health of other applications? How does response & resource utilization compare to current production levels? Reproduce and troubleshoot production problems. Will we need to add capacity?  In stress testing we measure response times at production peak load and 5x production peak.  Often identify 'Break Points' to watch for in production.

28. Interaction with Availability A badly performing application is effectively the same as the application being unavailable. Capacity and Availability Management share common goals / tools and complement each other. Capacity Management needs to be aware of Availability techniques deployed, such as mirroring, load balancers or clustering, in order to plan accurately for Capacity.

29. Questions: