␡
- What Is Scalability?
- Detecting Performance Bottlenecks
- When to Begin Scaling
- Okay, You Need to Scale. Now What?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Detecting Performance Bottlenecks
I consider the database tier to be the critical bottleneck in an application—the last mile of true scalability. If a database is experiencing performance degradation, a performance bottleneck somewhere is likely causing the problem. Some common issues point the way to a proper resolution of performance issues:
High CPU usage is the most common performance bottleneck, but it’s often the easiest issue to resolve—sometimes simply by upgrading the server. However, despite seeming like a simple problem, high CPU usage can actually be an indicator of other causes:
- User CPU indicates that your CPU is doing productive work and the problem can be resolved with an upgrade.
- System CPU is usage consumed by the operating system, typically software related.
- I/O wait often is caused by the CPU waiting for the I/O subsystem.
- Low memory is the second most-common bottleneck. If your server doesn’t have enough memory to handle your application load, the effect on performance can be dramatic. Memory is commonly 100 times faster than disk; therefore, if you run low on—or worse, run out of—physical memory, your application can slow to a crawl. Most operating systems (Linux in particular) will automatically resort to memory swapping when this situation arises. Low memory sometimes requires only a RAM upgrade, but it can also be an indicator of memory leak, which requires identifying the leak within the application code and fixing it.
- High disk usage is the third most commonly encountered bottleneck. Of the three, this problem, caused by maxed-out disk writes, is the strongest indicator of the need for scaling. Getting a faster (and more expensive) disk is an option, but scaling is a stronger solution.