There are more uses to these proprietary server analytics than simply ensuring that you’re receiving all of your critical system resources. Let’s take a moment to look at some of the most common ones.
1. Checking your site performance
The stated purpose of the Site Performance Guarantee resource graphs is to show that you are receiving your promised resources. If you see your site performance degrading, it’s very simple to check your resource graphs and make sure you are receiving 100% of your critical server resources.
Resource degradation, though, is so unlikely that not only could we not find an example of it to show you, we could not find an accurate way of artificially producing the problem for illustrative purposes.
The important point to remember when checking for hardware degradation is to make sure you look at the “Allocated” number in individual resource graphs. If that number falls below your guarantee for even five minutes, you qualify for a refund of that entire month of service. The important point to note here is that for each of our guaranteed resources — CPU, RAM, disk space and IOPS — if your site slows down and you do not know why, you can check these resources at any time to confirm that it is not a problem with the hardware. If it is — you get that month of hosting absolutely free. If you want the fine print, you can read our entire SLA here.
2. Monitor your total server uptime
With ServInt’s SolidFire SSD VPS, full server downtime is very unlikely in all but the most dire circumstances. Still, let’s look at what a full server outage would look like in your resource graphs. We simulated an outage on August 25th by rebooting a test server. Notice that the lines on the graph simply disappear. If you see this, click into a specific resource graph (such as CPU): You can see in this graph that not only has the resource utilization gone to zero, but the allocated amounts have as well. This indicates that the server itself was offline.
In the extremely unlikely event that you are temporarily unable to access the Portal, please know that these graphing tools will continue to collect data. This will be valuable after the incident should you decide to seek a refund for downtime.
3. Monitoring resource usage.
Confirming that your server hardware is running at 100% efficiency and your server is up are both important, but frankly, we don’t expect many customers to find evidence of resource degradation or downtime.
What is far more common is for customers who are experiencing site slowness to log into their resource graphs and find that their server is online and they are receiving all of their promised resources, but that they are using all the resources in one or more categories. Let’s look at some examples of this. These examples show customers who are maxing out IOPS, CPU and RAM respectively. Simply put, if you are using all of the resources your server has been allocated and you then wish to use more, your site will slow down. The question of how to fix this is one of time or money: should you optimize your code or purchase more server resources. Sometimes customers only have spikes in their resources. These spikes may have been anticipated or may be a surprise. The questions to consider in this scenario are: Did you have enough computing power in reserve to handle this extra traffic, and was the traffic spike preventable or simply a result of increased visits to your site?
Finally, there is a special circumstance when monitoring RAM usage on your ServInt SolidFire SSD VPS. There are two separate RAM metrics that add up to Total RAM: Active and Cache RAM. Active RAM is just what you would expect — this is the RAM the processes on your server are actively using.
Cache RAM is an optimization wherein unused RAM is temporarily used to store (or cache) data that has been recently accessed on the server. When that RAM is needed for Active RAM, the cache is simply dumped (or a portion is dumped) to free up the RAM. Some servers have a large cache because of many active users. In this case, the Active and Cache RAM total nearly all of the allocated RAM. But other servers do not require a large cache or the cache has been recently dumped due to the need for more active RAM. If your active RAM usage increases to near the limits of your allocated RAM, you will have little-to-no space left for Cache RAM. Depending on your configuration and requirements, this could signal a need to optimize your code or upgrade your hardware.
4. Planning for future optimizations or upgrades
One of the best ways to use your ServInt SolidFire SSD VPS resource graphs is to plan for future growth of your sites. Monitoring resource usage over time and deciding on predetermined limits past which you will upgrade can save you the headache of running out of resources in the first place.
Study your resource graphs. Determine how much of your system resources you’re using on a regular basis and how much you need to hold in reserve for growth or spikes in traffic. This will help you know when it is time to scale before you run out of resources. With ServInt’s SolidFire SSD VPS, knowing when to upgrade your resources has never been simpler.
Editor’s note: A reader made the following comment on yesterday’s blog post about our SolidFire Site Performance Guarantee and resource graphs: “I am curious to know what’s proprietary about these graphs given that so many open source tools exist (Munin, MRTG, Nagios etc.) that show similar stats.” We’ve asked one of the chief architects of ServInt’s resource graphing tools, Giles Fox, to weigh in.
From an engineering perspective, there’s nothing in particular that makes our graphs proprietary. For the most part, all of that same information can be polled by any user of the system, except — potentially — some of our IOPS data. Also, extrapolating the CPU data using open source tools involves a lot of complicated calculations. Still, if one wished, one could use Munin, MRTG or any of a number of other open source solutions to build their own graphs. Read more
You’ve heard us talk a lot about what makes ServInt’s SolidFire VPS and dedicated hosting platform the most significant evolution of Cloud hosting technology in many years — the elimination of noisy neighbors, the transition to an all SSD cloud storage solution, and most recently, the implementation of a hosting-industry first: a Site Performance Guarantee that promises your site will never slow down because of a drop in available RAM, CPU, disk or read write operations per second (IOPS).
What is behind this guarantee — and the verification and proof that you’re receiving the performance you’ve been promised — is the proprietary analytics tool that we’ve introduced to support our Site Performance Guarantee.
If you’re a SolidFire customer, these resource graphs are available in your ServInt portal. They give you total transparency into all your critical server resources, showing not just how much CPU, RAM, disk, IOPS, and network resources you’re using, but also tracking how much you’re guaranteed and currently allotted.
Never before has a virtual server been so transparent.
So, just what do these graphs include? Read more
If you’re a ServInt SolidFire customer, your site will never slow down because of your server. Ever.
Did you know that? Have we done a good job explaining that to you? I wonder sometimes.
In past blog posts, we’ve examined IOPS, resource contention, disaster recovery, and lots of other very good reasons why you should choose our SolidFire-powered VPS and dedicated servers. But when you boil it all down, the main reason is this:
If you’re a ServInt SolidFire customer, your site will never slow down because of your server.
That’s revolutionary — and it’s a genuine first for the business-focused hosting industry. No other hosting company can make this promise.
Now, as of today, we’re backing our promise up with a revolutionary new guarantee — ServInt’s SolidFire Site Performance Guarantee — that says this: if your site slows down because your server doesn’t deliver 100% of the CPU, RAM, disk and IOPS you were promised, for more than five minutes… you get your entire month of hosting absolutely free.
How will you know whether you’re getting all the server resources you deserve? By using our new, completely transparent system resource graphs — another ServInt exclusive. From this day forward, if you’re a SolidFire customer, we’re not just going to tell you exactly how much RAM, CPU, disk and IOPS you’ll get with each hosting package. We’re going to put tools into your hands to keep us honest — tools that will give you real, verifiable proof that your server is delivering what you paid for — and we’re going to back it all up with the most radical system resource guarantee in the hosting industry.
Here’s the punchline: ninety-nine-point-whatever percent server “uptime” guarantees are a thing of the past. As of today, ServInt is guaranteeing server performance — i.e., guaranteeing that your site is not only up and online, but also that your site or app performance is never compromised by any server resource shortcoming. Ever. We’ll prove it to you.
Editor’s Note: As third-party software, ServInt does not support Nginx beyond installation. Also, to follow these instructions, users must have a working knowledge of the command line. Click here if you would like more information about logging into your server on the command line.
Nginx offers an alternative to the Apache web server popular with some server admins. Advanced users may choose to run Nginx instead of Apache, as it is believed to offer possible performance benefits in certain configurations. Read on if you are interested in installing Nginx on a server running cPanel. Read more
There’s an interesting parallel between the way people buy web hosting and the way they buy sports cars. Frequently, the sports car purchaser who doesn’t actually compete in races will buy their vehicle based on theoretical maximum performance capability, examining numbers like top speed, maximum horsepower and so forth to see how fast their dream car might theoretically go.
Of course, people who actually race for a living understand a critically important maxim: top speeds don’t win races, high average speeds do. That means it’s just as important to be able to speed around accidents and slow traffic as it is to power down the straightaways as fast as possible.
It’s the same with hosting. The size of a CPU, the amount of RAM, the network uplink speed — these are all important metrics, but everybody’s working with similar engines these days. You can get your specs and never see reliable performance at other host because your server still can’t swerve around the accidents and slower traffic without getting bogged down. Why? Because of something called IOPS. Read more
“This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).”
This vulnerability impacts openssl versions 1.0.1 and 1.0.2-beta. ServInt customers may have this vulnerability if they are running CentOS 6. CentOS 4 and 5 do not have versions impacted by the Heartbleed vulnerability. Read more
My son is five years old and a digital native. For the last year or so he’s been saying that he wants to develop video games when he grows up. I’ve acknowledged his desire, telling him that he can develop video games, but that he’d need to learn how to write code and work hard. When he recently brought up his plan again I finally said, “Okay, lets do it.”
We sat down and talked about what he wanted his game to do. His first idea was a Minecraft type game with dinosaurs, I told him that was a good end goal, but that we needed to start smaller, something simple. I asked him what he wanted the goal of his game to be about, he said slaying a dragon. Then I asked him how he wanted the game to start, and he chose waking up in a cave. We then began designing our text-based adventure.
I used this opportunity to teach him the echo command. Echo is the simplest of commands, returning whatever string of text or variables is typed into the command. It’s also a great command to use to learn your first script. Read more
Editor’s note: this tutorial assumes you are familiar with working on the command line on your server via SSH. If you’re not, you might want to check out this article first to get your feet wet.
In previous Tech Bench posts, we discussed how to install vanilla Minecraft and how to install Bukkit Minecraft, but how can you look at your beautiful server maps and buildings and show them off to your friends? Minecraft Overviewer is one solution.
As I’ve mentioned before, Minecraft is memory intensive. Minecraft Overviewer is also memory intensive. I would recommend at least a Signature VPS for hosting a Minecraft server, but an Ultimate would be better.
Here is how to install Minecraft Overviewer on a cPanel VPS. Read more
1. A VPS user believes that the PHP mail function is not working or that there is something wrong with the mail sending script (Contact Us form, registration form, or an order form which sends an email).
2. A user is having trouble sending email to other email accounts that are hosted on the same server.
In both cases, the client’s site is usually hosted on the server while email is hosted elsewhere. The site is also usually using third party nameservers (e.g. nameservers at a third-party domain registrar). The server is trying to send email locally instead of remotely where it actually exists (Google Apps, GoDaddy mail, Office365 etc).
If you think your PHP mail function is not working because you are having trouble sending email to an account on your server, you should check your DNS configuration:
- Run a DNS report of the domain on a site such as intoDNS.
- Use the output to determine if the domain is using third-party nameservers.
Third-party nameservers are nameservers whose IPs do not resolve to your server’s IP addresses. Running a DNS report will help you determine if this is the case. If it is, you likely set up an A record to have the site resolve to your server while keeping the mail exchange (MX) records set to resolve to another server.
- Move the domain for the off-server email address from /etc/localdomains to /etc/remotedomains. On cPanel servers, this can be done in WHM:
- Navigate to DNS Functions >> Edit DNS Zone, choose the domain in question and scroll to the bottom and switch to ‘Remote Mail Exchanger’. This change in WHM updates the above two files. (In certain instances even though a domain may be in /etc/remotedomains, it may still be in /etc/localdomains as well. Check to see if it is properly removed if you decide to add the file manually.)
- If you are using your own private nameservers for the domain in question, this is all that needs to be done to resolve the issue. If you are NOT using your own private nameservers, proceed to step 2.
- Delete the DNS zone file from the server because it is using third party nameservers and is not needed on the server. This local zone file is actually what is directing the server to send email locally instead of looking for it off your server. The zone file can be deleted from the following location: DNS Functions >> Delete a DNS Zone
Please note that this DNS zone file can be generated again if you ever decide to move away from third party nameservers and start using your own (e.g. ns1.yourdomain.com and ns2.yourdomain.com).
That’s it, you should now be able to send email at your domains that are hosted with third parties.