Since I haven’t really found any tuning Tyke topic I’m taking the liberty to create one on my own.
I’d like to share my experience with you in setting up Tyk on our VM environment.
I hope some Tips & Tricks are of value for you and you maybe have some of your own to share.
Our current system setup is Redhat Enterprise 7.
- 4 CPU cores
- 2 Gigabytes of RAM
- 8 Gigabytes of Disk (SAN storage)
Monitoring Memory usage CPU and Processes
I’m using HTOP to monitor Memory Usage, CPU load and Process activity:
It gives a clean output and if needed you can easily KILL some processes
Monitoring Disk usage (iowait)
I’m using IOSTAT to check disk load / activity (if there is any).
I have found that the batch-wise processing of calls is very efficient and IO hardly seems an issue.
iostat -x 2 50 to get 50 reports of the iowait (which is the time the Linux kernel get’s stuck whenever you have a lot of Synchronous IO in the queue)
In the example you see a very low IO wait and a relatively high CPU load. (%user)
Whenever you find this number is relatively high try to set some write caching on the SAN or use SSD’s instead of conventional HDD’s
Load / Performance test
On a DIFFERENT server I’m using Apache Benchmark (apache tools) to test the performance of calls.
In above example I’m stressing the API manager with 100.000 calls (cached)
Tuning tips for Memory management and connection limit’s
Make sure to have your
/etc/sysctl.conf look something like this:
vm.overcommit_memory = 1 net.ipv4.tcp_tw_recycle = 1 net.core.somaxconn = 1024 fs.file-max = 80000
It manages giving back memory, memory overload and the number of connections that are per default limited.
Handling large amount of requests local?
I’m setting up the server to be able to handle a lot of internal calls.
In such a case make sure to either:
- Use a DNS server that is running on the API Gateway machine
- Register highly used hosts in the
I ran into a DDOS “alarm” on our HA / Load balanced DNS servers because it was getting a too much requests in a short period of time.
This will result in dropped requests (errors).
Note: I’m not sure how this would reflect to a Discovery service since I do not have experience with that
Start services at boot
If services aren’t started at boot; make sure to enable this
systemctl enable redis.service systemctl enable mongod.service systemctl enable tyk-dashboard.service systemctl enable tyk-pump.service systemctl enable tyk-gateway.service
Thanks for the input, I’ll ask the team @tyk to review and suggest their input too.
You might also find this guide interesting, it deals with some optimisation ideas : https://tyk.io/tyk-documentation/deploy-tyk-premise-production/
Thanks for the tip, I didn’t see that URL yet; I only found something similar in old google references.
I need to run through the rest of the doc’s. There is a lot to work through.
Did you guys ever consider using Nginx for “plain” reverse proxy activity?
They manage to have an amazing response speed in doing that combined with minor load and memory usage.
(Although I think Tyk is coping pretty well in this part)
We’re big fans of Nginx as a proxy. But we prefer to keep Tyk as focused as possible, so avoid dependencies on other stacks where possible.