<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: about performance control in General</title>
    <link>https://community.hpe.com/t5/general/about-performance-control/m-p/3473955#M2579</link>
    <description>Sorry for the delay.  I wasn't able to get back to this stuff much this week.&lt;BR /&gt;&lt;BR /&gt;But I guess from my perspective, which is admittedly not a storage expert (but a definitely a worker), it really depends on what kind of RAID.  If you're using JBOD with MirrorDisk as your RAID control, then you may have more insight and control.  If, on the other hand, you have an EMC Symmetrix-class array, you have relatively little control (unless something has changed in the last year).  &lt;BR /&gt;&lt;BR /&gt;I don't see how you can have any real control on either throughput or average response time if you're using the very high-end, cached storage like EMC (or Hitachi, ... even an old HP AutoRAID).  If this is the case, I guess my answer would be to use the (supposedly vendor-neutral) APIs developed by EMC for ControlCenter (not real clear on this, sorry) or beg the vendor for more control.  If you're working with this storage, I'd say the best thing you can do is measure the two metrics mentioned above and throttle application performance appropriately so that they don't degrade.  But that kind of doesn't make sense...it seems like optimization is actually the goal...&lt;BR /&gt;&lt;BR /&gt;So I'm guessing you have control over the RAID functionality -- some kind of relatively low-tech stuff.  &lt;BR /&gt;&lt;BR /&gt;After a little thought, I would say yes, I think that if you guarantee average response time you can guarantee throughput to a degree -- but remember that you're only guaranteeing an *average* response time and therefore there will be spikes.  There's also system overhead related to disk I/O.  There may be a system overhead issue that is unrelated to disk response or throughput that slows down throughput because the application can't get around to issuing the I/O requests.  For example, system load suddenly jumps.  The main application (that's supposed to have the good disk performance) is now competing for CPU with everything else, and therefore it just doesn't issue its I/O requests as quickly as it did when it wasn't waiting for CPU.  &lt;BR /&gt;&lt;BR /&gt;I'm hoping some others will jump in for different perspectives.  I really don't feel like an expert -- I just have a few thoughts on it.  There are a lot of "what ifs" that still aren't specified in this example and those can make a big difference.&lt;BR /&gt;&lt;BR /&gt;HTH,&lt;BR /&gt;Mic</description>
    <pubDate>Sun, 30 Jan 2005 21:54:41 GMT</pubDate>
    <dc:creator>Mic V.</dc:creator>
    <dc:date>2005-01-30T21:54:41Z</dc:date>
    <item>
      <title>about performance control</title>
      <link>https://community.hpe.com/t5/general/about-performance-control/m-p/3473952#M2576</link>
      <description>Hi all,&lt;BR /&gt;&lt;BR /&gt;Currently I am working on a storage system performance control project. We know average response time and throughput are two important metrics.&lt;BR /&gt;&lt;BR /&gt;My question is: if we can guarantee the delay of average response time, can we say we also control the degradation of system throughput&lt;BR /&gt;well? how about vice versa? could you please give me some examples?&lt;BR /&gt;&lt;BR /&gt;Thanks&lt;BR /&gt;Dong&lt;BR /&gt;</description>
      <pubDate>Fri, 28 Jan 2005 19:38:39 GMT</pubDate>
      <guid>https://community.hpe.com/t5/general/about-performance-control/m-p/3473952#M2576</guid>
      <dc:creator>Dong Li</dc:creator>
      <dc:date>2005-01-28T19:38:39Z</dc:date>
    </item>
    <item>
      <title>Re: about performance control</title>
      <link>https://community.hpe.com/t5/general/about-performance-control/m-p/3473953#M2577</link>
      <description>Hi, Dong,&lt;BR /&gt;&lt;BR /&gt;This is a broad topic.  Are there particular types or situations that interest you?  For example:  NAS, NetApp, NFS, Brocade SAN, EMC DMX, local hard drive, ...?  In my perspective, things like "system throughput" change based on what the architecture is.  In an appliance or complex external array, you have relatively little control over what's going on.&lt;BR /&gt;&lt;BR /&gt;It might be helpful if you mentioned where you're going with it -- are you engineering new hardware, new software, trying to solve a problem, writing a paper...   :-)&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;Mic</description>
      <pubDate>Sat, 29 Jan 2005 00:01:28 GMT</pubDate>
      <guid>https://community.hpe.com/t5/general/about-performance-control/m-p/3473953#M2577</guid>
      <dc:creator>Mic V.</dc:creator>
      <dc:date>2005-01-29T00:01:28Z</dc:date>
    </item>
    <item>
      <title>Re: about performance control</title>
      <link>https://community.hpe.com/t5/general/about-performance-control/m-p/3473954#M2578</link>
      <description>Thanks Mic.&lt;BR /&gt;&lt;BR /&gt;I am working on a RAID system with new software. Some functions of this new software could induce system performance degradation.&lt;BR /&gt;We want to dynamically restrict the execution time of these functions in order to keep the performance degradation in an affordable level. Do we need to guarantee the average response time, throughput or both of them?&lt;BR /&gt;</description>
      <pubDate>Sat, 29 Jan 2005 11:18:41 GMT</pubDate>
      <guid>https://community.hpe.com/t5/general/about-performance-control/m-p/3473954#M2578</guid>
      <dc:creator>Dong Li</dc:creator>
      <dc:date>2005-01-29T11:18:41Z</dc:date>
    </item>
    <item>
      <title>Re: about performance control</title>
      <link>https://community.hpe.com/t5/general/about-performance-control/m-p/3473955#M2579</link>
      <description>Sorry for the delay.  I wasn't able to get back to this stuff much this week.&lt;BR /&gt;&lt;BR /&gt;But I guess from my perspective, which is admittedly not a storage expert (but a definitely a worker), it really depends on what kind of RAID.  If you're using JBOD with MirrorDisk as your RAID control, then you may have more insight and control.  If, on the other hand, you have an EMC Symmetrix-class array, you have relatively little control (unless something has changed in the last year).  &lt;BR /&gt;&lt;BR /&gt;I don't see how you can have any real control on either throughput or average response time if you're using the very high-end, cached storage like EMC (or Hitachi, ... even an old HP AutoRAID).  If this is the case, I guess my answer would be to use the (supposedly vendor-neutral) APIs developed by EMC for ControlCenter (not real clear on this, sorry) or beg the vendor for more control.  If you're working with this storage, I'd say the best thing you can do is measure the two metrics mentioned above and throttle application performance appropriately so that they don't degrade.  But that kind of doesn't make sense...it seems like optimization is actually the goal...&lt;BR /&gt;&lt;BR /&gt;So I'm guessing you have control over the RAID functionality -- some kind of relatively low-tech stuff.  &lt;BR /&gt;&lt;BR /&gt;After a little thought, I would say yes, I think that if you guarantee average response time you can guarantee throughput to a degree -- but remember that you're only guaranteeing an *average* response time and therefore there will be spikes.  There's also system overhead related to disk I/O.  There may be a system overhead issue that is unrelated to disk response or throughput that slows down throughput because the application can't get around to issuing the I/O requests.  For example, system load suddenly jumps.  The main application (that's supposed to have the good disk performance) is now competing for CPU with everything else, and therefore it just doesn't issue its I/O requests as quickly as it did when it wasn't waiting for CPU.  &lt;BR /&gt;&lt;BR /&gt;I'm hoping some others will jump in for different perspectives.  I really don't feel like an expert -- I just have a few thoughts on it.  There are a lot of "what ifs" that still aren't specified in this example and those can make a big difference.&lt;BR /&gt;&lt;BR /&gt;HTH,&lt;BR /&gt;Mic</description>
      <pubDate>Sun, 30 Jan 2005 21:54:41 GMT</pubDate>
      <guid>https://community.hpe.com/t5/general/about-performance-control/m-p/3473955#M2579</guid>
      <dc:creator>Mic V.</dc:creator>
      <dc:date>2005-01-30T21:54:41Z</dc:date>
    </item>
  </channel>
</rss>

