PES News Archives | Page 2 of 8 | Pure Energy Systems
15 Oct 2019
04 Oct 2019

Upcoming Maintenance Windows

We’ve recently been notified by one of our data center providers that they need to schedule some emergency maintenance windows in order to apply some critical updates to the underlying physical hardware, and that these updates will require taking some of our servers offline while they perform the work.

While we know that these scheduled events are never ideal, we have <knock on wood> been very lucky in terms of infrastructure outages since moving from our own managed hardware into provider-managed cloud servers.

We’ve been collating the scheduled windows and are currently:

  • notifying all impacted clients via email of their scheduled outage window.
  • adding the impacting events into the Network Status / Scheduled Events section of our client portal.
    • This is particularly cool to us, as it allows us to input all future scheduled events, and clients will only see/be bothered by the events that actually impact them personally.  Yes, we’ve had the ability to do the same via email for some time, but this is just another cool feature of the ‘new’ client portal that we’re really getting to utilize for the first time.

We will continue to monitor the situation and should any further windows be scheduled by the provider, we will of course notify additional impacted users and add those events to the client portal as well.



12 Sep 2019

Node.js support is now live!

man holding a small sign that reads 'node js'This evening we’re taking the covers off our latest feature addition to our Shared Linux Web Hosting plans, everyone please welcome Node.js to our feature list!

The Node.js setups is very similar to the Python support we unveiled earlier his year, in that you can deploy a new Node application into your account by looking for the “Setup Node.js App” icon under the “Software” section in cPanel. You’ll be prompted to select the Node version you wish to use, where the application should live folder wise, and the URL you want to associate with the application, cpanel takes care of all the rest.

At this time the Node.js selector will default to v10, but you can also choose to run your applications under v12 if so desired.

17 Aug 2019

More details on the cPanel price increase

So, the great cPanel Price Increase of 2019people counting coins on a table is scheduled to go into effect in just over two weeks, and, not so shockingly, details are still a bit slow in coming.  Officially the word we’ve seen from our license distributor is “The pricing you saw previously is valid, that’s what we’ll be charging as of September 1.  As for any sort of volume discount or any details beyond what was in the original announcement, we’re still waiting for that information ourselves.

Short version for us is, that as of right now, cPanel licensing goes from approximately 6% of our cost per server, to about 18% of each server.   This does not include CloudLinux, Fantastico, or any other software we license for our server fleet, just cPanel itself.   cPanel by itself will, after September 1, cost us more per server each month by itself than what we pay for all the software we license for a given server today.

The good news for our clients is, we’ll be absorbing that cost directly.  We have no web hosting plan pricing changes scheduled or planned as a result of the cPanel cost increase.

Long term, we’re honestly still a bit worried about what this pricing model change is going to mean for cPanel in relation to the industry as a whole.  cPanel has long maintained a market dominate position simply by virtue of being the “best of the cost effective control panels”…  Starting September 1, they’re kind of moving themselves out of the “cost effective” category for a number of business models, and based on the rumblings we’re hearing inside the industry, we suspect you may see a spike in popularity and/or new Control Panel options entering the market.

For our part, we’re going to keep an eye on the situation as it evolves and see how it all shakes out.  But in the meantime we’re maintaining course for our clients.

18 Jul 2019

PHP 7.3 now available

Screenshot of PHP code in a text editor

PHP 7.3 has been rolled out across all of our Linux servers, and now available for general use.

To select PHP 7.3, you will need to change your selection using the “MultiPHP Manager” which can be found inside your cPanel interface under the “Software” section.

The PHP 7.3 Migration Guide may prove useful and provide a quick reference of what has changed within the language.

29 Jun 2019

cPanel Increases Pricing, Potential Chaos Ensues

Yesterday the folks @ cPanel lobbed something of a grenade into the middle of the web hosting industry with a blog post entitled Announcing Account Based Pricing.

Long story short, they are increasing the cost of cPanel for pretty much every situation under the sun effective September 1st. The old pricing model was a flat monthly fee per licensed hosting server, while the new pricing is directly tied to the number of web hosting accounts on the server.

Now, this announcement has sparked a number of reactions, including anger, confusion, and fear from around our industry. We’ve seen reports of providers who believe they will see massive increases in their cPanel costs going forward, with some expressing concern of just how they are going to make the numbers work. These conversations have lead to discussions of providers moving to other platforms, cutting ancillary features out of their offerings to lower costs, or simply closing up shop as they will no longer be able to financially stay above water given the new pricing model.

Some of those reactions and discussions have filtered out from the industry watering holes and into the webmaster forums and chat rooms, to the point we have had more than a couple clients reach out in the last 24 hours asking for information on the topic from our perspective.

