Software works too
But installing an appliance isn’t the only way to control network traffic. Adelaide-based Foursticks offers a software-based alternative called Foursticks NP, allowing users to choose the hardware to suit their needs for throughput and availability. In the longer term, Foursticks visualises end-to-end deployment, right down to handheld devices.
According to Alisdair Faulkner, vice president of marketing, Foursticks NP delivers higher resolution monitoring and reporting than competing products. “Our customers find the at-the-second monitoring essential,” he says.
The software dynamically controls bandwidth usage in reaction to network conditions, and its patent-pending algorithms provide more accurate and more efficient management of interactive and real-time applications, says Faulkner. The result is “more efficient use of network resources, better application stability, [and] more precise configuration,” he says. This ability extends to managing variable speed networks such as frame relay, as Foursticks NP can detect the availability of bandwidth above the committed rate.
One problem with many types of network controls is that setting incorrect policies can severely impact performance, sometimes bringing the network to a halt. Foursticks’ patent-pending methods for checking policy correctness overcame this problem, making the system easier and safer to use. The cost of implementing Foursticks NP is typically returned within six to 12 months, according to Faulkner. One customer—Bridgestone—reported an immediate saving of $100,000 in bandwidth costs, he says.
“The forklift approach to the [network performance] problem—bringing in truckloads of bandwidth—isn’t even a bandaid solution,” says Martin Sheahan, Foursticks state manager for Victoria. “What the Foursticks NP software does is create express lanes through networks, and when you talk to enterprise customers, they get the idea immediately.”
The product has only been shipping for a few months, but customers are reporting good results.
“We run a truck every 10 minutes in the early stage of vintage. We need things to happen quickly and consistently,” says Doug Wheatley, network administrator at winemaker BRL Hardy.
“We can ill afford to have trucks backed up . . . we have customers phoning in orders every minute, and we need that to happen instantly.
“On one occasion we had a user send a 20MB PowerPoint presentation to a small site operating on narrow bandwidth and critical business activity was severely hampered.
“We found that putting in an NP resolved these problems, with sub-two-second response times for all data over to remote sites such as Berri.”
Optimising code
While the build-or-buy pendulum has been pointing towards “buy” for the last several years, there are some suggestions that it is starting to swing back and in any case there have always been some jobs that required custom development. How can you be sure that such software was implemented efficiently?
It’s not as if you can rationalise ignoring suspected inefficiencies by arguing that it’s cheaper to add an extra server than tune the code. “A lot of Java development is done [for] the server side . . . and application server licences aren’t cheap—you can be talking about $50,000 to add a processor,” says Mark Foley, senior Java architect at Borland.
One project performed by Borland’s professional services group involved software that was required to support Windows, Mac OS, and other operating systems. That’s a situation where Java is supposed to excel, but a problem arose because many of the Mac users had old, slow hardware and weren’t getting satisfactory performance. By using Borland’s Optimizeit, Foley identified over 20 areas of the code that could be optimised, and in two days reduced 10-second delays to an acceptable one second.
While you don’t always get such a big speed boost from using Optimizeit, it’s rare that you don’t see a worthwhile improvement, he claims.
“It’s easy to make a mistake” when writing code, he says, but the problem is that such mistakes can be buried under millions of lines of code. That said, performance problems do not always relate to particular lines of code but in memory management. “A poorly tuned application [may spend] 25 percent of the time doing garbage collection,” he suggests. This makes Java tuning quite different to C or C++ tuning, he says: “It’s quite hard to see what’s happening without a tool.” In this situation, adding another processor to the server might not help, but adding memory would. “The way Java manages memory is absolutely key in a Java environment,” Foley says. You need to be able to look inside the JVM to tell what is happening, and the next release of Optimizeit will have more features to address memory-related problems.
According to Foley, the 80:20 rule applies to Java software: 20 percent of the code usually accounts for 80 percent of the execution time. The situation is more extreme with application servers, which spend little time executing application code. “It can be very difficult to optimise code” in these circumstances, says Foley, so what you need to do is examine how your program is interacting with the application server. “A lot of the issues are database related—identifying them is a key problem,” he explains. Optimizeit is good for finding out which database queries take a long time to answer.
Application server configuration is another issue. A client was about to purchase an additional server in an attempt to overcome a performance problem, but an hour’s work with Optimizeit showed that the configuration was preventing the use of all the server’s memory. “It’s just a tool. It’s a good tool, but the result relies on the skill of the person using it,” says Foley.
So why don’t all developers use code optimisation tools? Foley says it is an increasingly common practice, but such tools cost money and optimisation sometimes gets a lower priority than other aspects of the development process. However, it’s much better to do any optimisation work before testing and deployment—it should be “the fence at the top of the cliff, not the ambulance at the bottom,” says Foley. Another reason for doing tuning during the development phase is that once an application is in use, feature enhancements tend to take priority over tuning, says Quest’s Pregnell.
Following its recent acquisition of Sitraka, Quest now has tools to help diagnose and tune J2EE environments. JProbe and PerformaÃ,ÂSure allowing customers to identify potential performance problems down to a specific line of Java code. “By combining Quest’s existing database and application performance management solutions with Sitraka’s in-depth Java expertise, we will be better positioned to monitor current Java applications and the next generation of packaged applications,” says Pregnell.
Just as packet shaping allows IT managers to control the bandwidth available to particular applications, other tools are available to control programs’ CPU usage. An example is ONEAPP CPU SeNTinel, which runs on Windows NT or 2000 Server, Terminal Server, and NT, 2000, or XP Workstation.
According to distributor Infotronics Software, “a single user opening an application can take processor usage to 100 percent; the result can be significant across the enterprise, machines can lock up or run very slowly.” Capping the CPU usage of individual programs prevents them becoming processor hogs and ensures more consistent across the board operation. “Applications that have sucked up so much CPU resource that they have required their own server may be run in conjunction with other applications, thereby decreasing hardware and operating systems costs,” according to a company spokesperson.
