Introduction
Application delivery services are critical for successful applications. Whether such services add scalability, reliability, or security, most applications rely on one or more. Application Delivery Controllers (ADCs), therefore, occupy a critical place in most application, cloud, and data center designs.
For many environments, including private cloud installations, dedicated ADC hardware is still the preferred platform for delivering application delivery services. This is because a dedicated platform incorporates controlled, stable, and consistent resources. A dedicated, purpose-built appliance can consistently deliver the performance and reliability that even the most demanding application workload requires, because it has no variation in hypervisor, software, or underlying compute platform—plus it has the advantages of specialized hardware components to offload tasks from the CPU.
But what does “performance” actually mean? In general, ADC vendors publish four main types of metrics to demonstrate performance:
- Requests per second (RPS)
- Connections per second (CPS)
- Transactions per second (TPS)
- Throughput (often measured in gigabits per second, Gbps)
Manufacturers provide comprehensive data sheets listing these and other platform characteristics, including tables of throughput, SSL transaction numbers, or concurrent connections. Interpreting these numbers and their relevance to an application workload, and understanding the likely limits and bottlenecks of a system, are essential to selecting the correct platform. Learning to interpret vendor data sheets and understand the metrics relevant to your applications can help you be more successful in selecting the right platforms for your business.
What Does an ADC Do?
An Application Delivery Controller is an infrastructure component that acts as an application proxy, providing application delivery services such as traffic management, load balancing, SSL decryption, application layer security, and access control for applications. Client devices and services connect to the ADC, and the ADC creates a separate (or reuses an existing) connection to the application. In this logical gap, the ADC inserts application delivery services.
To understand the workload of an ADC, it is helpful to look at a TCP connection and application-layer request. The ADC must perform tasks at multiple layers of the TCP stack and accomplish a number of activities to deliver application services to the application traffic. (See Figure 1.) This can make interpreting performance metrics from ADC vendors difficult. A key prerequisite for understanding which metrics are relevant is to identify the workload type.
There are many types of applications and therefore many different ADC workloads. While most production deployments contain a mix of workloads, the impact and needs of each workload influence which components of an ADC will be most utilized. Even within components, workload needs vary. Some workloads may be more sensitive to latency, others more sensitive to jitter; some workloads are sensitive to throughput limits, while some workloads are more dependent upon availability.
Here are the most common workloads, along with the key metrics that support them:
- Currently, the most common workload, used by websites and many mobile applications, is transactional HTTP web applications, often using SSL and TLS. The most important metrics for this workload are all of the SSL metrics: RPS, TPS, and throughput, as well as the layer 7 RPS and CPS.
- DNS is another common workload used in almost all Internet exchanges. DNS is used frequently, with the volume of traffic low and commonly deployed using UDP instead of TCP. As a result, the most important metrics are layer 3 and layer 4 throughput.
- The REST API is growing quickly in use, and refers to a common API transport for services. As a result, REST API is often used in machine-to-machine communication. Because the REST API is based on HTTP, the key metrics are the same as for HTTP (all of the SSL metrics): RPS, TPS, and throughput, as well as layer 7 RPS and CPS.
- MQTT is an emerging messaging protocol that has many uses and is growing quickly in Internet of Things (IoT) communication. Like the REST API, MQTT is primarily found in machine-to-machine applications. The key metrics for MQTT are layer 4 CPS and throughput.
- Diameter is a replacement for the RADIUS authentication protocol that operates at layer 4 and holds TCP connections open for long periods of time. Its key metrics are layer 4 CPS and the robustness of the layer 4 connection table.
- Financial trading protocols such as FIX, SAIL, and OUCH are sensitive to latency at both the layer 4 and layer 7 level. That makes its key metrics layer 4 CPS, plus layer 7 RPS and CPS.
- WebSockets technology is a relatively recent addition to workload types, whereby the server can initiate communication with the client over a long-lasting layer 4 and layer 7 connection. Key metrics are layer 4 CPS, layer 7 RPS and CPS, and the robustness of layer 4 and layer 7 connection tables.
- Logging and alerting workloads all operate at layer 4 and some are based on the REST API, which operates at layer 7. As a result, a key metric is layer 4 CPS and, for those based on the REST API, layer 7 RPS and CPS.
Workload mixes continue to evolve and new workloads are constantly being introduced, each with its own critical ADC metrics based on the workload’s primary operations.
Continue Reading https://f5.com/resources/white-papers/understanding-adc-performance-metrics-25948
Credits F5 whitepaper.
#ActivEdge Technologies #Technology
