Most performance tuning activities involve systems tuning such as managing I/O, adjusting parameters, moving workloads, etc. Only rarely do you work directly with application developers to improve code efficiency. But there’s a third tuning method—one that’s only rarely employed, but often can be highly effective. This is particularly true when you can’t touch the application.
End-user tuning, where you work with users to improve their use of a specific application or function, can generate more balanced system resource consumption and consistent response times. Here, we’ll cover examples and approaches to working with end users.
Systems performance management can be a frustrating job. If response time is good, you get no credit. If it degrades, you aren’t doing your job. But in most companies, the performance analyst has limited knobs to tweak to improve performance. System parameters can be adjusted, memory can be used to avoid I/O, but often, the desired speed can’t be achieved due to the application design.
Bad application design can limit the effective performance of even the most highly tuned system, but rarely, if ever, is the performance analyst included on the design team. This is the recommended approach, but it occurs rarely, particularly given the trend toward purchased software. Here, we assume it’s unlikely to occur.
In addition, the trend toward high level or object-oriented languages makes it more difficult for even an experienced analyst to understand or affect the impact of programming choices. System managed storage (SMS) file management, in effect, got rid of one of the most valuable tuning techniques—hand placement of data files to optimize I/O performance. In the CICS and VSAM world particularly, this method plus buffering often resulted in 90 percent of the performance gains possible. The “guaranteed space” option can be used to override SMS file placement, but the data management group rarely supports this option, despite its proven efficacy.
A Better Way
A better way to manage performance is to begin with the application design team. Performance analysts can significantly improve the performance and scalability of an application if they’re involved upfront, when the application is conceived. Management typically assumes that “performance is everyone’s job,” so application designers should care about it just as much as the performance analyst. However, only the analyst is really held accountable for response time. Programmers will often cave in to users’ demands, resulting in online transaction processing (OLTP) applications with batch-like or I/O-pig transactions that will never meet service level agreements (SLAs). SLAs tend to be numbers users pluck from the air, but they gain substance and reality the longer people hesitate to challenge them. Remember, an application programmer’s primary responsibility is to meet the functional requirements of the business he supports; performance is a secondary consideration, at best.
Involvement in design and testing means that poorly designed transactions can be fixed while the team is still open to change. An installed application frequently attains the inertia of an aircraft carrier and, given the difficulty in passing through installation hoops at most shops, it’s somewhat understandable that changes after installation seem threatening.
Unfortunately, many shops have resorted to purchased code to speed “timeto- market.” Rarely, if ever, do the vendors support a performance or scalability clause in their contracts, and with object code only (OCO) as a standard delivery method, the performance analyst has almost no opportunity to fix the design.