This blog post was co-authored by Vemula Srimithra, Senior Software Engineer, and Aman Chaudhary, Senior Manager, Engineering, at Citrix.

NetScaler’s new jump table assisted ring hash (JARH) load balancing algorithm can improve your CPU utilization by up to 5x and save on operational costs. We created the JARH algorithm based on the principle of consistent hashing, and it offers stateless persistence for your apps, giving you improved performance with lower operational costs.

Apps and web services come in two forms: stateful or stateless. Stateful transactions are characterized by an app’s intent to store information and use it to make decisions when a client interacts with it. For example, an e-commerce shopper can close their browser and later can resume shopping and check out. Statelessness is ephemeral, often lasting a single transaction. Each new transition begins without knowledge of past transactions or past data — for example, downloading a file from a public website.

NetScaler ADC can help you load balance apps in a stateful or a stateless way — whichever best suits each deployment. In this blog post, we’ll look at a brief overview of consistent hashing and compare NetScaler ADC’s JARH with another popular algorithm.

NetScaler ADC Consistent Hashing Algorithm – JARH

With the growth in microservices, stateless app deployments are common. Services are lightweight and can spawn or re-spawn on any node in a distributed system. While there are ample methods to maintain state in microservices environments, there are often challenges such as defining persistent and scalable storage, handling a high number of sticky transactions, and dealing with connection or network failures.

Consistent hashing has long been the primary way to solve these problems. But current load-balancing options face issues such as maintaining uniform load distribution, consistency during failure events, and software performance challenges.

The highly compute-efficient JARH load balancing algorithm achieves near-perfect consistency when selecting backend app services. It also provides uniform traffic distribution, while being able to achieve stateless persistence in a fault-tolerant manner. This ensures that no single backend server gets overloaded while enabling organizations to save on costs by deploying fewer ADC instances.

JARH vs. CARP

Many vendors adopt the cache array routing protocol (CARP) for load balancing consistency in their traffic management solutions. NetScaler has used CARP in the past, but tests have shown JARH to be superior in terms of CPU utilization.

To compare, we looked at the new JARH algorithm and F5’s implementation of CARP, using equivalent virtual devices on AWS. We tested each system with 5,000 requests/second and 10,000 requests/second while load balancing 100, 1,000 and 5,000 backend servers. We measured the average CPU utilization (%) of the system for each combination.

Figure 1. JARH vs CARP CPU Utilization for 5,000 req/sec (figure references Citrix ADC, which is the previous name for NetScaler ADC)

Figure 2. JARH vs CARP CPU Utilization for 10,000 req/sec (figure references Citrix ADC, which is the previous name for NetScaler ADC)

As you can see, the JARH algorithm was far more efficient than CARP. In both tests (5,000 and 10,000 requests per second), CPU usage was lower at the outset and, unlike CARP, NetScaler’s JARH algorithm didn’t exhibit a significant increase in CPU utilization as the number of backend servers increased.

As shown in Figure 2, the F5 device using the CARP protocol saturates the CPU (82 percent) but the NetScaler ADC using JARH only registers 16 percent utilization.

So, at the low end, with 5,000 requests/second and 100 backend servers, NetScaler ADC performs 3x better. At the high end, with 10,000 requests/second and 5,000 backend servers, NetScaler ADC performs more than 5x more efficiently than the system running CARP.

This means that a single NetScaler ADC can process the same amount of traffic but still have compute capacity left over. So, what does this mean for your production environments?

The number of requests per second processed by apps varies widely. Popular websites such as Wikipedia, Twitter, and GitHub process tens of thousands to hundreds of thousands of requests per second. Moderately sized apps may process a few hundred to a few thousand requests per second. A NetScaler ADC running JARH can serve a broad range of customers, with different workloads.

When a small number of backend servers are used for an app, the NetScaler ADC using JARH, consumes up to 66 percent less CPU resources than ADCs from other vendors. This leaves plenty of additional computing for other ADC functionality, such as:

• Accepting more requests during peak hours or holiday seasons without having to scale up or scale down instances.
• Increasing the number of backend servers without worrying about capacity issues.
• Accommodating additional compute-intensive features and capabilities on the same  NetScaler ADC platform.

Customers with larger, more distributed apps that have several hundred to a few thousand backend servers can experience the benefits of JARH to its full capacity. While F5 BIG-IP or a similar product may be overwhelmed by an increase in the number of backend servers, a single NetScaler ADC can efficiently handle these changes with ease. This efficiency translates into significant cost savings as a single NetScaler ADC can do the job of multiple other products.

With application workloads becoming more dynamic, NetScaler ADCs are adapting to the characteristics of the apps they front. They can efficiently handle a broad range of workloads with relative ease. This ensures the user experience remains unaffected by the application’s scale and ephemeral nature while being able to deliver a high-performing and cost-effective solution.

Learn More

To learn more about load balancing methods based on hashes, check out the documentation on hashing methods on NetScaler ADC.