Performance Bottlenecks and Hardware
The prettiest, most featureful site or application in the world is worthless if it's not usable. Users are a pretty impatient lot -- if things don't work quickly and responsively, they will become impatient. So ensuring that your infrastructure is as performant as possible is a huge issue. As projects get bigger and userbases grow, things will inevitably slow down and your performance will suffer.
Ultimately, all performance issues stem from some sort of exhaustion of a shared resource. Any time a computer tries to execute an operation, it will try to access one or more parts of the hardware; if the parts that it needs aren't available, the operation must wait. This happens all the time, of course; it's normal and expected. As wait times increase, however, those delays can become noticeable -- and if left unchecked, the end result can be that your application fails to respond at all.
Before a performance issue can be fixed, it's important to understand what sort of resources are most commonly exhausted, and identify which one(s) are responsible. Then, once we know where the trouble lies, it must be determined if the problem is on the "supply" side, or the "demand" side. That is, do we need to make more resources available (via some sort of hardware upgrade), or do we need to make better use of our resources (by tuning/refactoring/replacing code)?
Today, we'll look at the hardware side. Going forward we'll look at some good strategies for reducing load from the software side for each of these different aspects.
When people think of a computer being "slow," the processor is usually what they think of. And sometimes that's true! Since the CPU is responsible for managing every process that runs on the machine, it's very possible that it can get bogged down with operations and fall behind. This is particularly true if there are a lot of processes running at once; the overhead involved in switching between tasks can add up quickly and lead to a non-responsive system.
If you're dealing with a processor bottleneck, the most obvious solution is to upgrade to a "faster" one. However, it may be more effective to try and "spread the load" a bit more. Adding more cores -- that is, more parallel processing units -- can let multiple tasks proceed concurrently, with less contention. However, task switching can still be a concern in these situations. Also, some processes will not scale well to multiple processors (though this is less of an issue for most modern software).
Ultimately, the most powerful way to deal with a processor bottleneck is to "farm out" work to multiple servers. For example, instead of running your web and database server on the same machine, you may split them into separate entities. This way, each process can run at full speed and never have to "wait in line" behind the other. It's also possible (and for very large installations, necessary) to have multiple servers of the same kind -- e.g. multiple load-balanced web servers, or several distributed database nodes. The downside here is, when data has to go over the network a bottleneck can be introduced there -- but with proper design, this can be kept to a minimum.
Bottlenecks on input and output can be very troublesome -- even moreso than processor bottlenecks, in some cases. This is because, while your CPU can perform billions of operations each second, your disks may only be able to process several thousand, or perhaps even only a few hundred. So if there are a lot of operations in line, waiting for them to complete can leave you with a non-responsive system that's idling it's processors!
One easy solution here is to ensure that you are using solid-state drives for any high-capacity data access. You may also consider a RAID configuration, to allow for quicker retrieval, or separating data into "chunks" that can be served from different physical drives.
If you're dealing with particularly memory-intensive operations, then this can be a bottleneck. Unless you're absolutely certain that RAM is the problem, though, you'll often be better served looking towards other improvements.
Fortunately, if you're running a 64-bit OS, fixing a RAM shortage is practically "plug-and-play" -- your system and applications should recognize and make use of additional memory automatically, though some additional tuning may be necessary to fully leverage it.
If your processes rely on access to remote data or systems, you'll want to ensure things are moving as efficiently as possible. Unfortunately, the "external" nature of the network means it can be one of the hardest to address.
There are actually two separate bottlenecks that can present on your network: bandwidth and latency. Bandwidth is a measure of how long it takes a particularly-sized chunk of data can move between two nodes, whereas latency simply measures the minimum "round-trip" time of information between nodes. Bandwidth is important, and can become an issue on older or lower-quality networks, but latency is a more common issue, particularly if there's a lot of data that must go "back and forth."
For example, a web server making requests off a remote database might make a 50ms round trip. While that's not a lot on its own, ten requests running sequentially will add half a second or more
Eliminating bandwidth bottlenecks requires you to make sure your hardware is fast enough -- gigabit networks are quite inexpensive, and multi-gigabit or fiber networks are available for very high-capacity use cases. To address latency, it's beneficial to keep servers as close together as possible, both physically and logically. Minimizing the amount of hardware and cabling between them will help keep latency at a minimum.
Performance issues are universal in any sort of software development, and understanding how and where those issues arise is crucial to solving them. Smart Software Solutions has the experience and expertise necessary to help you identify bottlenecks, minimize their impact, and recommend the best way forward for whatever project you might have.