Digital Edge: Common Misconceptions

It’s enough to stress-test a system after it is developed. Small changes cannot spoil a stress-tested, well-behaved system... right?
If a system works slowly, we just need a bigger and faster server
It is always easy to add another server
There is no need to profile common usage patterns for script development; we can just use the most-used path
If there is a problem with basic performance metrics (I/O, memory, CPU, or network) we just need to add hardware

MANAGED COLO SERVICES

MONITORING SERVICES

PERFORMANCE SERVICES

APPLICATION SERVICES

1. It’s enough to stress-test a system after it is developed. Small changes cannot spoil a stress-tested, well-behaved system... right?

Wrong. Actually, even a small code change can produce catastrophic performance change. For example: programmers decide to split one database into two. One contains read-only information; another is updatable. Each page on the website starts using two connections, instead of one. This yields systems performance degradation from 10,000 concurrent users to 3,000 (because a number of concurrent TCP/IP connections that SQL server could handle). Changing the TCP/IP settings boosts the amount of TCP/IP connections-and system performance returned to normal.

2. If a system works slowly, we just need a bigger and faster server

This is not always true. Sometimes when a program is written directly to hardware specs, performance is not affected at all. And there are many examples of when purchasing 50%-stronger hardware results only in a 10% boost in performance. However, simple application logic change can regularly yield a 200% to 300% performance improvement.

3. It is always easy to add another server

This may be the case for web or application layers, yet it is hard to scale-out databases. To add a server to processing the application should be adjusted so it will use 100% of that particular resources.

4. There is no need to profile common usage patterns for script development; we can just use the most-used path

Although you may be sure 99% of users will use a common usage scenario and 1% of users will use something else, that 1% must be scripted, as well. Unfortunately, that 1% can produce more performance problems than the remaining 99% of common users. Many times, a very small amount of activity can lockup the entire system.

5. If there is a problem with basic performance metrics (I/O, memory, CPU, or network) we just need to add hardware.

This is not always true. For example, your basic performance parameters may show that you are lacking I/O. Boosting I/O may cost you tens of thousands of dollars when, instead, simple memory extension and system reconfiguration may decrease the I/O burden dramatically (at very little cost).