"Question: Why is my site slow? Answer: Too much is being asked of the current solution Solution: Ask less of the servers or add more resources"
It’s a common question asked by almost any administrator or webmaster at some point or another. Perhaps it was working fast early on and now response times seem to be slower. Maybe it's been slow right out of the gate and you wondering what you could do to improve it.
A colleague of mine, Drew Cox @DrewCoxSA made the statement above just in passing and it occurred to me that there was a good deal of merit in his statement. There are a lot of reasons and just as many solutions to solve the problem. In this article, I will cover two common reasons as to why your site might be running slow. And, I'll go over a few solutions as well.
Too much is being asked of the current solution.
Many times I see people running a software configuration that is too big for the number of servers available. This might be due to budget or lack of knowledge. It's important to consider that not only do your applications need memory to run, but each visit to your site will consume resources as well as the resources that the operating system needs to run.
When applications need to run alongside each other, they will compete for disk I/O, memory, network, and CPU. If, for example, an application needs to run to process a request, CPU consumption could slow things down for other apps that are also on that same system. Until that request has been processed, other systems functions are going to be slower. The same thing holds true if there is a large amount of available bandwidth being consumed. Accessing the server will be difficult until the request has been served.
In the physical world, you will need to build servers with the right resource specifications to handle the demands it receives.
In an earlier article, I mention decoupling as a solution. This means separating certain functions of your application to their own tiers of workers and then you can scale those that have the heaviest load.
Another solution for this might be "___ as a Service" options like database as a service or DaaS. Using a database as a service you don't have to spin up the exact same size in terms of disk and memory as you would need for a cloud server. You run/pay for only the amount of system requirements your application requires.
Ask less of the current solution or add more resources
Adding more resources or making the configuration bigger is sometimes the solution that is considered first. If two is good four is better, right? And, if four is better than eight must be awesome. There are some cases where this holds true. When you scale up there is a point of diminishing returns. Sometimes you get to a point were adding more resources yields no net gain in performance. The reasons why this happens are the kernel parameters are configured with certain thresholds. Those include how many connections you can have, how much memory the connections take, open file limits and more.
There are ways to ask less of your servers and still achieve a significantly high output. The use of a content delivery network or CDN is one of those ways. Think of CDNs as vending machines on the Internet.
If you want a soda there are multiple different ways to obtain one. The first way would be to get into your car, drive to the store and purchase a soda. This would be the equivalent to what is called an origin pull on the Internet. The visitor is pulling information directly from the server. The server has to process the request and deliver the results.
Another way to obtain a soda is to get it from a vending machine. Rather than driving to the store, you can go to a vending machine that is just down the hall and purchase your soda there. The soda is closer to where the request is being made. This is what a CDN pull is like. The CDN has the information ready to be served at a closer location to the requester. These are called edge nodes. By serving up content through a CDN, your server doesn't have to work as hard and you can deliver a better experience with fewer resources.
Conclusion
There are many variables that impact site response times. It's usually an indication that the current configuration does not meet the demands of the traffic it is receiving. Since reducing traffic is not an option it's time to look at where the bottlenecks are and make the necessary adjustments.
"Do less, better." - Drew Cox
Have a comment?
So, what do you think? Did I miss anything? Is any part unclear?