Sometimes wide-area network application acceleration begins at the programmer's workstation. Network engineers can prevent wide-area network (WAN) application latency by collaborating with software development teams.
"The network operations group should have a team that assists developers [on] performance and supplies them with, for example, WAN delay emulation tools … so they can see what will happen," said Eric Siegel, senior analyst at the Burton Group. "Then the new app should have to pass testing -- before it's placed into production -- on a lab test bed with realistic latency and also on a few real-life paths over the real enterprise network."
As long as application development and networking groups operate with a separate silo mentality, a WAN is bound to suffer from application latency.
"The network guys don't understand how distant the application programmers are from the hardware and underlying network," Siegel said. "As far as the programmer's concerned, the network guy [made the mistake]. As far as the network guy is concerned, the programming guy's an idiot."
In a programming development environment, even the chattiest of applications will run seamlessly on a local area network (LAN) and can give ill-advised programmers the idea they'll perform similarly across the WAN. Network admins have to give programming teams a reality check, said Siegel, who recently authored the best practices paper Designing Applications for the WAN.
That means getting applications out of the test lab and into typical end-user spots -- such as a small satellite-connected branch office, a remote laptop on the Internet or a large branch office -- to see how applications perform when jumping through hoops such as firewalls, caches, optimizers and VPNs.
Part of making this kind of collaboration happen requires a "top-down approach" and includes the CIO, said Jim Metzler, vice president of Ashton, Metzler & Associates.
"We have to change [the attitude that] my job is to cover my butt to protect my group from the slings and arrows from the other group," he said. "The culture change can really only come from the top. The network administrator can really only make so nice with the systems administrator."
Stop application latency before it happens
Programmers use middleware, which "hide the complexity and details of the computer environment" so that they don't "have to get into the bits" as they design applications, Siegel said. As a result, they often don't realize their SQL call, for example, was tightly coupled or that the application made the call at all.
"It might take one or two hundred round trips to do a transaction. If that's over a LAN and you have a delay or one or two milliseconds, nobody notices," Metzler said. "Take that application and run it over a WAN … you get a delay of 10 to 20 seconds. That's not acceptable."
Network administrators should urge application development groups to enable "dye-tracing tools" -- as they're developed, not after they're executed -- are optimized for the WAN, Siegel said.
"Diagnosing problems in production often requires tracking the state of a single transaction as it passes through many different processors and as it interacts with remote servers," he wrote in the paper. "To do that, many organizations ask the network group to dump raw data from communications links and help the programmers interpret the flow of messages."
Because programming and networking staff speak different technical languages, the process is often unfruitful, Siegel said. Vendors such as Quest Software and AmberPoint have sold transaction tracing tools for mainframe computers. Those tools have now been developed for distributed computer systems, he added.
"They associate a single transaction with all of the calls that it makes on the operating system and on the databases, and they can tag individual transactions as they move from one server to another," Siegel wrote. "The tools can trace a subset of the transactions, such as those generated by synthetic transaction agents, or they can trace all transactions entering the system."
Application performance over a WAN may sometimes also be gauged during development if programmers know the right parameters to set in their middleware -- a space where network admins can also play a critical role, Siegel said. Network sniffing can also be used to diagnose problem apps.
"[Programmers] don't have these tools in their production systems because operations guys don't want to be running these tools all the time," Siegel said. "Their general attitude is, 'You've got to be joking -- and you want me to pay for it too? Get out of here.' And yet, that is exactly what we need."
Although not every application is doomed to fail over a WAN, some are more likely to struggle, Siegel said. "Especially [those] on low-bandwidth, high-latency or high error links," he said. "Streaming video is an obvious example, as is any fast-changing graphics thing."
For commercially-developed applications that perform poorly on the WAN, a WAN optimization device may be the only recourse, analysts said. Larger enterprises with more to spend may want to invest in using an MPLS to mitigate Internet latency across the WAN, while smaller organizations that can't afford MPLS could purchase an application-delivery service.
But for the most part, network administrators need to make sure in-house programmers understand their concerns as they develop more WAN-friendly apps.
"At the end of the day, there's not a lot a network administrator can do to improve latency," Metzler said. "We're not going to suggest they improve the speed of light."
Let us know what you think about the story; email: Jessica Scarpati, News Writer
Dig deeper on Application performance on the WAN