In the world of storage performance there’s three types of performance numbers that I typically see:
(1) The pumped up marketing numbers from the providing vendor. This is essentially measured when the system is “running down hill with the wind at its back”. These numbers are usually derived from some 100% optimized yet completely unrealistic configuration.
(2) The perceived performance that the customer thinks they’ll get with some fuzzy calculation of the marketing numbers.
(3) The actual numbers that can’t really be assessed without trying it out.

The toughest question for any storage administrator to answer is, “What kind of performance do you NEED?” This is a loaded question, because it involves the characterization of the data itself (file sizes, block sizes, application, etc…), the performance that is driven from the “user” of the data (clients – how many, how often) during NORMAL and PEAK operation. In the end it becomes a very subjective question for the small shop IT Pro to answer. After all, you can always make data access faster – but when is it fast enough?

This is an instance where storage vendors ask customers to quantify something that is completely dependent on the tolerance of performance (or lack-there-of) by the end user of the data. The question we are really asking is, “How fast do YOU WANT your storage to be?”

SIDEBAR: I must counter all of the above however with one caveat: I’ve talked with customers (usually larger companies) that can actually characterize their data fairly well. For databases performance is often measured by latency (measured in milliseconds) and IOPS (I/O’s per second). For other environments (storage of large media files for example), performance is often measured by throughput (MB/sec - Megabytes per second). In large enterprises they don’t have the luxury of “tolerating” poor performance, because if they don’t sufficiently account for the necessary peaks, it could lead to an application failure - which wouldn’t be good if they’re looking to stay employed in that position for very long!

When talking with the small and medium enterprises, however, it’s a very different story. They fit the profile I described up top where they have to guest-imate performance requirements, not because they couldn’t make a more accurate estimate, but because in many instances, storage performance is not the bottleneck.

In the end, if I’m talking to someone that hasn’t really characterized their storage performance needs, and they reverse the situation and ask me, “How fast is the performance of ’such-and-such’ product or solution?” I end up chickening out. I always point to the “marketing” numbers first, then some rough ‘swag’ of what I think they might get based on what they’ve told me, and then I complete my answer by telling them that it depends on their specific environment and configuration – the only way to really know is to try it!

For the big enterprises that know how to answer this question - I bow down to you - for the rest of you that are too busy “fighting fires” and have no staff to put on figuring it out good luck! Maybe we can all put our heads together and answer the question, “When is fast, fast enough?”

So if you know when fast is fast enough, comment back. I’d love to hear it! Oh, and don’t start your comment with “it depends”. No kidding!

Blog ya later!

Joe

This entry was posted on Thursday, November 3rd, 2005 and is filed under General, Storage Applications, Application Environments, Advisor - Joe Disher. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.