Scaling Your Web Application: VPS vs PAAS

Andy Hawthorne
Andy Hawthorne
Share
You have deployed your Rails application to your VPS, or to Heroku. Traffic starts to arrive as interest in your application builds. Next, it goes viral. Then your application crashes… Much has been discussed about the scalability or otherwise of Rails. Conventional wisdom suggests that it’s not the web application itself that crashes due to high traffic volumes, it’s simply a case of a lack of hardware resources. So, what options are there to scale your app on a VPS? And what about for Heroku? Let’s see…

First, What Rails Can Do To Help?

Best advice suggests that we should turn on page caching for our Rails apps wherever we can. We have an article here on Rubysource that provides plenty of information about HTTP caching. The bottom line is: page caching helps with server load because the normal cycle of request/response that runs through like this:
  • Request from the client
  • Apache passes the request to say, Mongrel
  • Mongrel sends the response to Apache
  • Response is sent to the client
Mongrel can handle around 20-50 requests per second, which is good for 2 million hit a day, or thereabouts. By switching on page caching, Apache can serve cached pages (usually) from the public directory of our app without the need for a further request to Mongrel. There are three options that we can use with Rails:

1. Page Caching

With page caching switched on, the web server (Apache or nginx) can avoid the Rails stack entirely. That will only work for some scenarios – it couldn’t be used for pages that need authentication for example.

2. Action Caching

Action caching solves the problem mentioned above, by sending requests to the Rails stack. Action Pack configured with before filters can then be run before the cache is served. That is a powerful feature because it means that authentication can run before a page is served from a cached copy.

3. Fragment Caching

Fragment Caching allows a section of a view to be enclosed in a cache block, and served out of the cache store for each request. For example, if you had part of a view that contained a list of blog posts you want to cache that list: [gist id=”3702298″] It is also possible to cache multiple fragments by setting the :action_suffix . It’s good practice to utilise these options generally, but when we start to investigate scaling options, you’ll see that there is another reason too.

Scaling – Hardware Considerations

There are two aspects to consider when considering scalability issues:
  1. Capacity – To achieve effective load balancing, the best method is to increase capacity by adding hardware. As load increases, adding extra hardware will help to distribute the load and maintain stability for end users.
  2. Redundancy – In this context redundancy means that, if a server fails, it doesn’t bring down the whole system. Instead, it just reduces the capacity by the amount that it added in the first place.
This combination of capacity adjustment and redundancy is usually achieved through load balancing
.

Scaling an App Deployed on a VPS

So, you have deployed your app on a Virtual Private Server(VPS). Something like Linode, or Webbynode for example. Scaling options are available for most VPS hosting services. Linode has a comprehensive set of load balancing options, so let’s see what can be done.

Getting Started

Linode uses what it calls NodeBalancers that listen on a public IP address for incoming connections. You can apply sets of rules that are used to configure which backend node (there can be more than one) the connection gets sent. NodeBalancers can also assess the incoming request and make decisions based on what it contains. There is one complication though. If your app uses sessions they will need to be directed to to the node that the app is running on. The Linode NodeBalancers solve this problem because they can be configured to ensure the same client lands on the same backend node.

An Important Caveat

Most VPS hosting will offer some form of scaling, perhaps not to the same depth that Linode does, but it will be there. Be careful of cost though. For example, for NodeBalancers to work you have a static IP address. That involves adding an admittedly small cost to your monthly bill. The real hit comes from applying a NodeBalancer. It costs an extra $19.95 a month to switch one on. That’s on top of your normal monthly fee.

The Steps For Setting Up a NodeBalancer

Assuming that you have purchased a static IP address, and added a NodeBalancer to your account, you can now configure it. The basic steps are:
  1. You choose a port for the Balancer to listen on. Port 80 is fine to pick up regular web traffic.
  2. In the configuration screen, there are a number of options, such as session stickiness to handle the session problem described earlier. You can also set a check interval which determines the number of seconds between health check probes. These options are clearly explained on the configuration screen.
  3. You then point the backend node to the private IP address for your web server
  4. After everything has updated, you should be able to go to the the NodeBalancer’s IP address and see your web app as before.
That’s the procedure to add one extra backend node. If your app needs more, then you will need to purchase another one and follow the same routine. You can see that this could get expensive quite quickly, but it is also worth pointing out that you would need to be experiencing some serious traffic to consider buying extra NodeBalancers.