With that in mind, even though we don’t yet have 100% of the picture (the pricing being bandied around so far is ‘retail’, we’re not yet sure exactly where our final pricing will land), I wanted to take a moment to discuss both the big picture, as well as what it means for us here at Pure Energy.

In the big picture, things could get dicey for some of the lower cost hosting providers over the next couple months. The lower end market is run on razor thin margins, and, well, I’ll be blunt, it’s hard to stay afloat selling $5/year hosting if your control panel alone is costing you $4/year per account.

For our own environment and business model, we’ll see around a 3x increase in our monthly cPanel license costs, at the retail pricing we’ve seen so far. While not ideal for us, especially coming so closely on the heels of the cost increase we absorbed just a few months ago with the addition of CloudLinux to our servers, at this time I believe we can make the numbers work for our existing Shared Linux Web Hosting plans without a price increase, and without any other substantial changes to our service, plans, or features.

We won’t have 100% of the picture until we get firm pricing from our provider, but to be honest, the bigger concern for us is the uncertainty this injects into the idea of cPanel as a stable platform for our future:

  • Our biggest, as of yet unannounced, project for 2019 was a ‘scratch our own itch’ service that we were hoping to integrate into cPanel pretty tightly and offer to our users as a value added feature of hosting with us, as well as to market the service to other hosting providers as a way to scratch their itch as well. This is on hold (the integration, not the service!) while we see how the cPanel landscape shakes out.
  • A smaller project we had been looking at involved clients who find themselves needing much larger resource allocations than any of our current plans offer. The idea here was larger servers, larger plans, fewer clients per server. We have to re-run the numbers there to see if cPanel still makes sense once we have the finalized pricing.
  • cPanel’s immense popularity has long made it the de-facto ‘go to’ for any provider/service/platform that had a product of interest to the hosting industry. The fallout from this price increase, if it serves to fracture the landscape of providers, could very well jeopardize the dominance that cPanel currently enjoys in the market. If that happens, what happens to the 3rd party interest/support for cPanel?

Some of these are obviously questions that wont be answered for some time, for right now however, things, for us, are status quo. We’ll keep doing the best we can for our clients, keep our eyes on the industry landscape, and keep moving forward.

16 Jun 2019

The Evolution of PHP under Apache

Over the sixteen years we’ve been doing this web hosting thing, we’ve seen a multitude of changes to the way webservers run, and more notably, in how they run scripts under, for instance, languages such as PHP.


In the beginning: PHP as CGI

In the beginning running a PHP script was a fairly simple affair.  The Apache webserver of the day used a preforked child based process for handling requests, where the main web server had a pool of child processes, and as each web request came into the server, it would be allocated to a worker, the worker would process that one request, and if a PHP script was involved, a separate CGI process would be spawned out to run PHP and process the scripting part of the page.   There would be a whole slew of settings in your apache configuration that would boil down to “PHP files located in /home/bob/public_html/ get run under the ‘bob’ user account”.

This worked, but it was anything but fast.  As time went on and PHP became more popular, and the sites that it powered became more complex, performance became a big issue, in order to keep things efficient and cost effective, a better way had to be found.

Enter mod_php

Along came mod_php, which sort of up-ended the entire apple cart compared to how we all thought of PHP.   mod_php was an actual module that you linked into Apache itself.  Now your PHP scripts were basically interpreted by the webserver.  No longer did Apache have to ‘spawn out’ another process to render your PHP content.  This was fast.  Then OpCode caching became a thing, with add-ons such as the APC module, where now you could allocate some RAM to be used to persistently cache the PHP code (and possibly other data) in between requests.  Things got extremely fast, and there was much rejoicing on the parts of web hosts everywhere as CPU usage decreased on servers everywhere.

Downside, this meant all PHP scripts needed to run as the same user that Apache ran as.  This meant that everyone’s scripts ran as “nobody”, or possibly “apache”.  Having all the PHP scripts on a server that hosts multiple clients and websites all run under the same security user account was (although I don’t believe anyone initially saw it coming at the time) a huge problem.  The industry started to see a rise in the number of defaced and hijacked sites, and it quickly became evident that the “everything runs as nobody” was to blame.

