Putting Tyk Through its Paces
The Tyk Open Source API Gateway is performant and efficient, and we’re not shy to put numbers where our mouths are. We load test every release of Tyk both with canary build on Tyk Cloud, and pre-release with blitz.io rush tests, here are some of the results.
For those who just want the highlights:
- Tyk can easily proxy ~2,000 requests per second with sub-30ms latency, with a pretty flat performance curve
- Under load, doing full key validation, security checks, quota management, and analytics gathering, Tyk can handle~1,500 requests per second with sub 50ms latency
- All of this on a $20 p/m commodity virtual server
If you want to see all the pretty graphs, the full results and analysis continue below…
A Vanilla Test
All of the following results are from rush tests that ran from zero to two thousand users within two minutes. Our gateway was set up with an external Redis database, a gateway server and a target host. All three servers were 2-core, 2GB RAM servers from digital ocean, servers that cost about $20 a month to run.
So, lets start with a vanilla test – this is the kind of test that you will find elsewhere – and is what most providers will publish, this first test is Tyk 2.0 running an open API (no authentication), but only recording analytics data.
Basically, this test shows us how well Tyk proxies a request doing very little work:
So here we can see, Tyk drops no requests, produces no errors and keeps a nice steady pace between <10ms to ~30ms latency all the way up to ~2,000 requests per second.
At this point, Tyk is still recording a bunch of analytics data that is being stored in Redis.
What does it mean?
Tyk is a pretty performant proxy – and it’s adding very little overhead to the requests, keeping performance steady and ensuring that requests get through without causing a fuss. But most importantly, even when Tyk is doing nothing it is still doing work, it’s recording analytics.
A Real Test
Now let’s look at a real test, with Tyk actually doing some of the activities you would expect from an API gateway, under some decent load, with a representative number of client tokens. The activities we are evaluating here are on a closed API, and we want to see the gateway:
- Recording analytics
- Validating each inbound request against access control
- Checking each request against a quota
- Checking each request against a rate limit
This is a pretty standard expectation of an API gateway, in fact, it’s a very traditional use case. We set this test up to use 30 API tokens and hit the same API as before (same response payload), ramping up from 0 to 2000 users as we did before:
Now that’s a different picture! Here we can see that Tyk is really working hard, in fact, in contrast to the vanilla test, we can see some strain..
Most importantly, we can see that Tyk is performing swimmingly (remember, this is a $20 server!), in this test we expect there to be resource limitations to be hit, and for the node to start tweaking out during higher load. Given these expectations, here we can see that:
- Latency remains smooth and under 30ms until about 1,300 requests per second
- Stays under 100ms up until 1,500 requests per second
This test had to do a lot more work, for each request, Tyk evaluated the inbound token for its access rights, checked its quota, checked its rate limit was still acceptable and then proxied the request. It then recorded the analytics of the request and response and stored that in the database. All of that in under 30ms on cheap commodity hardware.