As the self-proclaimed storage vigilante, I will keep bringing these idiocies up as I come across them.
So, the latest “thing” now is selling systems using “Raw IOPS” numbers.
Simply put, some vendors are selling based on the aggregate IOPS the system will do based on per-disk statistics and nothing else.
They are not providing realistic performance estimates for the proposed workload, with the appropriate RAID type and I/O sizes and hot vs cold data and what the storage controller overhead will be to do everything. That’s probably too much work.
Continue reading “So now it is OK to sell systems using “Raw IOPS”???”
<I understand this extremely long post is redundant for seasoned storage performance pros – however, these subjects come up so frequently, that I felt compelled to write something. Plus, even the seasoned pros don’t seem to get it sometimes… 🙂 >
IOPS: Possibly the most common measure of storage system performance.
IOPS means Input/Output (operations) Per Second. Seems straightforward. A measure of work vs time (not the same as MB/s, which is actually easier to understand – simply, MegaBytes per Second).
How many of you have seen storage vendors extolling the virtues of their storage by using large IOPS numbers to illustrate a performance advantage?
How many of you decide on storage purchases and base your decisions on those numbers?
However: how many times has a vendor actually specified what they mean when they utter “IOPS”? 🙂
For the impatient, I’ll say this: IOPS numbers by themselves are meaningless and should be treated as such. Without additional metrics such as latency, read vs write % and I/O size (to name a few), an IOPS number is useless.
And now, let’s elaborate… (and, as a refresher regarding the perils of ignoring such things when it comes to sizing, you can always go back here).
Continue reading “An explanation of IOPS and latency”
<Article updated with more accurate calculation>
There are some impressive new scores at storageperformance.org, with the usual crazy configurations of thousands of drives etc.
When looking at $/IOP, make sure you are comparing list price (look at the full disclosure report, that has all the details for each config).
Otherwise, you could get the wrong $/IOP since some vendors have list prices, others show heavy discounting.
Continue reading “Interpreting $/IOPS and IOPS/RAID correctly for various RAID types”
With the advent of performance-altering technologies (notice the word choice), storage sizing is just not what it used to be.
I’m writing this post because more and more I see some vendors not using scientific methods to size their solution, instead aiming to reach a price point, hoping the technology will work to achieve the requisite performance (and if it doesn’t, it’s sold anyway, either they can give some free gear to make the problem go away, or the customer can always buy more, right?)
Continue reading “Buyer beware: is your storage vendor sizing properly for performance, or are they under-sizing technologies like Megacaching and Autotiering?”
Some of the comments in my previous post asked about $/IOPS and $/TB.
Since SPEC doesn’t require prices to be listed, I did my own analysis.
The NetApp numbers are simply 4x the existing 6240 result, which is what EMC did with their submission, they used 4x separate VNX systems and aggregated the result.
Continue reading “Examining value for money regarding the SPEC benchmarks”