What About Heroku?

Heroku offer some nice scaling options that can be defined as two choices:
  • Web dynos
  • Worker dynos
Web dynos allows your app to handle more concurrent HTTP requests, while worker dynos allow you to process more jobs concurrently. They also offer various database solutions to assist with caching of queries too. If you are experiencing a slow down that is coming from data related processing, adding more web dynos could make the problem worse. Optimising queries would be a first step to solving that problem. You can apply scaling options from the command line. For example, to apply web dynos you simply do:
heroku ps:scale web=2 
Or to apply workers and well as web processes:
heroku ps:scale web=2 worker=1 

Pricing

This gets expensive quite quickly too. For example, to have 2 web dynos and 1 worker, it will cost you $71 per month. Add a 400Mb database cache, and that’s a further $50 per month. Again, that cost might be considered minimal if you have a production web application that is serving it’s purpose well.

Finally…

If you have deployed to a VPS, scaling your app is made easy via the manager or admin control panel that VPS services normally provide. It is really a matter of adding the extra resources and paying for them. The configuration options are well explained (certainly in Linode’s case), so increasing resources is not the technical issue it once was. Cloud based services such as Heroku and Webbynode also make it easy to scale up (or down), based on what your traffic monitoring is telling you. So the only challenge now, is to drive that traffic in!

Frequently Asked Questions (FAQs) on Scaling Your Web Application: VPS vs PaaS

What are the key differences between VPS and PaaS?

VPS (Virtual Private Server) and PaaS (Platform as a Service) are two different types of web hosting solutions. VPS is a type of hosting where you get a portion of a physical server dedicated to your website, while PaaS is a cloud computing model where a third-party provider delivers hardware and software tools over the internet. The main differences lie in their level of control, scalability, and cost. With VPS, you have more control over your server but it requires more technical knowledge. PaaS, on the other hand, is more scalable and requires less technical knowledge, but you have less control over your server.

Which is more cost-effective: VPS or PaaS?

The cost-effectiveness of VPS and PaaS depends on your specific needs. VPS can be more cost-effective for smaller projects or businesses with a tight budget, as you only pay for the resources you use. However, as your business grows, PaaS can be more cost-effective due to its scalability and the fact that you don’t have to worry about server maintenance or upgrades.

Is PaaS more secure than VPS?

Both VPS and PaaS have their own security measures. With VPS, you are responsible for your own server security, which can be a benefit if you have the technical knowledge to manage it. PaaS providers, on the other hand, handle security on their end, which can be a benefit if you lack the technical knowledge or resources to manage server security.

Which is easier to manage: VPS or PaaS?

PaaS is generally easier to manage than VPS. With PaaS, the provider handles all the server management tasks, including maintenance, updates, and security. This allows you to focus on developing your web application. With VPS, you are responsible for managing your server, which requires more technical knowledge.

Can I switch from VPS to PaaS or vice versa?

Yes, you can switch from VPS to PaaS or vice versa. However, the process can be complex and requires careful planning to avoid data loss or downtime. It’s recommended to consult with a professional or your hosting provider before making the switch.

Which is more scalable: VPS or PaaS?

PaaS is generally more scalable than VPS. With PaaS, you can easily scale up or down based on your needs, without having to worry about server capacity. With VPS, while you can scale up, it often requires more technical knowledge and can be more time-consuming.

What are the main advantages of VPS?

The main advantages of VPS include more control over your server, cost-effectiveness for smaller projects, and the ability to customize your server to your specific needs.

What are the main advantages of PaaS?

The main advantages of PaaS include easy scalability, less technical knowledge required, and the ability to focus on developing your web application instead of managing a server.

Is VPS or PaaS better for startups?

The choice between VPS and PaaS for startups depends on the specific needs of the startup. If the startup has a tight budget and requires more control over their server, VPS may be a better choice. However, if the startup is expected to grow quickly and requires easy scalability, PaaS may be a better choice.

Can I use both VPS and PaaS for my web application?

Yes, it’s possible to use both VPS and PaaS for your web application. For example, you could use VPS for your main website and PaaS for your mobile app. However, this requires careful planning and management to ensure seamless integration between the two.