Many developers hope to thoroughly understand how the API works and how to improve their business by caching API requests, but when this requirement enters the implementation stage, many people will find that there are no suitable tools and methods at hand, so We will give you a comprehensive explanation today:
① Several different API cache implementation methods
② The advantages and disadvantages of the above methods and how to formulate the most suitable caching strategy for each API
First of all, we want to make an important conclusion: After testing according to the method described below, Akamai found that through proper caching technology, the delivery speed of API can be improved by 21% .
Establishment of test methods and baselines——Taking cats as an example
We'll create requests against the sample API using a load testing and benchmarking tool called Siege. Siege's running interface is similar to the following figure, which lists the responses of all requests initiated for a specific URL:
In subsequent tests, we used a NodeJS API with a MongoDB backend, which is a basic Express-based API that returns data on kittens available for adoption. After all, everyone loves cats, right? The content of this API is as follows:
We'll test this with a simple GET request that returns a 6.59 KB JSON response with 227 lines, all of which is data about adoptable kittens:
The header data returned by running the GET command is as follows. Note that the connection to the server will continue uninterrupted, and we will use GZIP to reduce the payload size:
In the first test, we ran Siege from a local machine with 5 concurrent users in 5 minutes, and the Express server handling the requests was also running locally, that is, no network communication was involved at all. This is to rule out all possible interferences related to the network and establish an accurate baseline. We run Siege for 5 minutes and simulate 5 concurrent users making GET requests with the following command:
$ siege -c 5 –time=5m –content-type “application/json” GET http://localhost:3000/cats
The results of the first run are as follows, including the number of (transaction) hits, how long the test was run for, the amount of data transferred by the test, the transaction rate, and the number of successful and failed transactions:
These data will be used as a baseline for subsequent testing and comparisons.
Tests and results for different scenarios
First introduce application-level caching. We'll add a simple in-memory response cache to this application using the apicache NPM package. After adding the package (running the "npm install apicache" command), add the following configuration lines to enable the package:
Then test again and run "get_all_cats". Please note that the previously used command has been commented out, the newly run command uses apicache, and will cache the response for 5 minutes through the instruction:
In the different tests below, as the cache is enabled and disabled, we will use one of the above commands respectively, and restart the NodeJS server to clear the residual data in the memory that may affect the test results. If a request is made to the server and "cache-control" is included in the response, it means that this is a cached response. The max-age value of this header has been set to 300 seconds (i.e. 5 minutes specified in the application):
In addition, you can also turn on the debug mode of the apicache module to confirm whether the module is running normally:
As you can see from the figure above, the first request took 31 milliseconds to return the data to the client, but the time required for subsequent requests has been greatly reduced. Because the first request is a complete request, all subsequent requests are served from the in-memory cache and therefore return to the client in less than 0.5 milliseconds. This is the core advantage of caching.
Next, run the exact same Siege command as above again to see how the results differ after using the application-level cache:
$ siege -c 5 –time=5m –content-type “application/json” GET http://localhost:3000/cats
See it! Application-level caching alone has such a big effect. In the same five minutes, the number of hits increased by 60% after caching was enabled. Although the amount of data transmission is also more, the number of transactions processed per second is as high as 449, which was only 179 per second at the beginning, which is also increased by 60%! Who doesn't like the benefits of just setting up caching for an API?
Then take network factors into account. For the sake of testing and demonstration, I set up a Droplet server with 1GB memory, 1 virtual processor, and a 25GB SSD hard disk in the Digital Ocean New York data center. This is the virtual machine with the lowest hardware configuration that Digital Ocean can provide, and we chose this configuration specifically to test the effect of API caching under the condition of limited hardware performance. Deploy the NodeJS cats API mentioned above to the Droplet server, and use Nginx as a proxy on the front end to send requests from port 80 to port 3000 of NodeJS. There is also a MongoDB instance running locally as the backend for the API. Also no other software is running on the server.
Make a request to the server and check the returned response header, as shown in the figure below, from which you can see that the word "Nginx" means that this test was not performed on this machine:
Next run the same Siege command again (using the IP address) against the Digital Ocean server:
$ siege -c 5 –time=5m –content-type “application/json” GET http://206.81.0.14/cats
Here are the results of running Siege against a Digital Ocean VPS without caching API responses:
Running on the local machine and running on the IaaS platform, the results of the two comparisons have the following differences:
◆ The number of hits and transactions has been reduced by 35%
◆ Transactions that fail for the first time
A 35% reduction is already a serious result, but considering that this is the result of running on a multi-tenant cloud platform, it does not seem so surprising. So for this scene of Digital Ocean, how much effect can enabling apicache produce? Enable the API cache according to the method listed above, and then to confirm that the cache is enabled, send an API request to the Digital Ocean server again, and check the response content as follows:
It can be seen that the header contains "cache-control", which means that the cache has been successfully enabled, and the cache lifetime is 5 minutes (300 seconds). Then run the same Siege command again against the Digital Ocean server:
$ siege -c 5 –time=5m –content-type “application/json” GET http://206.81.0.14/
Wow! This time, after enabling the cache, the number of transactions processed within 5 minutes increased by 4,932, and the processing speed increased by 21% (from 63 transactions per second to 80 transactions per second). Since the server does not need to regenerate the response every time, more data can be served in the same time. This result perfectly illustrates the value of caching API responses.
Finally, in order to make it easier for everyone to compare, we will put the results of the above tests together. Do you see the value of API caching?
↑↑↑Tested locally, no cache ↑↑↑
↑↑↑Tested on this machine, with cache ↑↑↑
↑↑↑Network test, no cache ↑↑↑