Malicious actors quickly built PHP scripts that when run, would scour a server, for instance by looking for any *.php files in /home/*/public_html/ on the server, and every time it found a php file it could write to, it would then inject whatever malicious code it desired to spread.  Since all the php scripts on a server ran as the same user, that user account would, by default, need access to all the scripts on the server.   It only took finding one single exploitable script on a website in which they could launch their script to allow the malicious actor to infect (or delete) all the php scripts on the server.  This of course, was not a good solution, as now every script and client account on your server was only as secure as the most out of date, un-patched script on the server!  Something else would need to come along…

(Side Rant:  If, in 2019, you find a web host that is still suggesting that you chown your scripts to “nobody:nobody” or “apache:apache”, be very afraid.  The reasons for this fear should be evident from the last paragraph, but I feel the need to re-iterate the point, because doing so is, well, just a huge mistake security wise!)

SuPHP to the rescue

Then along came SuPHP, which combined most (but not all) of the performance benefits of mod_apache with the flexibility of scripts once again being able to run as individual user accounts.   It was something of a balanced trade off between “fast” and “secure”. 

Apache Gains Workers, But They’re Useless To Us

Along with other great advances to the Apache Web Server, eventually it gained the ability to have ‘Workers’ instead of just ‘Preforked Children Processes’.  While child processes worked fine for years, the overhead of ‘every connection has a dedicated child process that feeds it’ involves a fair amount of overhead.

So the Apache team implemented the ‘Worker’ MPM module.  The server still forks a group of child processes in advance, but each child process is capable of serving multiple http connections via Threads. 

This brought a sizeable boost in performance on hosting servers (notably a decrease in memory needed to service a given number of http connections), but it had one big drawback… it didn’t work with PHP, so it was no good to us for quite some time.

mod_lsapi:  The best of all worlds?

With the recent migration of our servers over to the CloudLinux platform, we’ve gained the ability to leverage the lsapi Apache/PHP interface to achieve a modern ‘best of all worlds’ approach:

  • Apache runs with the mpm_worker module, allowing one child process to handle multiple connections via threads.
  • lsapi interfaces those workers to php via php-fpm as needed when an php file needs to be processed.
  • php-fpm gives us flexibility, security, and performance all in one.

Wait, what’s PHP-FPM?

PHP-FPM is sort of a ‘php server’ if you will.  It is responsible for maintaining a pool of PHP processes that can be handled your PHP code to process.

The flexibility comes in that we can control the version of PHP on a per site level, which is how we can provide the ability for users to control which version of PHP their code runs against.

On the security front, each user has their own self contained php server process, providing a ‘pool’ of PHP processes at their disposal, each running as that user, so no worries about ‘nobody’ permissions or users being able to access each other scripts.

For performance, well, we ‘persist’ the pools per user for a set amount of ‘idle time’ after the last PHP script was processed.  This means that while on the first PHP request for a given client site, we need to (quickly) spin up a PHP process, that process will live-on after the request is finished (up to our idle timeout), if a second request comes in before that time-out ends, it is serviced by the same process, saving start up time, and more importantly, allowing us to once again benefit from the performance boost of PHP OpCode Caching.

The ability to use a PHP pool, when combined with the per-user resource scheduling available to us in CloudLinux, really opens things up possibility wise, allowing us to fairly distribute resources while maintaining performances across all users on a given server.

For instance, here’s the CPU and RAM utilization over a given day for a typical user on one of our shared linux webhosting servers:

cpu and memory graph showing normal traffic activity

Now, this users site got a pretty normal consistent level of traffic throughout the day, it of course had some spikes here and there, but overall, pretty even-keeled distribution of traffic.   You’ll note that the memory usage is pretty even throughout the day, even though CPU jumped a bit more here and there..  This is because even though the clients site may have needed more processing time, the standard PHP process pool for them was already running, and simply kept going handling the visitor load.

Now, lets see what happens when things get… busy.  This customer had a far more interesting day:

cpu and memoryg graph showing peaks caused by a slight DDoS attack

Now, this graph is a bit of an anomaly, not enough to cause a panic, but, well, they were dealing with a slight DDoS attack, in for the form of someone attempting to brute force user logins to their forum.   The traffic was pretty steady throughout the day, but with large spikes in traffic at random times along the way. 

While CPU utilization got pretty intense at times, RAM utilization stayed pretty consistent (most of the time)..   there were a couple times throughout the day when the system determined it was unable to provide all the cpu resources demanded by the attacker, so things did get throttled a bit here and there with the ebb and flow of traffic coming in from the attacker, but the ability for the server to maintain a single, persistent pool of PHP processes to handle the requests, complete with OpCode caching and all the other benefits of reusing the same process for multiple requests, allowed the overall impact to memory to stay pretty consistent throughout the day.

The important thing in this scenario is, that with the persistent php process and OpCode caching being available between requests, the overall load on the server generated by this attack was minimized.  The system did it’s best to maintain service to the client’s website throughout the ‘bursty’ attack periods, and no other client sites hosted on the same server saw any impact at all.

This is a huge change from the days of ‘PHP as CGI’, and we’re confident that Apache Workers + mod_lsapi + php-fpm gives us just the right combination of security, flexibility, and performance going forward to best serve our clients.


(c) 2020 Pure Energy Systems LLC - All rights reserved.

back to top