The second article in my multi-part series on MySQL Performance. Published by Liquid Web, Inc on the Liquid Web Knowledge Base. This article discusses the use cases for both MyISAM and InnoDB, a widely contentous topic to be sure. Both MySQL engines have their niche and in their niche they perform very well. This article is a guide to understanding when, why and how to use MyISAM vs InnoDB.
The first in a multi-part series on MySQL Optimization written for Liquid Web, Inc. This one covers the basics of identifying bottlenecks using mysqladmin and mysql to view the MySQL process list. If you’ve been interested in optimizing your database setup, this is just the start of a longer series where I cover several topics all related to MySQL Optimization.
HIPAA is serious business. Nobody wants their private medical information to fall into the hands of strangers. If you work with servers in the medical field, having a good understanding of the HIPAA and HITECH laws are a must. Check out this piece that Liquid Web asked me to write regarding this very topic.
If you want to get the most out of your server, one of the best tactics is to use modern browser cache controlling. The fewer elements a user has to download repeated can take considerably strain off of the server. Check out this piece I did for the folks at Liquid Web that can help you configure this technique on your own.
Part two of my full original article on handling disk quotas on various server types. Quotas are a critical component of shared webhosting and understanding how to utilize them is paramount to anyone administrating web servers.
Article Name: How to Use Disk Quotas in Dedicated Linux Servers for cPanel Servers
Publisher: Liquid Web Knowledge Base
Author: Jason M Potter – The cPanel Guy
One major gripe I have with WordPress is the default wp-cron.php implementation. If you are familiar with how WordPress uses wp-cron.php by default, you may want to skip ahead to the next section of this article.
What is wp-cron.php & How does it work?
The file wp-cron.php is the portion of WordPress that handles scheduled events within a WordPress site. Anything that has to do with scheduling posts or publications and really anything date/time oriented is governed by the wp-cron.php file.
In order for wp-cron.php to work properly, it needs to be executed frequently, but no more than once per minute. However, the default behavior does not require you to set up a real system level cron job on your server. Instead, it uses a piggyback method on every incoming request. When a request comes into the site, WordPress will generate an additional request from itself to the wp-cron.php file over HTTP(S). That sounds pretty innocuous, right?
Why is the default wp-cron.php behavior a nightmare?
The default method works perfectly fine on a small site with very few visitors per hour. However, when implemented on a medium or larger site or even a site that is being scanned by bots (which is very common these days), this means you get twice fold whatever traffic you are currently handling. It becomes a rudimentary DDoS attack against yourself. This is because the cron is being executed multiple times a minute using an HTTP request. The HTTP request generates additional overhead by having to generate, negotiate and establish the connection over a network socket. It even impacts the effective capacity of your underlying web server. This solution does not fare well in most situations, and honestly, it should be removed as the default behavior due to its propensity to be abused or turned into an attack vector on a server just from regular traffic.
Check out the Full Article on Medium.
This piece is taken from a broader article I wrote discussing quota usage and some of the unsung dangers that can occur when disk space runs low. The original covers both Linux Plesk and cPanel servers, those particular parts of the original source will be published as their own articles. As always, you can find all my currently published articles with other parties on the External Publications page here on cpguy.com.
Why didn’t the HA-cPanel/KVM kick-in when Apache was down for 20 minutes?
Apache operates on the service level of the HA-cPanel/KVM infrastructure. Service levels issues are not monitored. This is because they are contained within the virtual machine running on within the virtualization layer. Quite simply, the underlaying parent servers have no idea what is running on the guest VM they are protecting. Consider the following simplified chart of a typical HA-cPanel/KVM setup:
As we can see the LAMP Stack where Apache resided is further up past the Fail-safe level. There guest server runs in its own virtual environment. It’s not even aware that it is a guest in the environment and behaves like a standard Virtual Machine.
The HA-cPanel/KVM hardware layer protection is constantly at work. Each parent is perpetually talking to each other over a dedicated cross-over cable using a heartbeat daemon. The moment the PRIMARY server fails to identify itself to the SECONDARY server, the SECONDARY server springs to life, promoting itself to PRIMARY and spinning up the virtualization platform to launch the guest-vm.
Fail-over is not completely seamless in this configuration. The guest-vm must be booted up on the new PRIMARY parent. However, due to the constant synchronization of data using DRDB there should be minimal lost data.
Why not monitor the service level?
That’s a tricky questions. Fail-over in this system is designed to protect against imminent hardware failure and not a system built to maintain service uptime. Service level issues are generally resolved without needing to reboot a server. Since fail-over is effectively an abrupt power off of the guest-vm, it’s not a clean shutdown and there is always a minimal risk of some data loss or corruption.
There are better suited configuration for handling service level downtime. A highly trafficked site can take advantage of Load Balancing techniques to ensure responsive and stable uptime of their Apache LAMP stack. HA-cPanel/KVM can also work as a single node in an LB setup offering both the service level stability of a Load Balancer as well as the hardware level protection of HA-cPanel/KVM. You can have the best of both worlds.
If you are looking for a reliable system that protects against hardware level damage, give the folks at Liquid Web a few moments of your time to consider a solution like this for your valued data. I promise they won’t bit and the support is truly heroic.
I wrote this piece on Cloud Hosting technologies and how they can be leveraged by some example business model concepts. Cloud Hosting solutions are the norm in the hosting field and will continue to be the unseen future.
My very first published article and it’s a good one. An outline of what makes up a typical LAMP stack and how knowing each layer applies to site owners and developers. Understanding the LAMP stack is critical for optimization. We all want our sites to perform there very best, but there is no one-size-fits-all solution when it comes down to server performance. A basic understanding of these software layers allows you to properly configure each directive to best perform for your unique site, user base, traffic and hardware configuration.