Performance tuning.- This step would consist of refactoring a web application’s source code, analyzing a web application’s configuration settings, attempting to further parallelize a web application’s logic, implementing caching strategies, detecting hot spots and another series of often invasive — code wise that is — procedures throughout a web application’s tiers. These topics will be detailed as the book progresses.
Vertical Scaling: In scaling terminology, this implies that a box or node on which a web application is running can be upwardly equipped with more CPU, Memory, Bandwidth or I/O capacity. Thus if a web application encounters a greater demand for any of these resources, and you are able to move a web application or one of its tiers to a box or node with greater capacity, you will have vertically scaled an application.
Horizontal Scaling: Horizontal scaling refers to assigning resources on a lateral basis. In scaling terminology, this implies that the node on which a web application is running cannot be equipped with more CPU, Memory, Bandwidth, or I/O capacity and thus a web application is split to run on multiple boxes or nodes.
The process of horizontally scaling a web application is more elaborate than that of vertically scaling. The reason is that by relying on horizontal scaling, you need to devise a way to decouple a web application. The simplest way to decouple a web application is by means of its tiers. Recapping from the previous paragraphs, these tiers would be:
Business logic tier.- Consists of a web framework for processing data provided by users or stored in the permanent storage tier. Depending on your preferences, this could be Ruby on Rails, PHP Cake, Django, Grails(Java) or MonoRail(.NET) among many others.
Permanent storage tier.- Consists of a permanent storage location for data. In most web applications this is a relational database system(RDBMS).