Skip to main content

10 Reasons Why Your Applications May Not Be Reaching Advertised Performance Levels

Cassius Rhue
SIOS Technology

Many times customers want to know why their measured performance doesn't match the speed advertised (by the platform vendor, software vendor, network vendor, etc). Assuming the advertised speeds are (a) within the realm of physical possibility and obeys the laws of physics, and (b) are real achievable speeds and not "click-bait," there are at least ten reasons for being unable to achieve advertised speeds. In situations where customer expectations and measured performance don't align, use the following checklist to help determine the reason(s) why.

1. Processing power of your computer

No matter the task, or number of tasks, CPU power, CPU cache, and threading capability will be essential factors in achieving performance benchmark results. Lower CPU power, or CPUs with lower clock speeds determine how quickly the system can complete its tasks, including launching the test harness, writing to the network, writing to disk, and a host of other tasks.

2. Latency

Latency is defined as "the delay before a transfer of data begins following an instruction for its transfer." In terms of performance, multiple forms of latency can impact the results. Network latency, which is the amount of time it takes for the data to move from one place to another, can degrade performance in a replication configuration. In addition to network latency, systems can experience data transfer latency between the attached disks, storage devices, platforms and within the software solution. Data transfer latency can also impede performance.

3. Limitations of your network

While latency is one of the most common issues with networks, other issues can exist within the network that cause differences between the measured and advertised performance. These differences include topology, deployed switches, routers, firewalls and other devices within the architecture. For example, a firewall that is analyzing packets and traffic can create delays in performance.

4. Additional devices on the network

Additionally, if you are not using a fully isolated environment, that is, an environment where servers, switches, storage cabinets, etc. are not affected by network traffic associated with other devices, then those additional devices on the network which are also consuming available bandwidth will cause performance degradation.

5, Additional devices on the hypervisor

Similar to point four above, the presence of additional virtual machines on a hypervisor host (VM, Hyper-V, KVM, etc) can impact the measured performance of other VMs running on it. Hosting multiple virtual machines on a single hypervisor host, while practical for many applications and situations, may also introduce a phenomenon known as "noisy neighbor" which can cause additional performance issues and performance loss. This loss typically shows up in tests specifically aimed at proving performance numbers.

6. Outdated drivers

When outdated, several different types of drivers can cause performance loss or issues, especially network and storage drivers. Outdated drivers may contain bugs that have been fixed in future versions, or lack optimizations and enhancements that drive performance to higher numbers. In addition, an outdated driver may not operate correctly with other parts of the stack. It is best to always run with the latest driver version for your configuration, architecture, and test case.

7. Memory Speed and Capacity

Memory speed determines the ability of the computer to perform at scale. Lower total memory capacity and lower memory speeds can cause sluggish performance, especially if the test harness for measuring performance requires multi-threading. In addition, low system memory can result in excessive page swapping and disk thrashing. In addition, faster memory enhances the computer's ability to transfer large amounts of data between the parts of the system, including disks, networks, and other applications.

8. Outdated OS and/or application software

Similar to outdated drivers, attempting to measure performance of an application, architecture, or HA solution while running outdated software can drastically impact your measurements.Outdated software can contain bugs that impact performance and have been fixed or remediated in newer versions. In addition, newer versions of software most likely contain enhancements that harness the improvements of modern infrastructure, faster CPUs and more memory. If you aren't getting close to advertised speeds, be sure to update the software involved in the testing.

9. Infrastructure health

The health of the infrastructure is another important factor in achieving published performance numbers. Regardless of whether the systems are hosted on-prem or in the cloud, if the components within the infrastructure are unhealthy, the published numbers will be harder to achieve. For example, any component within the network, compute, or storage layer of the infrastructure that is performing sub-optimally will jeopardize the performance.

10. Test harness

