But while this new system offered great improvements in functionality, it also imposed greater demands on the available infrastructure. The project's technical lead observed, "In the past, the mainframe sent small packets of information to the green screens in each county. [The project] is browser-based, which gives users a much richer set of graphical features but also generates more traffic and larger XML and HTML data packets. If we wanted to run the new system over existing pipes then we knew that highly efficient bandwidth compression would be a key success factor."

The state turned to application switches to accelerate the performance of the applications and services running on its Microsoft infrastructure. Yet while these acceleration appliances were able to achieve and document an 80% reduction in bandwidth usage, they didn't quantify the accompanying improvements in end-to-end response times.

Measuring Feeds and Speeds
The key to measuring the impact of application acceleration is to be able to monitor the before-and-after performance of the relevant Web Services, to be able to watch a "speedometer" as the application revs from 35 to 100 mph. And just as there are several different flavors of acceleration appliances, so there are also several different ways to measure speed.

Service-based
The oldest variety of measurement is service-based monitoring. Service bureaus operate a global network of monitoring stations that transmit synthetic requests to the Web pages you want tested. You can then log into the service provider's system to see how quickly your SOA could respond to artificial requests from a variety of locations around the globe.

These service-based measurement tools are a good first step, since they require little upfront investment, and can also be used for testing pre-launch applications that don't yet have any real load on the system. However, they are less helpful in monitoring production Web Services, since they can't replicate all the different locations that might call a service, or replicate the complex interactions generated by real system load.

Appliance-based
The next variety of measurement device is the appliance-based speedometer. These monitoring appliances sit in your data center alongside your acceleration appliances, generally off a mirror port. The appliance-based speedometers use network sniffing techniques to estimate the end-to-end response times that your Web Service users experience.

Unlike the service-based measurement, these appliance-based devices can monitor all the requests and transactions of true production load, making them much more helpful for production monitoring. However, because they're completely passive, their data reflects a statistical estimate rather than an actual measurement. In addition, the cost of these appliances generally rivals those of the actual accelerators themselves, which means that you're paying just as much money and setting aside just as much room in your data center for your speedometer as for your actual motor (the accelerator).

Software-based Speedometers
The final variety of measurement tools is the software-based speedometer. These speedometers measure the actual end-to-end response times of your Web Services.

Like the appliance-based devices, software-based speedometers can monitor all the requests and transactions of true production loads. Yet unlike the appliance-based devices, software-based speedometers offer a much leaner, more efficient solution that doesn't require additional boxes in your data center.

Because they can provide complete end-to-end tracing of .NET and J2EE applications as well as detecting Web Service slowdowns, end-to-end monitoring software can also trace the root cause of those slowdowns on the back-end, down to individual method calls and SQL queries.

As a drawback, however, software-based speedometers require IT groups to install software rather than simply plugging in an appliance.

Beyond Measurement: Tuning the Engine
Of course, even if you have the right measurement device to determine the speed of your Web Services, you're job still isn't done. Let's say your speedometer tells you that your apps are crawling along at 35 mph when the desired speed is 65. Now you need to know whether to replace the spark plugs, change the carburetor, or maybe just find a smoother road. What you need is actionable information that allows the IT organization to tune the infrastructure and application development to tune the app.

Nor can this information be limited to aggregate data from the various tiers of the infrastructure, which masks information about individual users and transactions. Most tools for tuning deal with how the aggregate performance is affected by tuning the areas they point out as bottlenecks. However, the CEO and CIO must also deal with specific user complaints caused by specific transaction issues. These are only visible after the transaction has taken place and there are no tools to preemptively alert executives to these problems. Like IT they only hear about them after the irate call. More importantly, they have no visibility into the impact these slowdowns are having on the business - from revenue to reputation. Combining an accelerator appliance with a speedometer that allows the diagnosis of specific issues offers IT organizations a complete solution.

For example, a regional multiple listing service (MLS) experienced a series of service outages that affected a key application for its subscribers (www.f5.com/solutions/success/nwmls_ss.html). This application gave real estate agents access to a centralized database of listings, market analysis, tax information, and zoning on a broad range of properties. Naturally, performance was critical.

The problem was that the system was running into infrastructure capacity issues. For example, the MLS would often have problems with its Internet Service Providers. According to their network administrator: "We'd be forced to wait while the ISP's webmaster tried to diagnose a routing problem and determine whose fault it was."

By implementing a load balancing solution, the regional MLS was able to accelerate application performance and increase availability as well. "Customers no longer have to pay the price if one of the providers has system problems or is getting flooded," the network administrator said. "There's no more down time or waiting while third-party ISPs try to find the issue. There's no more latency in failing over or waiting for our routers' tables to update through the Internet. It's a whole new level of high availability for Internet connectivity - failover is instantaneous."

In another case, a Web 2.0 company used an acceleration appliance in conjunction with a software-based speedometer to accelerate its Web Services, as well as to identify and fix individual code issues (www.symphoniq.com/solutions/videos/wallop.asp).

In the end, even the best application accelerator cannot fix flaws in the infrastructure or code. The company brought in an end-to-end transaction management tool to measure the impact of the acceleration appliance, as well as for its ability to tag-and-trace sluggish real user actions through the application infrastructure to pinpoint hotspots and bottlenecks. This data lets developers and operations staff quickly work around infrastructure problems or application anomalies to ensure a smooth deployment and production ramp.

"[Symphoniq's product] TrueView gives my developers a clear roadmap to problem resolution using real user data to determine which tier of the application is sub-par, and what is causing the slowness," said the company's VP of engineering. "With a few clicks, the product identifies the servers, method calls, or SQL queries that are causing the problem, saving a lot of time we would otherwise have to spend reproducing, investigating, or debating over the details."

Conclusion
As we've seen, the rapid adoption of Web Services and Service Oriented Architectures is increasing, rather than decreasing, the importance of network performance in the enterprise. As a result of the pressure exerted by the added complexity and overhead of SOAs, companies are increasingly turning to application acceleration vendors to improve performance. However, while these solutions work, they leave IT organizations dangerously in the dark about actual performance conditions. The answer to these issues is to choose the right speedometer for your enterprise. The different types of speedometers - service-based, appliance-based, and software-based - offer different functionality, but with a shared goal of allowing IT organizations to understand the true gains of acceleration. Once these gains are documented and analyzed, IT organizations should look to their tools to provide the actionable information needed to tune the infrastructure and code for optimum performance.