Over the last few months our upstream providers have been rolling out a new shared platform onto CPanel servers to take them to the next level. These upgrades are meant to accommodate where the internet and websites are going, rather than where it has been. To do that, we have gone back to basics to rethink everything from the ground up. We will be introducing these changes in a new round of blog posts starting with the new Apache 2.4 upgrades which have been rolled out already.
Apache 2.4 – A big step forward.
While other web servers such as NGINX have captured social media’s attention, Apache still powers most of the internet as the rock solid platform we have depended on for almost 20 years. The Apache platform continues to modernize itself without sacrificing what makes it into the platform that has built so much of the internet. You can see clear examples of this in each system’s design as NGINX drops support for .htaccess configuration while Apache builds in architecture changes to support MPM event taking on NGINX where it gets most of its performance.
Usability is key.
As we looked at each piece of the shared webhosting platform, our focus was performance, compatibility, and usability in equal measure. If the system was slower for compatibility, we needed to do better. If the system performs extremely well, but it requires a support ticket to change website rewrite, we need to do better. If the performance wasn’t showing in benchmarks, we definitely needed to do better.
We started with static file performance, MPM event, and Apache 2.4.
Much like NGINX’s event based architecture, Apache’s MPM event takes a few more steps in that direction than other MPMs recycling more threads in different ways including secure threads for TLS/HTTPS connections improving https performance. This reduces overhead as more sites can securely use the same threads ensuring requests meet the hardware faster than before. If a visitor requests resources from website1.com and another user requests different resources from website3.com, there is no pause or startup/shutdown as the server handles each seamlessly. This massively increases the maximum number of requests the server can handle while reducing the amount of time it takes to handle each of the requests. Win/Win.
In addition to improvements introduced by MPM event, we have also optimized every aspect of the system including mod_expires/mod_headers intelligent caching, mod_deflate optimized compression, and a lot more. These changes optimize caching for CDN/proxy, mobile usage such as iOS/Android, and a lot more without interfering with website settings. These transparently instruct CDNs such as Cloudflare, mobile devices, and even browsers to:
- Keep certain items locally cached instead of constantly rechecking/downloading,
- Accept compressed content such as CSS, javascript, HTML coding, and more for faster loading on mobile. The slower connections on many mobile devices make this a key performance improvement.Deny access to restricted resources to reduce robot intrusions reducing resource usage. With more of your resources available for visitors, more of your traffic is legitimate instead of just more robots lining up to attack. This is in addition to other measures such as mod_security and denies access to files such as .sql which are usually database backups left in place by mistake.
- Optimizes TLS/HTTPS connections introducing Forward Perfect Secrecy, HSTS, SNI, faster TLS KeepAlive responses, and a lot more. With Google’s recent changes to search engine rankings making HTTPS sites list higher, these changes will be key going forward.
* mod_fcgid FastCGI – The replacement for suPHP. Good riddens.
When suPHP was first introduced years ago, it was a significant improvement over the older phpsuexec patch set for Apache that had been in use. It supported user level php.ini, significantly improved security, and a full CGI implementation with several “fixes” to ensure compatibility among many other things. With mod_fastcgi (not mod_fcgid which would be introduced much later) a buggy mess, it was a stable, production, and fast option.
Fast? Yes, suPHP was fast during a time when a single page request was a single PHP request.
With AJAX/Web 2.0, automatically refreshing WordPress themes, and a lot more, one PHP request per page request became 15 – 20 PHP requests per page request increasing the stress put onto the system by suPHP. As the system starts an interpreter process, runs the code provided by Apache, flushes the result back to Apache, and shuts down for each request, the overhead became significant. There was also no way to introduce opcode caches to cache compiled PHP code as suPHP shuts down the interpreter after each request closing the cache along with it. To resolve this, we started to upgrade to mod_fcgid.
What is the difference?
The most important aspect of the difference is how much they are the same. suPHP and mod_fcgid are both CGI based which improves compatibility between the two allowing us to make only minor alterations to the variable environment as it changes. The result has been tens of thousands of websites upgraded with less than one support ticket per server upgraded.
To improve on the performance of suPHP, mod_fcgid avoids the startup/shutdown overhead by keeping the workers resident in memory for a short time after the request has been completed. If a website loads the index.php, it is very reasonable to assume the visitor or search engine robot will also request more resources in the next few seconds/minutes. If no requests have been received during that time, the worker unloads itself to reduce resource usage until more requests are received. This intelligent worker management combined with opcode caching has resulted in less server instability/crashing as well as improved speeds as websites load in a fraction of the previous time thanks to opcode caching and the reduced overhead.
In the next post, we will cover more ways the Apache 2.4 architecture is being used to improve performance and security.