What to Watch When Watching Your ServerEditor’s Note: The following is an excerpt from a recent white paper about server scaling published by ServInt titled, “How do You Know When it’s Time to Scale?” You can download the full white paper here.
The only criterion that matters when when it is time to scale is how fast your sites’ pages load and applications execute. There is no standard for this. Site visitors to a forum with millions of threads and very important content will probably put up with slightly longer load times than someone visiting a landing page for a site they’ve never seen before. Only you can determine how fast is fast enough.
But remember, we’re not talking about simply running a program on your server and waiting until it finishes. We’re talking about things like the number of MySQL queries per second your server can handle, or the number of Apache web processes. And the hard part is, there’s no way to give a standard number that every server should be able to handle. Queries are not all equal. The number of queries a given server will be able to execute has to do with the complexity of the queries. Planning for server scaling is about watching trends over a single server and determining when your applications are not performing as well as you’d like.
Let’s say you decide your site or application is doing well – pages load pretty quickly and your visitors aren’t complaining. Now you need to monitor the resource usage on your server to get a sense of how much it takes for the performance you have and see trends as they develop. The main resource factors to consider are traffic, disk storage and I/O, CPU, and memory. All of these contribute to the speed your queries are being served up to a given user.
Traffic – or bandwidth – is simply a measure of the data moving in and out of your server and over the network for a given time. Traffic is measured in bits per second. It’s simply how many ones and zeros you’re pushing out the door and letting back in.
In most scenarios, if you’re serving up web pages you’ll have much more outbound traffic as your site visitors simply send requests to see information in the form of pages that your server sends over the network.
Few providers give customers unlimited bandwidth, but – assuming your server can handle the traffic and your provider’s network has enough connectivity – there is no functional limit to the amount of bandwidth a particular server package can consume. Since bandwidth costs money, providers charge customers who go over predetermined limits. The good news is that with simple prepayment or negotiating you can often avoid excessive overage charges for bandwidth. The key – once again – is to monitor your service and figure out what you will need ahead of time.
How much of your allocated hard drive space are you using? How much do you have left? The amount of space you have left doesn’t really affect site performance — until you run out of space and everything stops working. That’s why you always need to keep an eye on available disk. You won’t see performance issues until you’re out of disk and it’s too late.
Another important consideration when you are struggling with slow site performance and suspect the cause is the disk is the performance of the disk array itself. Are the drives SATA, SAS or SSD? If magnetic drives, what is the spindle speed? Is the host machine running drives in a RAID array? If so, what RAID level? In addition to granting data protection against drive failure, different RAID levels can greatly increases read/write speed (I/O) over a single disk depending on how many drives are in the array.
Want to learn more about disk technology? Read our web series.
As the “brain” of your server, it’s a common theory that measuring CPU usage will give you a measure of the load on your server. In truth, this is a faulty metric because a CPU is either used or not. A CPU can’t be half used, it can only be used half of a specific time period. A better CPU simply completes a computation faster than a worse processor.
Furthermore, if we are measuring CPU usage, we are measuring the percentage of time used of a specific CPU. It is very difficult to quantify the power of one CPU over another for purposes of comparison. Many make the mistake of falsely comparing GHz – “clock speed” – between processor models, but with multiple cores, hyperthreading, cache sizes, GT/s QPI speeds, etc., any meaningful comparison between servers with different CPUs when considering upgrades is very difficult.
One way to compare CPUs accurately is by PassMark number. PassMark software rates most known CPUs on the same performance scale and posts the results for comparison. Still, this is really the territory of dedicated hardware. When you are on a host node with other users – whether in a VPS or other cloud environment – CPU usage is very difficult to track (and could only be tracked in terms of time or cycles anyway) with bursting and throttling necessary to prevent any one customer from hogging time on a CPU that serves multiple users.
Memory – in the form of RAM – is a very simple way of gauging the usage of a system. Memory, like disk, is a finite and discreet thing. It is an amount of space available to temporarily store data. And while some RAM has a faster “speed” than other RAM, as a general rule, 2 Gigabytes of RAM is 2 Gigabytes of RAM on a server or across platforms. You either have access to it or you don’t. And if you have access to it, the amount of it you are using can be precisely reported at any given time.
This makes RAM a great metric for judging server usage in a VPS environment. Either you have burned through your RAM or you haven’t.
Knowing what criteria to watch and the relative importance to give it is the first step to developing a successful server scaling plan.Photo by ShellyS