What is scalability ?


The rapid development of large clusters built with commodity hardware has highlighted scalability issues with deploying and effectively running system software in large clusters. The concept of scalability applies to business and technology. In this the base concept is consistent i.e., the ability for a business or a technology to accept increased volume without impacting the revenue variable costs. For example in some cases the variable cost will increase and reduce the revenue variable costs.


It is a performance measure for the execution of the software that refers to its ability to accommodate expanding traffic measures like number of users, activity of each user and so on.

In telecommunications and software engineering, scalability is a desirable property of system, network, process which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged. For example, it can refer to the capacity of the system to increase total throughput under an increased load when resources are added.

Scalability is generally difficult to define and in some case we define the specific requirements for scalability on some important dimensions. It is a highly significant issue in database, routers and networking. Scalable system is the system whose performance improves after adding hardware proportional to the capacity added is called scalable system. An algorithm, design, networking protocol, program or other system is sad to scale if it is suitably efficient and practical when applied to large situations. If the design fails when the quantity increases then it does not scale.


Software scalability analysis is an important issue for most businesses. It is essential that as the customer base increases, the system has to deal with significantly increased loads, the system is designed to handle the increased traffic so that the users do not encounter unacceptable system performance.

Scalability is an important goal for many software development projects and software installations because without scalability success might be hampered by poor performance as observed by end users.


The various dimensions by which the scalability can be measured are:

  1. Load scalability: it is the ability of a distributed system to easily expand and contract its resource pool to accommodate heavier or lighter loads.
  2. Geographic scalability: It is the ability to maintain performance, usefulness, or usability regardless of the expansion from concentration in the local area to a more geographic pattern.
  3. Administrative scalability: The ability for an increasing number of organizations to easily share a single distributed system.
  4. Functional scalability: The ability to enhance the system by adding new functionality at minimal effort.


It is often advised to focus system design on hardware scalability rather than on capacity. It is typically cheaper to add a new node to a system in order to achieve improved performance than to partake in performance tuning to improve the capacity that each node can handle. But this approach can have diminishing returns (as discussed in performance engineering). For example: suppose a portion of a program can be sped up by 70% if parallelized and run on four CPUs instead of one. If α is the fraction of a calculation that is sequential, and 1 − α is the fraction that can be parallelized, then the maximum speed up that can be achieved by using P processors is given according to Amdahl’s Law:.

Substituting the values for this example, we get

If we double the compute power to 8 processors we get

Doubling the processing power has only improved the speedup by roughly one-fifth. If the whole problem was parallelizable, we would, of course, expect the speed up to double also. Therefore, throwing in more hardware is not necessarily the optimal approach.


In the context of high performance computing there are two common notions of scalability. The first is strong scaling, which is defined as how the solution time varies with the number of processors for a fixed total problem size. The second is weak scaling, which is defined as how the solution time varies with the number of processors for a fixed problem size per processor.


A scalable online transaction processing system can be upgraded and can be used to produce more transactions by means of adding new processors, devices and storage that can be upgraded easily. It is also called as database management system.

If the size of the necessary routing table on each node grows as O (log N) then the routing protocol is considered as scalable with respect to the network size where N is the number of nodes in the network.

The distributed nature of the Domain Name System allows it to work efficiently even when all hosts on the worldwide Internet are served, so it is said to “scale well”.

Some early peer-to-peer implementations of Gnutella had scaling issues. Each node query flooded its requests to all peers. The demand on each peer would increase in proportion to the total number of peers, quickly overrunning the peers’ limited capacity. Other P2P systems like Bit Torrent scale well because demand on each peer is independent of the total number of peers. There is no centralized bottleneck, so the system may expand indefinitely without the addition of supporting resources.


Methods of adding more resources for a particular application fall into two broad categories:


To scale vertically (or scale up) means to add resources to a single node in a system, typically involving the addition of CPUs or memory to a single computer. Such vertical scaling of existing systems also enables them to leverage Virtualization technology more effectively, as it provides more resources for the hosted set of Operating system and Application modules to share. Taking advantage of such resources can also be called “scaling up”, such as expanding the number of Apache daemon processes currently running


To scale horizontally (or scale out) means to add more nodes to a system, such as adding a new computer to a distributed software application. An example might be scaling out from one web server system to three.

As computer prices drop and performance continues to increase, low cost “commodity” systems can be used for high performance computing applications such as seismic analysis and biotechnology workloads that could in the past only be handled by supercomputers. Hundreds of small computers may be configured in a cluster to obtain aggregate computing power which often exceeds that of single traditional RISC processor based scientific computers. This model has further been fuelled by the availability of high performance interconnects such as Myrinet and InfiniBand technologies. It has also led to demand for features such as remote maintenance and batch processing management previously not available for “commodity” systems.

The scale-out model has created an increased demand for shared data storage with very high I/O performance, especially where processing of large amounts of data is required, such as in seismic analysis. This has fuelled the development of new storage technologies such as object storage devices.


There are tradeoffs between the two models. Larger numbers of computers means increased management complexity, as well as a more complex programming model and issues such as throughput and latency between nodes; also, some applications do not lend themselves to a distributed computing model. In the past, the price differential between the two models has favoured “scale out” computing for those applications that fit its paradigm, but recent advances in virtualization technology have blurred that advantage, since deploying a new virtual system over a hypervisor (where possible) is almost always less expensive than actually buying and installing a real one.


Scalable system software has become an important factor to the RCF for efficiently deploying and managing our rapidly growing Linux cluster. It allows us to monitor the status of individual cluster servers in near-real time, to deploy our Linux image in a fast and reliable fashion across the cluster and to access the cluster in a fast, parallel manner. Because not all of our system software needs can be addressed from a single source, it has become necessary for us to use a mix of RCF-designed, open-source and vendor-provided software to achieve our goal of scalable system software architecture.