Performance Anxiety

There is no excuse for a poorly performing client/server system. In my world, that's just poor quality. It's the application architect's responsibility to ensure that the processors, network, operating systems, applications, and databases all work together to form the system and define good overall system performance. That means thinking about performance early in the life cycle.

Client/server performance, as a concept, is a delicate balance of technology and architecture. Many consider it an art; however, it's really a science. Using a few rules, tools, and methodologies, you can ensure that your users will never have to wait for your system.

To my surprise, even the most gifted client/server application architects and developers don't think about performance until it's too late. The fact is, many client/server development projects fail because of poor performance, and others die a slow death as systems fail to scale to higher users and processing loads.

When considering client/server performance, application architects need to learn a few basic rules:

• Overall system performance is constrained by the slowest component (such as client, network, application server, database server, Web Server, or Web Server to DBMS API).
• Consider performance early, at the design stage, not only during testing and deployment.
• Pilot, component, integration, and load testing are essential when selecting system components and tools.
• Monitor the system in production to verify performance and ensure good performance over time.

Component Problems

To depict the concept of the throughput model, let's look at the behavior of a typical two-tier client/server system. When a user presses a "Customer Data Inquiry" button on the user interface, the client application translates the user interaction (using the client's hardware and operating system) and passes the request to the middleware layer. The middleware layer knows how to communicate with the specific network protocol layer, which in turn knows how to utilize the networking hardware (adapters, hubs, routers, and so on), passing the request to the target database server over the network. Middleware on board the database server is able to accept the request and pass it directly to the database engine for processing, using the server's hardware and operating system services. The result set returns to the client by moving through the same components in reverse. (See Figure 1, page 28.)

Obviously, if any one of these components is not able to keep up, the overall system performance will suffer. The components are like links in a chain. For instance, a slow network, client, or database server (or any combination of these) will cause such a problem. Most of us are already aware of this. The big question is, how do we avoid it before building and deploying the system? The answer: Model, simulate, model, simulate, build, test, deploy, and then monitor.

Performance by Design

System performance modeling is nothing new. Mainframe capacity planners have been using such techniques for years. Network designers also employ these techniques, and most of these concepts migrate down to client/server. However, client/server adds its own set of complexities because of the distributed nature of the application and the complexity of the architectures and quickly changing tools and technology. What's more, many client/server systems must share a network -- even servers -- with other applications, many of which are not under the control of the architect. The challenge is to learn to build these complexities into the model, and to adjust the model for time and change in technology. We also have monitoring tools that provide us with a mechanism to monitor the performance of each component under test or after deployment.

To create a model, you need a lot of information about the system you're looking to build, including hardware, operating system, network, and servers. Once you know what you're working with (or going to work with), you need to define the behavior of each component. This involves how much CPU time and memory are required for each transaction over time, as well as packets placed on the network. In addition, these models can also contain cost information, user behaviors, and application load on each system component. I discuss this later in this column.

So how do you create such models? Three tools work: First, you can use a calculator and a sheet of paper, but only if you have the table space and the time. (I would pass up this option.) Second, you might choose a spreadsheet such as Excel. This option is better, but you have to keep track of a lot of variables and define complex relationships between the variable using a tool that's better at budgets than at client/server architectures. The best (and third) way, however, is to use a simulation tool that's able to do most of the dirty work for you.

At this point I wish I could say that there are many client/server system performance simulation tools on the market, but that's just not true. One of the few that I've found is Strategizer from Scientific and Engineering Software Inc. (SES). SES/Strategizer is a Windows NT-based simulation tool that's able to model distributed systems including computers, networks, routers, applications, and databases. (See Figure 2.) Strategizer is able to simulate system performance providing application architects with information such as end-to-end application response time, network capacity, server capacity, data distribution, and cost. It enables architects to play what-if games to determine the optimal system configuration.

Although not a magic bullet, Strategizer gives application architects the ability to lay out the system architecture using a drag-and-drop visual interface. Here is where you'll find icons such as workstations, servers, mainframes, network topologies, users, server processes, database processes, and database tables. It's just a matter of placing the icons in the model, connecting them, and then setting parameters on the hardware components, adding information such as name, operating system, number of processors, types of processors, installed RAM, and number of disks. Strategizer provides several prebuilt models for typical client/server systems, but in most cases you'll have to define your own.

Strategizer also provides an Application Definition Notation (ADN), a way to represent applications of varying degrees of complexity creating common performance characteristics. For example, client/server applications that use message-oriented middleware (MOM) behave differently than those that use remote procedure calls (RPCs). Many applications today use a mix of both, adding further complexity. Remember, overall system throughput changes as component properties change. For instance, while migrating to Windows 95, many application architects noticed that performance of many existing Windows applications took a hit. For your entire model to be relevant, you need to capture all performance information in your model. Miss something, and all bets are off.

ADN enables architects to turn application logic into system behavior. For instance, you can capture information for message passing and send and receive statements; local processing and I/O requested using execute statements; control logic with If, While, Call, Fork, and Thread statements; and variable control with assignment statements. ADN also defines workload specifications and user behavior by capturing user "think time," interarrival time probability distributions, and other application behaviors. It's a common mechanism to define application behavior regardless of the development tools and type of application.

In addition, simulation tools such as Strategizer can collect data from system performance data points (disk I/O, network traffic, database performance, and so on) using traditional monitoring tools and standards such as Simple Network Management Protocol (SNMP). What's more, these tools can take realtime information and apply it to the model so that the architect can modify properties and assumptions to create a better client/server architecture.

Still Building Models at My Age

This is no easy task. To do it right, you need to put most of your workstations, servers, and the network in test mode to determine behaviors. I've found that relying on vendors to provide such information is not a good idea. Vendor benchmarks, for example, often don't match reality.

In addition to the normal system hardware, network, and operating system performance issues, you need to work with databases as well. Products such as Strategizer address the presence of databases through an extended ADN to define databases in a simulation model. For example, you can define the use of an Oracle DBMS in either single- or parallel-processing flavors. This portion of the model considers database operations and table information; it also represents parallel-server processes and memory-management and cache-management issues. For instance, you can simulate how common database operations, such as FETCH, UPDATE, SELECT, and COMMIT, hit CPU time and other server resources. You must match the database requirements to an application.

Monitor

Indeed, you can't solve all client/server performance problems using simulation and modeling. They're just tools to create a healthy system design. The real message that I'm trying to relay here is that you should consider system performance early and use these tools to avoid trouble, not as a means to get out of it. Most client/server systems that I see don't consider performance until the deployment stage, and at that point it's too late. You either have to pull the system back and layer in new components and architectures, or hope that the user won't notice. Either solution means poor-quality system development, which is more the norm today than the exception. That's not good.

Figure 1.

--A typical client/server throughput model.

Figure 2.

--SES/Strategizer is a Windows NT-based simulation tool that's able to model distributed systems including computers, networks, routers, applications, and databases.

---

The following screenshot is from a more recent version of SES/Strategizer seen in Figure 2. This figure was not featured in the print version of DBMS.

---

David S. Linthicum is the author of David Linthicum's Guide to Client/Server and Intranet Development (John Wiley & Sons, 1997). He is a widely published author, speaker, and senior manager with AT&T Solutions Systems Integration Practice in Chantilly, Virginia. You can email David at linthicum@worldnet.att.net.

---

What did you think of this article? Send a letter to the editor.