<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Load Testing on Anthony Nocentino&#39;s Blog</title>
    <link>https://www.nocentino.com/tags/load-testing/</link>
    <description>Recent content in Load Testing on Anthony Nocentino&#39;s Blog</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 27 Apr 2026 08:00:00 -0500</lastBuildDate>
    <atom:link href="https://www.nocentino.com/tags/load-testing/rss.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Designing a Storage Load Test for SQL Server</title>
      <link>https://www.nocentino.com/posts/2026-04-27-designing-a-storage-load-test-for-sql-server/</link>
      <pubDate>Mon, 27 Apr 2026 08:00:00 -0500</pubDate>
      <guid>https://www.nocentino.com/posts/2026-04-27-designing-a-storage-load-test-for-sql-server/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve been doing storage load tests for SQL Server for a long time, both as a consultant and now in my work at Everpure, and I see the same patterns over and over. Someone spins up a VM with two vCPUs, points it at a storage subsystem (cloud or on-prem), runs a thousand threads at it, and then concludes that the storage stinks. Or the opposite, where they buy a 64 gigabit HBA, plug it into the wrong PCIe slot, and wonder why they&amp;rsquo;re leaving half of the capacity on the table.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