Do not forget that the test harness, the tools used to measure the expected performance, can also play a role in reaching or not reaching the expected results. As a simple example, using different versions of a test tool, or different parameters and options can lead to different results. In a more complicated scenario, using a database benchmark tool to measure replication and HA performance will have a different outcome than using a tool that focuses on measuring the speed independent of the applications involved. In other words, measuring speed with or without other layers of processing between the tool and the underlying system components (software, hardware, etc.) can change the performance numbers.

I could add a number of other items to the list regarding performance, including system usage, environmental factors, disk IOPS, and type of operations (sync or async replication, for example). While this list is not exhaustive, it does provide customers a small window of insight into what may be causing the difference between measured and advertised performance. Be sure to use this list, and your own additional suggestions to properly identify the bottlenecks and critical issues. Then focus on eliminating inefficiencies in any of these items, and remediating things to increase the overall performance of the system.

Cassius Rhue is VP of Customer Experience at SIOS Technology

The Latest

Cloud outages are usually described as technical failures. When a service goes down, a dependency breaks, or a region has issues, the focus immediately shifts to infrastructure. But if you look closely at how these incidents actually unfold, the root cause is rarely the technology itself. It is almost always tied to decisions made earlier, during design, implementation, or day-to-day operations. The system behaves the way it was built. The real question is how it was built ...

77% of leaders say their teams need AI skills urgently. 64% say their organization plans to train current employees rather than hire new ones. So far, so reasonable. The part that surprised me is who's been put in charge: 34% of those leaders say IT and engineering own the AI skills mandate. Learning and Development or HR own it at 7% of organizations. That's roughly five-to-one in favor of the people who understand the tools, over the people whose actual job is teaching adults how to learn new ones ...

In the ever-evolving digital landscape, enterprises are increasingly focused on enhancing their observability stacks to gain deeper insights into their IT environments. Observability has become a cornerstone of modern IT operations, enabling organizations to monitor, diagnose, and optimize their systems with unprecedented precision. However, a critical piece of the puzzle often goes unnoticed in this transformation: IBM i ...

We just surveyed 300 frontend and mobile engineers across 16 countries, and the finding that keeps sticking with me isn't the one about AI. It's this: 74% of engineering teams rate themselves in the "middle" of the observability maturity scale. Not reactive, not strategic. Stuck in the middle. They have dashboards, they have tracing, they have alerts. And yet when something goes wrong, they still can't tell you why ...

In MEAN TIME TO INSIGHT Episode 25, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses  AI's impact on the Wide Area Network (WAN) ... 

Application performance monitoring (APM) dashboards are only as useful as what they are configured to measure. The default setup covers obvious failure modes such as downtime, error spikes, and latency breaches, but it does not cover everything. Some failures produce no alerts or anomalies. The dashboard stays green while users experience a broken product. Here are six signs that is happening ...

The race to deploy AI is largely over. Most enterprises have entered it. The question now is not whether artificial intelligence is running inside the organization. The question is whether anyone is genuinely responsible for what it does. That is not a technical question. It is a leadership one. And most organizations are not yet structured to answer it honestly ...

A new analysis of 250 real-world queries across common retail tasks, such as product pricing, availability, ratings, shipping and specifications, reveals systemic inefficiency at the heart of web-based AI agents. On average, 97.9% of the data retrieved by agents from live web pages is irrelevant to the query being answered. Specifically, the average page ingested ran nearly 9,000 characters, while the average answer was just 32 characters, resulting in a noise-to-signal ratio of 278:1. Price queries were the most extreme outlier, with noise rates approaching 99.5%. That's not a rounding error. That's a structural problem ...

The enterprises that will define the next decade are not the ones that deployed the most technology. They are the ones who understood what their technology was actually doing. That distinction is not a philosophical point. It is the central operational challenge facing every organization that has spent the last five years modernizing at speed ...

AI is becoming the operating system of the enterprise. It acts as an invisible coordination layer that understands intent, connects systems, and executes work across complex SaaS environments. Previously, employees had to click through multiple systems — CRM, ERP, support tools, collaboration platforms — to complete a single task. Now, instead of navigating each application manually, they can simply state what they need to accomplish ...

