Public CREST Rate Limits
I began writing this intro with "Hey developers" and then my mind starting thinking about DEVELOPERS DEVELOPERS DEVELOPERS! After smashing my face into the desk in an attempt to forget that reference I was unable to come up with a new introduction.
Public CREST Caching
Before we talk about the rate limit on public CREST lets talk about some caching. I wrote a dev blog recently talking about some changes we made to the caching for public CREST. Both those changes were made to the NGINX config, one was simply bumping the cache size and the other was prep work for a change that went out in Phoebe.
Up until Phoebe we could only ever specify a cache time in seconds for CREST and this was done via a decorator in Python. This meant that all calls to that resource always got the same cache time. It meant that if we wanted to cache something like say the market history we would generally set its cache to 1 hour. The unfortunate thing is that the market history data doesn't change during the day. It only changes at midnight UTC. So the same data was often being refetched throughout the day because the 1 hour cache expired. We couldn't just set the cache to be 24 hours though because if someone grabbed something at 2AM for the first time, it wouldn't be available until 2AM the next day. That's no good.
So on the backend for CREST we added the ability for developers to pass functions into the cache decorator, and then when the resource was called we could calculate a time in seconds to cache. So for things like the market history this means that we can pass in a function like CalculateSecondsUntilMidnight, and no matter when during the day that resource is called it will cache until midnight.
These changes to the CREST backend were deployed with Phoebe and have made a huge difference in the number of cache hits we get which is always nice to see as a developer. And because I know how much you guys like graphs, here is a graph of the cache hits for all HTTP200 requests on public CREST:
The biggest change is in the Expire cache status. Those expires came mostly from the market history resource getting requested at 01:00, and then again much later in the day after the cache had expired. With the cache now lasting until midnight, that is much less an issue.
New Rate Limits
With the improved caching and continued monitoring of public CREST we decided to increase its rate limit. I have posted the new rate limits on the Public CREST page over on the Developers site as these changes are live on TQ now. For quick reference though they are now as follows:
- Rate Per Second: 30
- Burst Size: 100
Hope this makes your life a bit easier, better, and helps allow you guys do more cool stuff! :D
Team Size Matters
p.s. that graph so didn't take 3 devs 30-40 minutes learning R to create... I swear.