Why would a heavily disk intensive application run faster on a SAN than on a Physical Disk? I would have expected the Physical disk to be slightly faster but in fact the process ran 100 times faster when it's work drive was set to a partition on the SAN.

Our guess is that the SAN is optimised out of the box to be fast whereas the physical disk tuning settings are OS (Solaris) related and have not been touched or the OS patched.

During the highest activity the disk I/O was running at 100% and the time to complete a write was over 2 seconds as several processes were writing to the disk at the same time.

(FYI the application involved was Informatica PowerCenter)

4 Answers 4


I'm not at all surprised. SAN arrays typically have a LOT of disks involved. The limiting factor for disk I/O is the speed of the individual disk, and these stack. 6 drives locally in a RAID10 will perform better than 2, and 80 drives on a SAN will perform better than 10 drives locally. There are variables of course, but that's how it's supposed to work.

Also, if the SAN has any SSDs involved, things get really zippy.


It's almost certainly due to caching. The DAS probable has minimal caching, where most Enterprise SANs have multiple gigabytes of cache. I'd guess the app is saturating the DAS's cache, but not the SAN's.

  • 1
    Obvious latency on the SAN is going longer than the DAS but overall throughput is higher on the SAN with all it's caching. Good answer.
    – hookenz
    Sep 9, 2011 at 0:18
  • and then there is often a read ahead cache so its random read/writes that take the biggest hit and then you can cache writes so its only random reads that get impacted, still a pretty small delay though.
    – Silverfire
    Sep 9, 2011 at 0:52
  • 1
    A properly configured Storage Subsystem on the SAN that isn't overloaded should be giving you random write times around 1-2ms.
    – MikeyB
    Sep 9, 2011 at 4:09
  • @MikeyB I'm not disagreeing with you. 1-2ms write to SAN seems right. But Charles' SAN config was 100 times faster than his overloaded physical disks (writes were > 2sec for latter). So even his SAN performance isn't so good, at 20ms rather than 1-2ms...? Sep 9, 2011 at 8:26

Conceptually it always feels like serving disk from SAN should be slower than serving it locally. However, there are plenty of factors which can reverse this and result in the SAN being a much faster option. Some of these factors are:

  • Does your workload require fast seek time or fast throughput, or both?
  • How many spindles on the SAN LUN versus the local disk?
  • What bus speed between the SAN LUN and the server, versus the local disk interface?
  • How much read/write cache is available on the SAN LUN vs the local disk?
  • What speed are the disks spinning at on the SAN LUN versus the local disk?
  • What other IO activity is taking place on the SAN LUN versus the local disk?
  • What RAID level are the arrays on the SAN and local storage?

All of these will affect your performance on SAN and local disk.


It all comes down to how many spindles are available.... The higher number of spindles the quicker it is to access any given piece of data. if you are heavy IO intensive, particularly if you are a database app, then you can quite easily bury local disk performance with a SAN solution which can have a far higher number of disk sets for the management of core data, indexes and such.

With the local disk subsystem you are also likely sharing access to the read/write heads with other operations, such as r/w to swap, local OS and library file access, application access, etc... While individually fast, the collective time for all of the read/write actions to move the read/write heads from one area of the disk to cover one set of actions to another to satisfy your application requirements can certainly beat on performance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .