Performance vs. Scalability

The difference between Performance and Scalability

For software running on a single machine, the definitions are simple:

• Performance: speed.
• Scalability: ability to perform better as more CPU Cores are involved.

Speed is obviously desirable. But in a world of parallelism (multi-Core CPUs are today's reality) scalability is mandatory: without scalability, software can only use one Core or two (even if you have 64 idle Cores begging for work).

And without performance, scalability is pointless: if you need 64 Cores to achieve what can be done with one single Core, that's a shameful waste of resources (which comes at an hefty price).

Conclusion: Performance and Scalability are (much) needed. Preferably in equal amounts (close to the theorical ideal).

Horizontal and Vertical Scalability

The scalability described above is Vertical: this is the ability for software to perform better after hardware is upgraded (more CPUs, more CPU Cores, more RAM, more SSD disks) on a single machine.

Horizontal scalability is about using many more machines to do the job.

People often argue that Vertical scalability is not as important as Horizontal scalability. For example, Yahoo! had to deploy a 50,000-node Hadoop network to do what Hadoop cannot do on one single machine. But this luxury comes at a cost:

• computational: machines must dispatch jobs and this is wasting resources that local processing can better use;
• temporal: the network layer overhead injects very high latency (the network is much slower than system memory);
• financial: 50,000 machines cost hundreds of millions of dollars recurringly for floor space, staff, hardware and electricity.

So, when this is possible, scaling Vertically is much more desirable than scaling Horizontally: it costs far less in terms of CPU and memory load, latency and money. Vertical Scalability makes Horizontal Scalability fly, reducing the number of machines you need while providing faster results!

Historically, the choice of scaling Horizontally was mainly due to the fact that massive Vertical scalability was limited to Super-computers (the only machines enjoying a lot of RAM and many CPUs).

Today, the frontier between Super-computers and Workstations is blurring because of multi-Core CPUs. And this is merely the beginning: we will soon have 128/512/1024-Core CPUs. With 4 CPUs per machine, that will give 4x more Cores.

The Multi-Core Revolution

The Need

In 2003, heat dissipation issues have made raising CPU clock frequency impractical. Then, instead of growing in speed, CPUs grow in parallelism, doing as many things simultaneously as they have 'Cores' (clones of the CPU that work in parallel).

But, despite billions of dollars invested by private and public research those last 10 years, software, traditionally based on procedural code, has still to make the shift towards parallelism techniques. multi-Core systems are un-used or under-used.

The Lawrence Berkeley National Laboratory says "this will be a huge shift" (The Economist, « Parallel bars », June 2nd 2011).

While a "client" Internet browser has to merely satisfy its own needs, a server must, by definition, satisfy the requests of hundreds of thousands of such clients – simultaneously.

As every Desktop application migrates to the Cloud or to Software as a Service Platforms (SaaS), the need for efficient server software is growing and they will make the difference between success and failure (companies like Google, Facebook or Amazon value every percent of efficiency gain because it directly translates into recurring savings in the tenths of millions of dollars in staff, hardware infrastructure, floor space, energy bills – and soon carbon taxes).

Yet, the software revolution expected to match the evolution of hardware has still not happened. Scientists say that "wait-free" parallel-ready data structures are "really hard" to create.

The Solution

G-WAN, an Application Server, is both the fastest and scales better than anything else on the market, outperforming the most recent research projects and even products called 'Web accelerators' – by several orders of magnitude.

G-WAN was designed for for Web applications but the same technology will shine equally in any server (high-concurrency) application like Proxy servers, Database servers, Big-Data, Email servers, Voice over IP servers, etc.

As time goes, the need for such a technology will only be more and more a necessity as the number of CPU Cores grow while at the same time their resources remain un-exploited

Add raising fixed costs (electricity, floor-space, staff) and budgets in free-fall (due to a long-term global economic depression) and this will be a devastating mix for end-users and developers.

Using G-WAN will therefore provide a decisive competitive advantage to its users – whatever their size.

The Future

Disruption happens when incumbents are displaced. And this is going to happen as fast as CPUs grow in power (twice as much every 18 months) by stacking Cores rather than by increasing their speed (the CPU clock rate).

Our world is a place where the Web server market shares are occupied by server applications that do not perform well and do not scale well on multi-Core architectures:

    Web server       Market shares  (Netcraft ratings, October 2011)
 ---------------    ---------------
    Apache (IBM)          65%
 IIS (Microsoft)          15% 
 Nginx (Rambler)           8%

With those Web servers, the performance gap is even worse when scripted programming languages (C#, Java, PHP, Go, etc.) are used to generate dynamic contents. By contrast, G-WAN makes all the programming languages fly:

On a mere 6-Core CPU, G-WAN generates dynamic contents several millions of times faster than Apache, IIS and Nginx.
Guess how much larger the gap will be on a 64 or 256-Core CPU.

Therefore, a newly designed Web server that performs and scales will be in the unique position of making all its competitors obsolete.

15 years ago, IBM acquired Apache – which is still the market leader today.
And that was before the Cloud and SaaS (Software as a Service).