There is no way to objectively determine that.
The best suggestion is to test it yourself, using an environment and condition that as closely as possible mirrors your production system.
"Mirrors" means the same payload sizes, the same request rate, the same "think time" on the backend, the same Apigee policy configuration, the same VMs, same memory and cpu and network configuration, and so on.
Having said that, I can offer some comments. If Apigee is not doing anything computationally intense, the most demanding part of your workload will be the network I/O. Specifically, pushing 6 MB into Apigee, then 6MB out of Apigee and into the target backend system.
Suppose you have a network with a full (not virtualized or oversubscribed) capacity of 10Gbps. That equates to 1.25 GB/s, in terms of bytes. Figuring an overhead of about 20-25% for HTTP, that puts you at a maximum of 1GB/s. For a 6 MB request payload, that gives you a theoretical max throughput of 170 TPS. In practice, the actual throughput will probably be less than that because of
- the response payload
- the think time of the backend, which causes buffering in Apigee
- contention due to concurrency
If you are observing 80TPS, which is about half of 170, that means you are exploiting about half of the theoretical 10Gbps network, or 5 Gbps of network.
But wait! That considers only the traffic from Apigee to the target system. If you also consider the traffic sent from the client to Apigee, that is another ~5 Gbps of network, which means at 80 TPS, for the size of the payload you described, you're probably utilizing 10 Gbps of network capacity. If the same network port is used for client-to-apigee and apigee-to-target, then your benchmark is network constrained.
To confirm this, check the cpu and memory usage on the Apigee nodes - you'll see they will be low, 20-25% *maybe*. Or lower. That indicates the overall system is constrained by the ability of the network to carry data.
Good luck on your benchmarking!
LinkedIn
Twitter