10 Reasons Why Your Applications May Not Be Reaching Advertised Performance Levels

Cassius Rhue
SIOS Technology

Many times customers want to know why their measured performance doesn't match the speed advertised (by the platform vendor, software vendor, network vendor, etc). Assuming the advertised speeds are (a) within the realm of physical possibility and obeys the laws of physics, and (b) are real achievable speeds and not "click-bait," there are at least ten reasons for being unable to achieve advertised speeds. In situations where customer expectations and measured performance don't align, use the following checklist to help determine the reason(s) why.

1. Processing power of your computer

No matter the task, or number of tasks, CPU power, CPU cache, and threading capability will be essential factors in achieving performance benchmark results. Lower CPU power, or CPUs with lower clock speeds determine how quickly the system can complete its tasks, including launching the test harness, writing to the network, writing to disk, and a host of other tasks.

2. Latency

Latency is defined as "the delay before a transfer of data begins following an instruction for its transfer." In terms of performance, multiple forms of latency can impact the results. Network latency, which is the amount of time it takes for the data to move from one place to another, can degrade performance in a replication configuration. In addition to network latency, systems can experience data transfer latency between the attached disks, storage devices, platforms and within the software solution. Data transfer latency can also impede performance.

3. Limitations of your network

While latency is one of the most common issues with networks, other issues can exist within the network that cause differences between the measured and advertised performance. These differences include topology, deployed switches, routers, firewalls and other devices within the architecture. For example, a firewall that is analyzing packets and traffic can create delays in performance.

4. Additional devices on the network

Additionally, if you are not using a fully isolated environment, that is, an environment where servers, switches, storage cabinets, etc. are not affected by network traffic associated with other devices, then those additional devices on the network which are also consuming available bandwidth will cause performance degradation.

5, Additional devices on the hypervisor

Similar to point four above, the presence of additional virtual machines on a hypervisor host (VM, Hyper-V, KVM, etc) can impact the measured performance of other VMs running on it. Hosting multiple virtual machines on a single hypervisor host, while practical for many applications and situations, may also introduce a phenomenon known as "noisy neighbor" which can cause additional performance issues and performance loss. This loss typically shows up in tests specifically aimed at proving performance numbers.

6. Outdated drivers

When outdated, several different types of drivers can cause performance loss or issues, especially network and storage drivers. Outdated drivers may contain bugs that have been fixed in future versions, or lack optimizations and enhancements that drive performance to higher numbers. In addition, an outdated driver may not operate correctly with other parts of the stack. It is best to always run with the latest driver version for your configuration, architecture, and test case.

7. Memory Speed and Capacity

Memory speed determines the ability of the computer to perform at scale. Lower total memory capacity and lower memory speeds can cause sluggish performance, especially if the test harness for measuring performance requires multi-threading. In addition, low system memory can result in excessive page swapping and disk thrashing. In addition, faster memory enhances the computer's ability to transfer large amounts of data between the parts of the system, including disks, networks, and other applications.

8. Outdated OS and/or application software

Similar to outdated drivers, attempting to measure performance of an application, architecture, or HA solution while running outdated software can drastically impact your measurements.Outdated software can contain bugs that impact performance and have been fixed or remediated in newer versions. In addition, newer versions of software most likely contain enhancements that harness the improvements of modern infrastructure, faster CPUs and more memory. If you aren't getting close to advertised speeds, be sure to update the software involved in the testing.

9. Infrastructure health

The health of the infrastructure is another important factor in achieving published performance numbers. Regardless of whether the systems are hosted on-prem or in the cloud, if the components within the infrastructure are unhealthy, the published numbers will be harder to achieve. For example, any component within the network, compute, or storage layer of the infrastructure that is performing sub-optimally will jeopardize the performance.

10. Test harness

