Apigee Edge is designed to not have any bottlenecks. Even so, depending on what you do in your API Proxies, Apigee Edge could slow things down. For example if you are performing multiple public/private key encryption decryption or signature operations, all of that could result in 200ms or more delay, which could slow things down when run at high concurrency.
But most customers don't do that. Most customer scenarios call for API proxies that perform a few simple steps - like verifying a token or an API key, enforcing some rate limiting, extracting some data. This will take 10-13ms or less, depending on your system. The most common cause of a bottleneck is a slow backend system.
You will need a backend system that supports the load you expect to serve. If the backend system exhibits 30s response time, at load, then it makes it difficult to handle high loads. If the backend is pretty fast, then it's easier.
There are no fixed and easy answers for determining latency or maximum throughput. Too many variables. The best way to determine that is to measure it - and by that I mean run realistic load tests for your particular scenario, and see what you get.
Start with the recommended basic configurations. (In the installation documents for the on-premises software, there are recommended basic configurations.) Measure against those, and see what works.
But it's possible that you won't need to worry about it. If you're driving 5000 tps, then you probably need to measure and plan. If you're driving 800tps sustained and the payloads are 10mb, then you need to measure and plan. On the other hand, if you're driving 100tps and your payloads are 10kb, then a single 2x4 or 4x8 gateway node will be sufficient. The network is usually the bottleneck: the data you pass through the Edge proxy will consume the network capacity before CPU or memory is exhausted. If this happens you need to expand your network from 1 Gbps to 10 Gbps or add NICs or nodes.
Most customers in my experience need redundancy in the Apigee Edge deployment for the reliability, not for the scale.
LinkedIn
Twitter
