Impact of Proxy chaining with overall TPS

[6493]

All - I would be interested in understanding the impact of Proxy chaining on the overall TPS. For ex. if every API request have an associated proxy chaining call, do we need to take this into account and will this reduce the overall TPS into half. Kindly advise 

[dchiesa1]

if every API request have an associated proxy chaining call, ... will this reduce the overall TPS into half

In general, no. Your instinct is correct, that if you have configured Apigee so that each inbound API call results in another "chained" call to another proxy, then Apigee is doing 2x the work. But, for several reasons, the conclusion you suggested - that the TPS (transactions per second) would be cut in half -- is unlikely.

1. First, Apigee (at least the SaaS versions) is designed to auto-scale, which means you do not need to worry about TPS and capacity. If there is increased load on the system, then the Apigee SaaS will dedicate more resources and your system will continue to run at the same request rate.
2. Second, Apigee systems often do not run at their limits. If you are running 10 or 100 or even 1000 tps today, there is probably enough "headroom" in the resources available to you, to handle the additional load that is implied with a "proxy chaining" approach. There's enough room in the CPU, memory, and I/O to handle the additional load.
3. finally, In general, in my experience, Apigee SaaS won't be the bottleneck in a high-performance distributed system. Apigee is a proxy, and sits "in front of" an upstream system. The performance of that upstream system is typically the dominant factor in determining overall system throughput (TPS). Apigee proxies, if well designed, can complete their work in 2-8ms. A Typical upstream system consumes something like 150-280 ms. As a result, it does not matter if the Apigee proxy consumes 10ms or 12ms. The overall throughput is still determined by the upstream system.

As alway though, with the performance of distributed systems, projected performance numbers are unreliable. There are simply too many variables, too many unknowns to predict performance characteristics with any degree of confidence. You will need to test and observe the performance on your own system.

[100714]

@dchiesa1 -Thanks for the detailed reply. I understand the autoscaling component with SaaS/Hybrid, but what would be the impact on an OPDK platform.

[dchiesa1]

Some customers have set up auto-scaling of MPs in their OPDK environments, but that's rare. So the first point won't apply.  But point 2 and 3 would still apply. 

Anyway points 1, 2, an 3 are all part of a mostly academic discussion.  You won't know how it performs until you take some empirical measurements. You could benchmark the system and compare the chained-proxy approach vs the single-proxy approach. 

Question for you: why are you chaining proxies? What problem are you solving with that architectural decision? 

[100714]

 For message logging, we have a typical framework of Flowhooks --> Sharedflow--> MessageLoggingPolicy-->Loggly. We require to dynamically configure the log servers host and port (across environments) which is not possible via MessageLogging policy, we have configured an API proxy with Loggly host/port configured as targetendpoint which is called from the Shared flow. The revised flow being Flowhooks --> Sharedflow--> MessageLoggingPolicy-->API proxy -->Loggly. Our concern is on the API proxy calls from the Shared flow on every API call.

Thanks again @dchiesa1.

[dchiesa1]

yes, I'd be concerned about that too.  Unfortunately the FlowHook mechanism does not extend to the PostClientFlow, so any logging you do within the context of a flowhook is going to incur some latency that is observable by the original client. 

If you attach a MessageLogging policy in every proxy in the PostClientFlow, you can avoid this. Alternatively, If you attach a ServiceCallout to every proxy in the PostClientFlow, then you can avoid the latency. But the downside is you have duplicated configuration.  (copy pasta). 

There is an outstanding feature to add a FlowHook for PostClientFlow.  (ref b/174472894)  For now, copypasta is the way to get standardized, fast logging.