The most common question we get at PHP Fog is “is this like a VPS?” Many PHP developers have worked with shared and dedicated hosting wonder what a “cloud-based” (fully managed) stack like PHP Fog can provide. We provide unprecedented scalability, but what does that mean?
Scalability in this context is the ability for your application to increase capacity to serve web pages by easily adding more servers (scaling out), or increasing the power of each server (scaling up).
Over the past few weeks I have been working at PHP Fog as a Product Manager. PHP Fog is a new type of hosting provider for PHP applications developers to build applications the good old-fashioned way but with easy scaling, reliability, speed, and easy deployment/management compared to traditional shared/dedicated hosting. As a Product Manager, I am the conduit between the product team (i.e. the developers), and the customers; in that context I get to talk to a lot of customers. Since most PHP developers build applications hosted on shared or dedicated (“traditional”) hosting, I frequently explain the differences between traditional and cloud hosting. Many questions can be answered by this PHP Fog Technology overview page. Most customers understand reliability, easy deployment, and speed; scalability leaves them hanging. So lets look at some scenarios where scalability plays a role.
- Site shut-down due to surge of traffic: You have a WordPress blog hosted on a popular shared hosting provider like HostGator, BlueHost, DreamHost or RackSpace. You have an article on their you post to a popular service like Slashdot, Digg, Mashable, or Hacker News, and it actually picks up traction. You get a surge of traffic to the site, and your site gets shut down immediately. Shared hosting fail! Your site will be shut down either because you used up your bandwidth, or because your website was impacting the performance of the other websites hosted on the service.
- Consistent growth leads to performance degradation and forces re-design: The first scenario happens, but it’s rare enough that few plan for it. The more common scenario is that you build some kind of small website and host it on a dedicated server. The website slowly gains popularity and it starts impacting the load time. Now you have to do a ton of work to figure out where the bottlenecks are, how to alleviate them, and quite possibly re-implement some core pieces to make it scale with the consistent growth.
- Paying for underutilized servers: You build a SaaS application for business customers. Looking at the usage pattern you will see that between 9AM and 5PM you get thousands of hits but virtually no usage after 5PM and before 9AM the next day. In that case you have to pay for the dedicated servers to run the applications 24/7 even though most of the time they sit idly.
In these first two scenario serving websites was hindered because some limited resources were depleted… which ones?Is it the web server CPU/memory? Usually no. Typically code is fast enough that it isn’t the first bottleneck. Avoiding some obvious poor implementations will help, then there are loads of ways for optimizing the code even further.
- Is it bandwidth (I/O) to your web server? Yup! Web servers are limited in the number of concurrent connections they can maintain (tubes aren’t big enough). This is typically the first resource that is depleted as a single page load requires many request/responses and each one does a little bit of processing.
- Is it database size? Rarely. Unless you are storing large data (e.g. images, GIS) in a database, chances are you won’t be running out of space on the database. For large data where complex queries are not required typically blob storage like Amazon’s S3 are a better option as opposed to relational databases like MySQL.
- Is it bandwidth to your DB? Probably not! The number of requests between your app server and your database is a fraction of the number of requests the client makes to your web server. Furthermore, databases are typically hosted in the same data center with high throughput and low latency between the web server and the database.
- Is it the CPU/RAM/IO on the DB? Yup. With larger data sets, more complex queries, needless queries, or sharing a database, it is forced to do a lot of query execution. This means that a single request can take a longer time to process.
This is just an introduction to the concept of bottlenecks and how to alleviate those bottlenecks. Before you figure out how to scale your application, first you need to make sure that it is written to be efficient end-to-end. There are many things you can do to make a website faster. Like with any problem, first you’ll have to diagnose, then you’ll have to solve the problem. To diagnose the problem you can use tools like YSlow, Jiffy, and WebGrind. These will only help you identify where the bottlenecks are; you’ll have to identify the root cause and fix it yourself. The article “Fast PHP – effective optimisation and bottleneck detection” is a great start for helping you fix those bottlenecks. Just as a hint, some common solutions include, caching, fixing slow code, optimizing DB queries and DB design, not using shared resources, client-side optimization (e.g. javascript), and optimizing intermediate code. PHP Fog does it all of this except making changes to your code.
Once you have done this, you can increase the performance, and therefore total capacity quite significantly. Caching alone can improve application performance 50+ percent. But once you do all these things, you will still need to handle more users. This is where scalability comes into play.
We can now assume that we’ve optimized the PHP application and the corresponding MySQL database to the best of our knowledge. And it still isn’t enough. There are two options for scaling (making more resources available) for your web server.
Scaling Up/Out
First option is to scale up your application server. This means you increase the overall power of the server (CPU, memory, etc). This will provide more of the resources we were talking about before. While easy, this unfortunately isn’t a good strategy for scaling. The server is still bound by its hardware (or virtual hardware), so there is still a clear limit when you just increase the power of a single server. Furthermore, as explained before, the first bottleneck is typically the bandwidth (I/O) not the CPU or memory, so this helps some, but it’s only adding resources but in the wrong area.
When scaling up does not work any more, the only other option is scaling out. You almost always have to do this yourself. This option is not provided by any VPS or most other hosting providers. It means adding more servers to spread the traffic across numerous servers. As mentioned before the first bottleneck is typically the bandwidth (I/O) on the web server. This a mechanism to spread the load, which is done by a “load balancer”, a special kind of server which intelligently forwards requests to one of your web servers.
I’ve been focusing on scaling up and out; however, scaling down for business is equally important. People want to pay only for what they use. If you need to use 5 servers for a couple hours a day it would be great only to pay for those five servers for those couple hours only. Traditional hosting forces you to pay for the servers on a monthly basis, regardless of how much it is used.
Regardless of the type of host you are using, there are a few things you will need to do to scale out: (1) get a new server from the host provider, (2) setup and configure the server software, (3) setup your application on the server, (4) setup the load balancer to distribute the traffic.
Scaling on traditional hosting
Scaling an application on traditional hosting is very difficult. All four of the steps for scaling out are done manually each time you want to add a new application. This isn’t trivial. There is even more pain involved with managing this over time. Every time you have to deploy a new version of your application, or add more servers there is going to be a lot of time spent on making sure everything is configured and setup properly.
Scaling on cloud hosting
With “cloud-hosting”, like PHP Fog, all of those steps are completely removed from the pictured and handled by the PHP Fog infrastructure. In PHP Fog if you want to scale out from 1 to 5 servers, PHP Fog will automatically do those steps 1-4 explained above in just 30 seconds. From our management console you only have to move the scale-slider from 1 to 5 and hit the “Confirm” button. When we say “easy scaling” that’s exactly what we mean. Scaling down is equally easy. Deploying a new version is also easy, you just push a new version via git push and your code automatically gets distributed to all the servers in just 30 seconds.
