The Hardware Cost of Scaling

When applications exhaust the capacity of a single machine and need to “scale out” across additional machines, scalability becomes difficult and expensive. One of the major problems is that there are diminishing returns from each additional machine, until at some point adding more machines actually decreases performance.

The reason for diminishing returns is simple: there are centralized components, primarily the database and messaging systems, which become overloaded as the application scales up. The higher the application’s throughput, the harder the database and messaging servers need to work, and the more time the application needs to spend waiting for these resources to respond – this is called contention. Contention degrades application performance, and this degradation gets worse the more the application is scaled up.

If it difficult to quantify the performance degradation, but it does have a known minimum threshold, given by Amdahl’s Law, the most broadly-used theoretical model of software scalability. In any real-world system, including your enterprise applications, performance degradation as a result of contention will necessarily be more than this. So let us assume that when your apps scale up, they will experience only this minimum performance degradation.

The minimal performance degradation depends on the contention. For database-driven applications, a realistic contention figure is 30%.

NOTE: Most applications today are estimated to have between 10-50% contention. 10-20% contention is typical in event-driven applications with no high availability. 20-30% is typical for small-scale reliable messaging systems. 25-40% is typical for database-centric web applications or information systems. 40-50% is typical for applications which integrate with back-end systems or rely on an ESB.

Now let’s consider an ambitious but realistic scaling scenario. An enterprise application running on 10 machines needs to scale up three-fold to meet future loads.

According to Amdahl’s Law, with 30% contention, the application needs to add at least 200 machines to achieve three-fold scalability. This may sound unbelievable, but it is a theoretical minimum which all applications are bound to. In real-life, much more than 200 machines will be needed.

Hardware Savings Due to Linear Scalability

With GigaSpaces XAP, the same application will have linear scalability, under two assumptions:

• The application uses XAP as its application server, messaging server, and In-Memory Data Grid. Applications running on XAP can use other products for these functions, but then XAP will not guarantee full linear scalability.
• No use of aggregated queries on all data. An aggregated query, by definition, precludes linear scalability because it needs to access all data.

If these assumptions are fulfilled, with XAP only 20 more machines need to be added to achieve three-fold scalability. Compared to the theoretical minimum of 200 machines in the traditional system, this represents a saving of 90%.

To see the savings figures for a selected range of scaling factors and contention rates, refer to Save 15-90% of Hardware Costs When Scaling Enterprise Applications.