Designing for application performance

Opinion
Feb 2, 20113 mins

In our last few newsletters we began to discuss a seldom-mentioned IT discipline – Application Performance Engineering (APE). In this newsletter we will discuss the linkage between APE and application design.

In the vast majority of instances the first phase in the application life cycle is to gather the requirements and the second phase is to design the application. As we mentioned in previous newsletters, a part of APE IT organizations must include in the gather requirements phase a focus on identifying performance requirements. It is obviously critical that these requirements be identified up front as they are important to guide both the development of the application as well as the deployment of the application.

While APE is a relatively new discipline, there are several vendors that provide APE products and services. This includes Shunra, HP and Capgemini. There is not, however, a wealth of best practices from which IT organizations can draw guidance. There are, however some obvious guidelines that application development groups need to adhere to during the application design stage. For example, application development groups should avoid the use of chatty protocols. A chatty protocol requires tens if not hundreds of round trips to complete a single transaction. 

Assume that the protocol requires 200 round trips to complete a transaction. If that chatty protocol is run over a LAN with 1 microsecond round trip delay, the chattiness of the protocol contributes roughly one fifth of a second of delay. Virtually no application would be impacted by this amount of additional delay. However, run that same protocol over a WAN with 70 ms of round trip delay and the chattiness of the protocol contributes roughly 14 seconds of delay. This amount of delay would significantly degrade the performance of virtually all applications.

One way that APE impacts the application design phase of the application life cycle, is the potential use of admission control. For example, we talked to one application development group that is a strong proponent of APE. The lead developer told us that during the requirements definition phase that his organization establishes firm objectives for how an application will perform. He added that those objectives have to be met independent of how many users are using the application. 

To accomplish that goal, the application development group establishes a limit on the maximum number of simultaneous users. For example, they design the application to meet a given set of performance objectives as long as the number of users does not exceed a certain number of simultaneous users. Once that number is reached, no more users are allowed to access the system.

The use of admission control as described in the preceding paragraph may not be acceptable in all situations. However, it does provide another example of the types of decisions that can be made mutually by the IT organization and the company’s business units during the design phase to ensure acceptable application performance.

In our next newsletter we will discuss the linkage between APE and application design and implementation. In the mean time we are interested in your experiences with any form of APE. Kindly write to us and let us know what you did, what worked and what didn’t work.

Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.

More from this author