What is important to document concerning disk IO

[jonsilver]

We are offering our product in a virtualized environment. We can specify the amount of CPU, ram and Disk,

but do we not also need to document the required disk bandwidth (throughput) needed for I/O.

Assuming that the customer installs using a SANs, then I'm guessing that they would need this data, otherwise, our solution could die or

kill their network?? I'm pretty new to this so I'm trying to understand what we need to document and how to derive those numbers.

I looked at windows perfmon, but it does not really provide me with what I thought that we needed; Do I publish

logical Disk.Disk Transfers/sec, logical Disk.Disk Write Bytes/sec and logical Disk.Disk read Bytes/sec and then is that all?

thanks,

jon

[Josh26]

jonsilver wrote:

We are offering our product in a virtualized environment. We can specify the amount of CPU, ram and Disk,

but do we not also need to document the required disk bandwidth (throughput) needed for I/O.

Assuming that the customer installs using a SANs, then I'm guessing that they would need this data, otherwise, our solution could die or

kill their network?? I'm pretty new to this so I'm trying to understand what we need to document and how to derive those numbers.

I looked at windows perfmon, but it does not really provide me with what I thought that we needed; Do I publish

logical Disk.Disk Transfers/sec, logical Disk.Disk Write Bytes/sec and logical Disk.Disk read Bytes/sec and then is that all?

thanks,

jon

Can you clarify this - are you basically writing a "minimum specs" guide for your app, so that a customer can install it in a virtual environment?

The answer in general would be:

* No you can't kill their network, what does disk IO have to do with that? Unless of course your app for some reason generates BPDU packets.....

* Surely any attempt at documenting "required" disk IO would be a stab in the dark. No two customers will have the same use patterns of your product. Even something like Microsoft SQL server doesn't document "minimum disk bandwidth". It can scale to a very high end where it would require a large RAID array but runs fine, in the right environment, on two SATA disks.

* If you release an application stating "minimum requirements: Disk transfers: x/sec" you will be a very difficult vendor to deal with

[jonsilver]

Yes - We are basically writing a "minimum specs" guide for our app, so that a customer can install it in a virtual environment.

Don't all products need to specify this kind of info?

So we've defined CPU, Disk, Network, RAM.  But assuming that a customer is going to use SANs, then disk bandwidth gets added to network bandwidth correct?

and if SANS is too slow, our real time application may not be able to operator real time. We output huge amounts of data, what will happen if the SANs is too slow?

I assume that windows/unix will slow down? and we will have application performance problems.

So, I think that we need to specify disk bandwidth requirements, but I'm not exactly sure where to get the data. Using perform, I see only

            logical Disk.Disk Transfers/sec,

            logical Disk.Disk Write Bytes/sec

            logical Disk.Disk read Bytes/sec

    is that enough?

thanks,

jon

[jwhitehv]

jonsilver wrote:

So, I think that we need to specify disk bandwidth requirements, but I'm not exactly sure where to get the data. Using perform, I see only

            logical Disk.Disk Transfers/sec,

            logical Disk.Disk Write Bytes/sec

            logical Disk.Disk read Bytes/sec

    is that enough?

thanks,

jon

Bandwidth is good to have if it falls outside the norm (huge writes in a video recording app, for example).  Normally IOPS is what you'd want to specify, with a read/write ratio if you're really friendly.