On 03/24, we performed an upgrade on our security for DFW01 and apparent complications arose. We have experienced a few minutes of downtime on DFW01 every day since 03/24. The downtime usually lasted only about 5 minutes. We worked closely with our security vendor for the past several days in trying to get a resolution and we believe we have isolated the problem. When new updates and rules were released, Apache needs to be restarted. The default method for the restart was a graceful restart, which means that it waits for all connections to close, prevents new connections from spawning, and then restarts Apache once it reaches zero connections. We have modified this behavior and will no longer perform a graceful restart of Apache. We will continue to monitor the situation closely and we apologize for any disruption of service this has caused.
If you are like millions of other website owners, you probably started out on shared hosting. You’ve been through the ups and the downs that are associated with small budget hosting. Your website was thrown onto a server with a thousand other websites, all doing different things. Websites may be hacked and infected, they may have adult content, they could be spammers, they could be designed to infect visitors with malware, or it could just be an honest person trying to make a living… the truth is, no one ever knows who their neighbor is, not even the hosting companies. All it takes is one bad apple to spoil the bunch, or in this case, one bad website to take down an entire server. Enter CloudLinux!
One of the biggest benefits of CloudLinux is that it takes your website and puts it in its own container via a component called CageFS. In short, this means that the security of a site on the same server cannot affect the security of another, nor can it affect the server as a whole. Let’s think of the apples again except this time, each apple is inside of a sealed container. If one apple goes bad, it no longer affects all the other apples. The same is true with sites on CloudLinux. If a site is hacked or infected, it no longer has the potential to impact it’s neighboring sites. This results in a much happier environment for our sites. The Operating System kernel has been hardened and security patches are released a lot more often. Combined with KernelCare, security patches are applied instantly without having to wait for reboots.
The CloudLinux operating system enables the ability to set limits based upon the package that the site is on. The limits include CPU, memory, disk performance, and running processes. These limits are not put in place to punish a website owner for having a busy site, they are there to make sure every site is using the resources their package was designed for and to protect the servers from being overloaded. These limits also help us to identify issues with sites very quickly because we monitor and get alerts any time a site hits their resource limits. Maybe the site is missing a cache plugin, has uncompressed images, has 500+ request per page load, or maybe it has a bad script that’s running for 20 seconds, or is stuck in an infinite loop. Once these issues are fixed, the site loads faster and the owner is a much happier customer. Because these limits are set per website, and the site is in its own container, a website maxing out its resources cannot affect another website, nor can it affect the performance of the server. Let’s look at a typical scenario: Site X uses up all available resources on a shared hosting server. Either the server crashes or all sites are running slow or are inaccessible. On one of our servers, Site X is using up all available resources for their account. The website is running slow but all other websites are moving at normal speed and the server is running fine. On the shared hosting server, the site is quickly turned off or terminated for abuse without warning. On our server, it just means the site can continue moving at a slower speed, or upgrade to a higher package since it needs more resources than what the package is designed for. The server keeps 30 days’ worth of logs and inside of each cPanel, the resources usage and limits are shown and can be used to gauge how a site is running under its current package.
There are many more benefits of CloudLinux and you can read about them here.
Does website speed really matter? According to some giant companies, it can significantly impact your bottom line. Giants like Amazon, Walmart, Google, eBay, Yahoo, AOL, Shopzilla, and Mozilla decided to overhaul their websites to decrease their page load times to find out just how much it impacted their sales, page views, downloads, etc.
- Walmart noted that for every 1 second of improvement, they experienced 2% increase in conversions. For every 100ms of improvement, they grew incremental revenue by 1%.
- Amazon also experienced the same 1% in increased revenue for every 100ms of improvement. On the flip side, a 1 second loss for Amazon is about $1.6 billion in sales a year.
- Shopzilla sped up their average page load time from 6 seconds to 1.2 seconds and increased revenue by 12% and page views by 25%.
- Firefox reduced their average load time by 2.2 seconds and increased downloads by 15.4% or 60 million more downloads a year.
- Google showed that slowing their search results by 400 milliseconds reduced the number of searches by 8,000,000 per day.
- Yahoo! increased traffic by 9% for every 400 milliseconds of improvement.
So how did they increase their page performance? I wish I could tell you that they just clicked a few boxes and their site magically improved. The truth is, it’s a very complex process to tune a website to get the best performance gains and something you should leave up to a professional. Many professionals will charge you a one time fee for optimization or through a monthly maintenance agreement, which is what we recommend. Things are always changing and it’s easy to get behind the curve if you’re trying to do everything yourself. If you’re interested in a maintenance agreement for WordPress, one of our resellers, SMD, does an excellent job at keeping WordPress sites running efficiently.
We decided to put a few simple optimization changes to the test to see how much each one improved the site’s performance. Two of the most beneficial changes that can be done to a WordPress site is to add a cache plugin and use CloudFlare Pro, a content delivery network (CDN). Here are the results:
WordPress without WP Super Cache or CloudFlare Pro – Baseline
WordPress with WP Super Cache’s recommended settings – 1.01s Improvement
WordPress with WP Super Cache’s recommended settings and CloudFlare Pro – 1.476s Improvement
What the test doesn’t show, is on the back end, server resources were drastically reduced at each stage of optimization. On average, these two improvements can reduce a site’s resource usage by up to 90%! The less resources a website uses per visitor, the more visitors a site can handle. You might be wondering, could I add CloudFlare and reduce my package? Typically, our answer here is no. CloudFlare can’t replace an existing package, only enhance it. There are many factors that go into the need for a certain package and the higher the package, the more resources available. You could actually slow down your site by adding CloudFlare and reducing the package your site is on.
Here’s an example of a website before and after CloudFlare Pro. We switched her over on the 29th of the month and as you can see, her bandwidth usage stayed lower through the next month. This is a significant savings of about 88% and if we were to calculate overages before switching her to CloudFlare Pro, it could have resulted in hundreds of dollars.
Day 29 CF Pro Switch First Month on CF Pro
- Remove the default admin account – Hackers need two pieces of information to get into a website. The default admin account already gives them the username, now all they have to do is brute force attack to get the password. Although brute force attacks will automatically be blocked by our firewall, hackers often use many IP addresses to carry out attacks.
- Use secure passwords – Using passwords with at least 10 characters with upper and lower case, numbers, and special characters will ensure that your account is secure.
- Use published and verified content – We have seen some sites that offer pirated themes and plugins that are infected. Once they get a hold of your site, they modify the database. Since all of the changes can’t be verified, best practice states that the website must be restored from a backup or completely rebuilt from the ground up. This is a very serious problem and could result in hundreds or thousands of dollars for a web designer to redo your website.
- Keep WordPress up-to-date – As with any software, WordPress, themes, and plugins will always have vulnerabilities. Every new release usually contains several fixes to patch these, as well as performance improvements.
We’ll admit, cPanel’s webmail interface lacks a lot of features and the user interface is very basic. Because of these and other reasons, users like to forward their mail to Gmail, AOL, Yahoo, or other email providers. There are a few things you should know before you forward your email.
- All emails, including spam, get forwarded to the account. Spam filtration does not get applied to messages that are forwarded. Because of this, the receiving email server will view our server as sending spam. This can cause an interruption to your mail flow if the server gets blacklisted.
- Marking Spam on a forwarded message does not mark the original sender as spam. Most email servers do not see the original recipient, they only sees the last email server the message came from. For those that do, they associate the IP address of our server to that recipient, meaning, our IP can get a bad reputation, even though our server wasn’t the originating server.
- Because of the previous points, you can no longer filter out spam messages efficiently without filtering out the good emails. Good spam filters will look at both the sender and the IP address of the mail server to determine if a message is spam or not.
You may ask then, is there a better way to get my email? Of course! One way is to use Microsoft Outlook. Most email services will allow for POP or IMAP so that you can have all of your emails in Outlook. This will consolidate all of your different emails into one program so you can easily see your business emails and your personal emails. I encourage anyone that is using their email for business to strongly consider switching their email to Microsoft Exchange Online or Office 365. For as little as $4 / month, you can have the same enterprise email service that all of the large companies do. The good news is, it’s a lot simpler to sign up for and use than you might think. If you are interested and need help, don’t hesitate to call and we’ll be happy to assist.
Thanks to everyone for your patience! Due to some large accounts, the transfer took longer than expected because the data had to be verified to make sure it all copied over and nothing was corrupted. After everything was transferred, we had to swap the IP addresses so customers did not have to change anything on their end. This also took extra time and the DNS cluster was out of sync and we had to rebuild the DNS cluster. It took time for this to all sync back up. Nginx also had to be repaired as it was bound to the original IP address and did not dynamically update. After the change, the license did not update automatically either, so it had to be reissued and then all services were restarted. After this was completed, websites came back up. We will continue to monitor performance and make any optimization tweaks.
We will be upgrading the DFW server on Thursday 12/04 starting at 9PM CST and hope to have this completed by 5AM CST. We expect very little downtime, but there’s a chance once the transfer is complete and we move over the DNS and the IP address, there might be a small window when sites are not accessible. Any new post or e-commerce transactions between the start time and the finish time may not show up on the new server, so please plan accordingly.
DFW is our oldest server and while the sustained traffic is below its limits, the traffic spikes can push it over the edge. While we optimize to get the most out of the hardware, there comes a time when every server must be upgraded. The new server will have at least twice the processing power and five times the hard drive performance. Since the majority of our customers are on WordPress, these two improvements will drastically reduce load times.
We thank you for your patience in this matter and apologize for any inconvenience this may cause. Happy Holidays!
WordPress 4.0 named “Benny” has been released. Visit this link to find out about the new features and updates. It’s always good practice to make sure your plugins have been updated to work with the latest version before installing a major release.
We discovered a bug in Nginx that causes the Nginx service to crash whenever a subdomain is created improperly. In all of the cases where Nginx crashed and failed to restart, we were able to view the logs and identify the account that caused the crash. Upon inspection of the account, we see that there is a subdomain folder, however, there is no subdomain or addon domain inside of cPanel. Nginx sees this folder as a subdomain and creates a virtual host but crashes since there is no identifier inside of cPanel. We have contacted Nginx and they have released a new version that addresses this bug. We will be applying this update shortly to all servers.
To avoid issues in the future, it’s important to always follow the cPanel wizards whenever creating or modifying accounts. In this case, the proper way to create a subdomain or addon domain is by logging into cPanel and following the wizard in either Subdomain or Addon Domains under the Domains section. This will properly create the folder structures and permissions.