What happens when you upgrade your storage, only to find that response time hasn't improved?

That's what happened to assistant VP of information technology Robert Campbell of The Graduate Center of the City University of New York. According to an article in the school's online newsletter, Campbell has spent about $100,000 on SAN gear, server, and switches. While that's a big improvement, Campbell attributes ongoing slow response time to other causes, including poor design and excessive traffic -- problems he's working to solve (though he did not respond to questions on the specifics).

Sifting through the reasons for poor performance can be a Herculean task, as any IT pro knows. In fact, there are a plethora of things to check. Where to begin?

Generally, say industry sources (including analysts, vendors, and end users), when it comes to storage, isolating response time problems calls for a multifaceted approach. For instance, if storage gear is up and running properly, it may be worth trimming the amount of data stored, shipped over network links, or backed up. This is where WAN optimization, data de-duplication, data compression and compaction, and other data-slimming techniques come into play. (See Scrunchable Storage.)

There may be no single solution. Brad Hudak, director of IT at Houston-based integrator NetVersant Solutions, claims to have saved considerable time, money, and effort by deploying WAFS and WAN optimization at the company's 22 remote sites. Still, he advocates checking the actual traffic that's going on a net. Internet access that loads up connections with streaming audio and video files, for instance, may need to be addressed with end users. Quality-of-service networking may also help improve bandwidth efficiency when connecting into and out of storage networks.

One SAN expert at a state government agency, who asked not to be named, suggests several checkpoints for weeding out storage-related response time problems:

• Keep up with cache. It you add disk without expanding your disk cache, performance could actually decrease, even if storage capacity climbs. Check server memory, too.
• Check iSCSI connections. iSCSI links to a SAN can suffer all the usual Ethernet woes -- namely bandwidth contention at the local NIC, cabling, core switch backplane, or other specific points. Check 'em all.
• Check NAS links as well. Access to network-attached storage over Ethernet can likewise suffer if there are contention bottlenecks in adapters, cabling, or switches. A protocol analyzer or other "packet sniffer" tool might help.
• Check buffers. Make sure that if multiple ports are clustered at the core switch, the line cards they're attached to have adequate buffering.
• Check coding. The data itself may be to blame. Poor coding within application that access shared databases can slow performance to a crawl, even if there's plenty of storage.
• Check your HBAs. It doesn't pay to upgrade a server to the latest Intel and AMD architecture for Exchange traffic, if you're using a low-end HBA that can't keep pace.

There is also a growing roster of tools out there to help. Startup Akorri, for instance, purports to tally response time for SAN performance. (See Point Product or Fancy Framework?.) Other general performance tools are available that analyze specific segments of the network for response time, such as the tools HP acquired with Mercury Interactive last year. (See HP Purchases Mercury.)

There's also professional help, if the problem is one of SAN or network design. That calls for caution, too. Mark Farnsworth, director of IT at civil engineering firm the Timmons Group in Richmond, Va., says he found out the hard way how careful one must be to check out resellers integrators, and other sources of advice. "You need to verify that the integrator is a qualified outfit, that they have the necessary certifications." Unless they do, you may find you can't make the most of what you've got, or get the best deals on necessary upgrades.

— Mary Jander, Site Editor, Byte and Switch