Apigee’s API Gateway is built on top of a Java code base. And, all of the policies built into the system are pre-compiled Java policies. So, the built in policies have pretty good performance since they are only reading in some cached configuration information and executing natively in the runtime.
Unfortunately, these policies come with two big draw backs:
- In order to do some common tasks (like if x then do y and z) you usually have to use multiple predefined policies chained together. And, those predefined policies are all configured in verbose and cumbersome xml definitions.
- Also, there’s no way to create predefined policies that cover every possible scenario. So, developers will need a way to do things that the original designers never imagined.
For those reasons, there are Javascript Policies which can do anything that javascript can do.
The big drawback with Javascript policies:
- The system has to instantiate a Javascript engine, populate its environment information, run the javascript file, and return the results back to the runtime. This takes time.
So, I was curious how much more time does it take to use a Javascript Policy vs an Assign Message Policy for a very simple task.
It turns out the difference in timing is relatively significant but overall unimportant.
The test used in the comparison checks if a query string parameter exists, and if it does then write it to a header parameter. If the header parameter existed in the first place, then don’t do any of this.
Here are the pseudo-statistical results:
- Average Time Taken (non-scientific measurements, best described as “its about this long”):
- Javascript Policy: ~330,000 nanoseconds (0.33 milliseconds)
- Assign Message Policy: ~50,000 nanoseconds (0.05 milliseonds)
- What you can take away
- A Javascript Policy is about 650% slower or Javascript has about 280,000 nanoseconds overhead for creation, processing and resolution.
- Both Policies take less that 0.5 ms. While the slower performance is relatively significant; in the larger scheme of things, they are both fast.
Javascript Policy
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> | |
<Javascript async="false" continueOnError="false" enabled="true" timeLimit="200" name="merge-query-string-api-key"> | |
<DisplayName>Merge Query String API Key</DisplayName> | |
<Properties/> | |
<ResourceURL>jsc://Merge-Query-String-API-Key.js</ResourceURL> | |
</Javascript> |
/* | |
* Attempts to "merge" (aka. use) the query string parameter 'api-key' | |
* into the header variable api-key if the header variable is missing. | |
* if the header variable exists, then the header variable is always used | |
* and the query string parameter is ignored. | |
*/ | |
var hApiKey = context.getVariable("request.header.api-key") | |
//print("header: " + hApiKey); | |
if(hApiKey === null) { | |
var qsApiKey = context.getVariable("request.queryparam.api-key"); | |
//print("query string: " + qsApiKey); | |
if(qsApiKey !== null) { | |
//print("setting request.header.api-key to '" + qsApiKey + "'"); | |
context.setVariable("request.header.api-key", qsApiKey); | |
} | |
} |
Javascript Timing Results
Assign Message Policy
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> | |
<AssignMessage async="false" continueOnError="false" enabled="true" name="Assign-API-Key-To-Header"> | |
<DisplayName>Assign API Key To Header</DisplayName> | |
<AssignTo createNew="false" transport="http" type="request"/> | |
<Properties/> | |
<Add> | |
<Headers> | |
<Header name="api-key">{request.queryparam.api-key}</Header> | |
</Headers> | |
</Add> | |
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> | |
</AssignMessage> |
Assing Message Timing Results
1 comments:
great
Post a Comment