Edward Jones IS Capacity Planning and Performance Management

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 Rich Unnerstall (Director – Data Center Operations) Art Morlock (Department Leader) • 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)

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, 2007Compared to Prior 4 Wednesdays

11. Dig deeper into details of the workload

12. 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? Once problem is found, find cause

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 Business Forecasts Performance and Workload Data Repositories Workload Models Performance Prediction Resource Utilization Models Resource Utilization Trends 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 Identify Opportunities for Improvement – aka "Hawgs" and "Dawgs". • 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?

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. 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. Interaction with Availability

29. Questions: