When you want to run NetScaler, the question of the right platform quickly arises. Even companies that have been using NetScaler for years are confronted with this question at the latest when the next upgrade is due.
The following hardware platforms are available:
- Citrix NetScaler MPX: NetScaler in hardware, MPX appliances have SSL acceleration chips
- Citrix NetScaler VPX: NetScaler as virtual appliances. VMWare ESXi, KVM, Citrix XenServer, Microsoft HyperV and all common cloud solutions like AWS and Azure are supported.
- Citrix NetScaler SDX: A mixture of NetScaler MPX and VPX. A customised XenServer runs on the MPX hardware, on which the virtual appliances run. The appliances are equipped with SSL acceleration chips for processing.
- Citrix NetScaler BLX: Citrix NetScaler runs within a Linux machine. There are two modes: dedicated mode and shared mode.
- Citrix NetScaler CPX: Citrix NetScaler runs within a Docker environment. Be careful, data may be case sensitive.
While the application of NetScaler CPX should be clear, it is often difficult to decide between the other form factors.
Citrix NetScaler MPX versus Citrix NetScaler SDX:
The decision is relatively easy: SDX has all the advantages of MPX, but it allows more than one Cirtix NetScaler to run on the hardware. As soon as you need more than one pair of NetScalers, you should therefore consider purchasing a Citrix NetScaler SDX. SDX appliances enable better utilisation of purchased bandwidth, and we also need less hardware and resources (power/cooling/space in the data centre). SDX appliances are therefore often cheaper than MPX appliances.
Physical (Citrix NetScaler MPX/SDX) vs. Virtual (Citrix NetScaler VPX/BLX):
Physical appliances have two key advantages:
Predictable and guaranteed data throughput
SSL acceleration in hardware
Data throughput over 100 Gb/s (August 2025: up to 250 Gb/s)
Virtual appliances also offer advantages that should not be overlooked:
High flexibility
Comparatively inexpensive
Short procurement times
Maximum data throughput, depending on the hypervisor: HyperV: 3 Gbt, XenServer: 40 Gbt, ESXi, KVM: 100 Gbt
Comparison between different models (August 2025):
| MPX/SDX 9100 | MPX/SDX 16000 | VPX 1000 | BLX, shared mode | BLX dedicated mode | |
| System throughput (Gbps) | 95 | 250 | max. 100 | max 12 | max 100 |
| L4/L7 HTTP requests/sec | 3,000,000 | 7,500,000 | ? | ? | ? |
| SSL throughput (Gbps) | 55 | 130 | max. 30 | ? | ? |
| SSL transactions/sec (2k key certifcates) | 90,000 | 280,000 | max. 30,000 | ? | ? |
| ECDHE transactions/sec (2k key certifcates) | 39,000 | 125,000 | max. 17,280 | ? | ? |
(source: NetScaler Data Sheet, August 2025)
When looking at this table, it is important to note that the data for VPX and BLX are maximum values that can be achieved under ideal conditions. The actual values depend on the CPU model and utilisation and the available memory of the virtualisation host. Citrix provides very few values for BLX because, unlike VPX, BLX also supports SSL acceleration in hardware. Please refer to the HCL to see which hardware can be used. In contrast, the values for MPX and SDX are guaranteed.
The comparison clearly shows that a NetScaler MPX/SDX can handle a significantly higher number of SSL transactions per second than a NetScaler VPX, whereas the difference in SSL data throughput is negligible. What does this mean?
SSL transactions per second indicates how many new SSL connections can be established per second. In contrast, SSL data throughput indicates how much bandwidth is available within existing SSL connections. It should be noted that the number of SSL connections per second also depends heavily on the certificates used: The figures refer to 2k certificates; for 4k certificates, a decrease to around a quarter must be expected (so think, if you really need 4k certificates!)
Where do SSL transactions play a major role?
We must clearly distinguish between SSL data throughput and transactions. Data throughput depends on the performance of data encryption and decryption. If large amounts of data are transferred, as is the case with streaming media servers or the Citrix Gateway, for example, then data throughput is the limiting factor. If a large number of clients want to transfer small amounts of data, as is the case with normal web servers, then the number of SSL transactions per second is very important.
How can you find out the current utilisation?
In the Reporting Centre, you can create a report that shows the number of SSL transactions. Using the NITRO interface, you can view the two counters ssltransactionsrate and sslecdhetransactionsrate. And, of course, you can use nsconmsg to determine the same counters.
So what should we use?
As I have already written in another article, NetScaler SSL acceleration hardware generally does not support Poly-Chacha encryption methods. If these are enforced, SSL communication runs via the Intel CPUs and not via the SSL acceleration chips. However, unlike common browsers, the Citrix Workspace app does not support Poly-Chachas either.
For applications such as Citrix Gateway or streaming servers, I would recommend a VPX or CPX as long as the SSL bandwidth does not exceed the limits, because the number of new SSL connections per second is rather low, even with large gateways. In contrast, I would definitely prefer SDX/MPX for large web servers, because the limiting factor there is primarily the number of SSL transactions per second.
If the decision is close, you could also consider switching to TLS 1.3 and HTTP 2.0. Unlike HTTP 1.1, which establishes up to 16 TCP connections (and therefore also SSL connections), HTTP 2.0 uses only a single TCP connection and is thus significantly more efficient. However, TLS 1.3 is also more efficient with HTTP 1.1 because it has a more elegant connection setup and can establish additional connections to the same client in a more resource-efficient manner. This may allow a VPX to be used where older technologies would only have allowed an SDX/MPX.
