Both existing and prospective users of the Oracle API Platform often ask about how Oracle API Platform performs.
What they're really asking is "How long will it take from when my client invokes an API (via the Gateway) to when they will get a response?"
And the answer is... "It depends".
That seemingly unhelpful answer is precisely why this blog exists.
Let's consider this very simple view of what happens when some client invokes an API using Oracle API Platform.
The client invokes a RESTful API via a load balancer. The load balancer determines the appropriate gateway to use. The gateway processes / implements Policies according to the developer's specification.
The Service Endpoint is invoked and, if all goes well, a response is routed precisely in reverse of the original invocation.
Let's have a little algebra to represent the total time that this entire round trip will take:-
T0 * 2 + T1 * 2 + T2 * 2 + T3 * 2 + T4 * 2 + T5
Where Tn is the real time spent in each step indicated in the diagram.
T3 is the time spent in gateway processing (common overheads) plus Policy processing in both the request and response pipelines. Note that the time spent in the request and response pipelines could vary considerably depending on the developer's needs.
We would always hope that T values 0, 1, 2 & 4 are negligible but they do need to be borne in mind.
I have empirical evidence that most standard Policies provided in API Platform exert a negligible overhead on throughput.
What's that you say? "Most?". Well, I can't say "All" because there are two Policies whose performance is outside of the control of the gateway itself - and they are "Service Callout" and "Groovy Script".
The overhead of invoking an external endpoint with the Service Callout Policy is made up of two parts. The internal management of the invocation and the time taken for the external endpoint to execute its work. The first of these two components runs extremely quickly (and asynchronously) but, obviously, the platform has no knowledge or control over the endpoint being invoked. Thus one could have a situation where the user of the platform perceives poor performance when, in fact, the delay is due to an external endpoint executing more slowly than the customer would hope.
A Groovy Policy contains custom Groovy/Java code that is pre-compiled for execution into Java. Simple operations such as getting or setting headers in Groovy will execute very quickly. However, what if the developer needs to programmatically work through a large and complex payload for the purposes of validation? How big is the payload? How many loops will the code execute? How efficient is the code (in terms of how well it was written)? There are many potential scenarios that one could contrive to demonstrate that, depending on the circumstances, a Groovy Policy implementation could run in minimal or sub-optimal real time.
For the sake of completeness we also need to consider the Rate Limiting and Throttling Policies. These will potentially slow the response from the client's perspective. However, that is fairly obviously by design - that's precisely what they're supposed to do when the configured criteria are met. If the execution frequency of an API that has either of these Policies configured is not being constrained (i.e. neither Rate Limiting nor Throttling is "in play") then the processing overhead is extremely low.
Some security policies will inevitably need to make an external reference to an Identity Management platform. Any additional overhead incurred here can be thought of as being similar to a Service Callout.
Providing that the user has no inefficient Groovy or Service Callout Policies and assuming that the time spent in each element in the network is negligible, then the time that needs most consideration is usually T5 - i.e. the time spent in the ultimate Service Endpoint. There are occasions when T4+T5 is extremely brief and thus the platform could be adding a small overhead to the total round-trip time. However, the benefits offered by the platform typically outweigh any such concerns.