Joyent Scale Architectures
Applications on the Joyent Cloud are capable of supporting:
- Billions of page views a month
- Easily pushing over 3 Gigabits per second
- Handling tens of thousands of queries per second
To achieve this kind of scale requires adopting straighforward scale architectures that combine multiple accelerators into scale architectures. This section will review some of those architectural patterns.
Automatic CPU bursting makes Joyent 20X more powerful than Amazon
Even the smallest 1GB Joyent Accelerator comes with automatic CPU bursting. When you need the extra power, you get instant access to an additional 8 cores. The performance boost is tremendous. For example, a 1GB Joyent Accelerator running a PHP application on Apache and MySQL can support 20X as many page requests per second as a standard 1.7GB EC2 AMI running the same code. The Joyent Accelerator’s performance advantage comes directly from it’s access to more cores and better networking.
As you scale up the architecture that supports your application, this increased performance means you need fewer Web Tier servers, thus saving you substantial expense.
Stage 1 – Basic Deployment
You can launch a successful application on a single Accelerator™. For example, if it is a PHP application running on Apache and MySQL, you can have Apache and MySQL both running on that first Accelerator. You will still be connected to Joyent’s first rate networking and you will have access to services such as our NFS drives which can be used for back-up or for storage that needs to be shared in the future across multiple Web Tier servers.
As your application traffic grows you can add additional infrastructure when you need it.
Stage 2 – Load balancing, caching, redundant web tier and redundant DB tier
The second stage adding a Zeus Accelerator™, which will give you simple yet powerful web based GUI interface to configure and then run load balancing, and page cacheing. The load balancing will let you spread requests across multiple Accelerators™ running your Web Tier. The page cacheing holds copies of dynamically generated pages in memory and then servers them up at a rate of over 4,000 requests per second. Depending on the nature of your application, that can dramatically reduce the load on your back end servers.
With load balancing in place, you can start to horizontally scale your Web Tier by adding a second Accelerator™ running your application. For example, you might have two Accelerators running Apache with your PHP code loaded on both. The same principle applies for Rails code running on Mongrels or within Passenger.
Finally, you will split out your Database Tier and run a redundant configuration such as dual master MySQL Accelerators.™
Stage 3 – Redundant load balancing, caching and traffic management
The typical next step requires adding a second Zeus Accelerator™ to make the traffic management redundant. Zeus automatically takes care of clustering, which means that adding fail-over and increasing cacheing capacity and through-put capacity usually takes only minutes to configure.
Stage 4 – Horizontally Scale the Web Tier
In the fourth stage, adding extra capacity simply means horizontally scaling the Web Tier. If a given web server can handle 500 requests per second and your application needs to support 2,500 requests per second, then you need to have 5 Accelerators™ running the web tier.
Stage 5 – Vertically Scale the DB Tier
The last major step in scaling a web application typically requires scaling out the capacity of the Database tier. This means increasing the size of the Accelerators you are using to run your DB from 1GB to 2GB, 4GB, 8GB, 16GB or even 32GB. We recommend making sure that your data set is never more than 80% of the RAM you have available. This allows MySQL or PostgreSQL or Oracle or DB2 or CouchDB to respond to queries without having to hit the disk for data. Retrieving data from RAM is always faster than retrieving data from disk.