Fengqi.Asia Cloud technologies are currently used to allow applications to scale to support:
- Billions of page views a month
- Handling tens of thousands of queries per second
- Growing from 0 to millions of users per day in less than 90 days
To achieve this kind of scale requires adopting straightforward scale architectures that combine multiple SmartMachines into scale architectures. This section will review some of those architectural patterns.
Automatic CPU bursting provides vertical scale
Even the smallest Fengqi.Asia SmartMachine comes with automatic CPU bursting. When applications require additional power, they have immediate access to a deep resource pool for additional CPU. The performance boost is tremendous, and it comes exactly when it’s required—not minutes later.
As you scale up the architecture that supports your application, this as required vertical scale reduces the need for over-provisioning in the web tier, thus saving you substantial expense.
Stage 0 – Single SmartMachine deployment
Successful applications on a single SmartOS SmartMachine are common. For example, if it is a PHP application running on Apache and MySQL, both can run on the same instance of SmartOS SmartMachine.
Applications using Fengqi.Asia’s public cloud hosting are connected to high-speed networking and have access to services such as 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.
Stage 1 – Basic tiered deployment
The recommended approach to small-scale application architecture is to separate the database and web tier. This provides enhanced performance over the basic deployment by providing access to specialized SmartMachines, such as the Perconna SmartMachine.
This architecture also provides modularity at the network level which makes it easier to transition to larger scale applications without modifying the architecture. As application traffic grows you can add additional infrastructure where you need it—such as increasing the size of the database without affecting the web tier.
Stage 2 – Load balancing, caching, redundant web tier and redundant DB tier
The second stage adds load balancing. For example, Stingray Traffic Manager provides a simple yet powerful web based GUI interface to configure and then run load balancing, and page caching. The load balancing can spread requests across multiple SmartMachines running the web tier. The page caching holds copies of dynamically generated pages in memory and then servers them up at thousands of requests per second. Depending on the application, that caching can dramatically reduce the load on back end servers.
With load balancing in place, the web tier can horizontally scale by adding a second SmartMachine. For example, the application might have a pair of SmartMachine running Apache with PHP code loaded on both SmartMachines. The same principle applies for Rails code running on Mongrels or within Passenger.
Stage 3 – Redundant load balancing, caching and traffic management
The typical next step requires adding a second load balancer, such as a Stingray Traffic Manager, to make the traffic management redundant. A load balancer can automatically take care of clustering, which means that adding fail-over and increasing caching 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 an application needs to support 2,500 requests per second, then 5 SmartMachines are required in 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 SmartMachines 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.