Do not forget that the test harness, the tools used to measure the expected performance, can also play a role in reaching or not reaching the expected results. As a simple example, using different versions of a test tool, or different parameters and options can lead to different results. In a more complicated scenario, using a database benchmark tool to measure replication and HA performance will have a different outcome than using a tool that focuses on measuring the speed independent of the applications involved. In other words, measuring speed with or without other layers of processing between the tool and the underlying system components (software, hardware, etc.) can change the performance numbers.

I could add a number of other items to the list regarding performance, including system usage, environmental factors, disk IOPS, and type of operations (sync or async replication, for example). While this list is not exhaustive, it does provide customers a small window of insight into what may be causing the difference between measured and advertised performance. Be sure to use this list, and your own additional suggestions to properly identify the bottlenecks and critical issues. Then focus on eliminating inefficiencies in any of these items, and remediating things to increase the overall performance of the system.

Cassius Rhue is VP of Customer Experience at SIOS Technology

The Latest

Cloud outages are usually described as technical failures. When a service goes down, a dependency breaks, or a region has issues, the focus immediately shifts to infrastructure. But if you look closely at how these incidents actually unfold, the root cause is rarely the technology itself. It is almost always tied to decisions made earlier, during design, implementation, or day-to-day operations. The system behaves the way it was built. The real question is how it was built ...

77% of leaders say their teams need AI skills urgently. 64% say their organization plans to train current employees rather than hire new ones. So far, so reasonable. The part that surprised me is who's been put in charge: 34% of those leaders say IT and engineering own the AI skills mandate. Learning and Development or HR own it at 7% of organizations. That's roughly five-to-one in favor of the people who understand the tools, over the people whose actual job is teaching adults how to learn new ones ...

In the ever-evolving digital landscape, enterprises are increasingly focused on enhancing their observability stacks to gain deeper insights into their IT environments. Observability has become a cornerstone of modern IT operations, enabling organizations to monitor, diagnose, and optimize their systems with unprecedented precision. However, a critical piece of the puzzle often goes unnoticed in this transformation: IBM i ...

We just surveyed 300 frontend and mobile engineers across 16 countries, and the finding that keeps sticking with me isn't the one about AI. It's this: 74% of engineering teams rate themselves in the "middle" of the observability maturity scale. Not reactive, not strategic. Stuck in the middle. They have dashboards, they have tracing, they have alerts. And yet when something goes wrong, they still can't tell you why ...

In MEAN TIME TO INSIGHT Episode 25, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses  AI's impact on the Wide Area Network (WAN) ... 

Application performance monitoring (APM) dashboards are only as useful as what they are configured to measure. The default setup covers obvious failure modes such as downtime, error spikes, and latency breaches, but it does not cover everything. Some failures produce no alerts or anomalies. The dashboard stays green while users experience a broken product. Here are six signs that is happening ...

The race to deploy AI is largely over. Most enterprises have entered it. The question now is not whether artificial intelligence is running inside the organization. The question is whether anyone is genuinely responsible for what it does. That is not a technical question. It is a leadership one. And most organizations are not yet structured to answer it honestly ...

A new analysis of 250 real-world queries across common retail tasks, such as product pricing, availability, ratings, shipping and specifications, reveals systemic inefficiency at the heart of web-based AI agents. On average, 97.9% of the data retrieved by agents from live web pages is irrelevant to the query being answered. Specifically, the average page ingested ran nearly 9,000 characters, while the average answer was just 32 characters, resulting in a noise-to-signal ratio of 278:1. Price queries were the most extreme outlier, with noise rates approaching 99.5%. That's not a rounding error. That's a structural problem ...

The enterprises that will define the next decade are not the ones that deployed the most technology. They are the ones who understood what their technology was actually doing. That distinction is not a philosophical point. It is the central operational challenge facing every organization that has spent the last five years modernizing at speed ...

AI is becoming the operating system of the enterprise. It acts as an invisible coordination layer that understands intent, connects systems, and executes work across complex SaaS environments. Previously, employees had to click through multiple systems — CRM, ERP, support tools, collaboration platforms — to complete a single task. Now, instead of navigating each application manually, they can simply state what they need to accomplish ...