Nova ADC performance is dependant on the hardware, VM, or container performance where it has been deployed. There are also minimum requirements for the full set of functionality, and a minimum amount of access required.
In order to control your new Nova Node via the Cloud it must be able to access poll.nova-adc.com on port 443. We don't require any direct access to it, or any inbound firewall rules - just outbound port 443, and DNS to do the lookup.
When you later launch ADCs you must of course ensure the ports you use are accessible (e.g. port 80 and 443) for your clients.
Nova ADC has three primary components to performance:
We recommend 2 CPUs and 2GB of memory as the minimum spec for a production Node. We have a guideline below on recommended specs:
Typically if you have less than 10,000 clients, or under 1,000 RPS you do not need to consider performance per Node. An individual Node can be configured to handle 50-80Gbps of traffic and up to 120,000 requests per second (L7) or 20,000 SSL TPS in the right configurations and with the right virtual machines.
By far the most costly activity on Nova ADC is the WAF. It has to scan and process the entire content of every request, making it 10-20x slower than the ADC without WAF. In high performance environments it is a good idea to run naked ADCs that are configured for performance, with WAF separated from the task. Alternatively, you can scale out (even using an autoscaler) to handle the increased load.
Nova ADC is a modern system, designed to function in a non-monolithic nature. When scaling Nova ADC (and next-gen infrastructure in general) you want to spread the load. An ADC per micro-service is much more performant and reliable than one massive north-south ADC at the ingress to your infrastructure.
We also recommend scaling-out versus scaling-up. This means running multiple (potentially autoscaling) Nodes that are of a medium size versus one that is extremely highly spec'd. Containers and VMs perform best at around 4 CPUs with 4-8GB of memory in our tests. It's often wiser to run 2 or more in an active configuration.
RPS (requests per second) and TPS (transactions per second) are a measurement of how many Layer 7 requests and SSL accelerated requests the ADC is handling per second. This is an excellent way to spec performance, but can be harder to estimate in an environment. Generally speaking, you can multiple RPS/TPS by 3 to get an idea of how many active users it could handle.
For example, on a webserver deployment lets suggest we have a Large deployment, handling 50,000 HTTP requests per second. This would likely be around (3 x 50,000) = 150,000 active users on the website.