The 100 limit was set as an absolute maximum, it wasn't the recommended amount for scripts to try and hit. Your scripts shouldn't really be making calls any more than once every 10 seconds (and that's in the most extreme case). API systems aren't intended for you to get live data to the second - it's highly unnecessary.
The CityWatch uses a custom API (specifically tuned to get only the data required) refreshes once every 10 seconds, and that's plenty. Anything more than that is basically DDoSing the servers.
If things continue the way they are, I expect we'll be reducing the maximum calls to 10-25 per minute. We're surviving for now, but as more people start using it (especially when our official mobile app comes out), I expect we will have to make sacrifices.
I mean, I love that you created an API, but I'd appreciate some info on what the server is going through.
Even if 3000 users were making 100 calls/min, that'd still leave you with mere 5k req/s-- by today's standards, not at all a high number. Am I that underestimating the number of users so much?
Perhaps you meant to limit the API by entities read instead of calls? There are tools requesting the full messages and events list every time, that way they save some calls. Mine gets a list of finished education courses because 'education' is not in the cooldowns.
Or, add a filtering system? Or, a delta mechanism? Or, a websocket connection that pushes changes or simply notify "there are changes?"
I'm not saying you shouldn't reduce the rate limits, that's totally your call. I'm just surprised you gave people a hammer and didn't expect to get hammered.
I imagine with the release of the API you were expecting more scripts that do one-time calls and work, versus things that do try to provide live info which of course need to make calls more frequently.
My most recent release can be turned down to update every 10 seconds, which I'm sure some people are okay with. But some people seem to like the quick information at their finger tips.
The tools and scripts that can be made with the API are endless and I think I speak for all of us here that we want to work with you, not against you. I think the 100 calls a minute is a happy place and players can easily run a handful of scripts simultaneously if they want. IBF and I were discussing things when it dropped to 50, it got a little crowded and players were running in to errors.
I was hoping there was a way to do this earlier on too. I'm requesting a lot of things I just don't need, but I do need other stuff in the call, so I get a lot more data then a I need.
Here's 2 idea I had:
For things like messages and events, accept a number, and the API call would only return the most recent X messages/events. So with a selection of messages:1,events:2 it would give the most recent message and the 2 most recent events.
Next, allow the selection to drill-down in a similar way by selecting a feild or group from within the selection. So a selection of profile:rank would just return that one piece of information, or profile:life would return that little group of the life information.
5,000 requests per second is an absolute crap-ton. Right now, our main database server currently has 5,880,000 (SELECT) per hour.
If you give users the '1 second refresh' option, yes they probably are going to choose it because it probably seems very slightly better for them. They're always going to choose the best option for them, even if it's only fractionally better.
As a developer using the API system it's up to you to be sensible, respect the servers, and set limits for the people using the scripts. The only way we can intervene is by hard-limiting each user by changing allowed requests (which we will do as soon as it starts effecting the servers).
I'm sorry, but 5.000 requests are nothing... Especially since the API is a highly cache-able endpoint (if done correctly).
Your response leads me to think you're not exactly interested in that, as if it was already super optimized. I don't think a high number of selects is anything to be proud of. In fact, we developers always strive to reduce them. Torn is generating around 1600 selects/user/hour-- how much of that could be cached?
Don't worry, I've already added a limit to DoctorN so users can't select 1s. I would heavily cache it if I could, but unfortunately that's up to Torn.
But "if you give users the 1 second refresh option, yes they probably are going to choose it" can be said right back to you about the API. That's why I don't get why you jump to compare us negligent developers to DDoSers. If that's your perspective, you should in fact hard-limit the API. That's certainly easier, safer and cheaper.
This is what I've been trying to tell some others on here, having a script update so frequently not only adds load, but it's just not needed. I originally had a 1 second option in Torn Tools but warned users if the selected it. The current minimum is 2 seconds, simply as I'm trying to provide near-real-time information, but in future releases I'll again raise the limit for performance sake.
I'm not following you when you say it's cacheable. You mean on Torn's end, or our end?
With each API query I make I create a local array of data. If a new piece of information is pulled from the API it's added to the array, or if the already exists, it updates. This way I'm able to manipulate that information any time I want without making an API call every time. So, I assume this is what you're talking about?
But, even with that method, the only way to get updated information is to make a new API call.
I've reduced my calls some and I'm working in some things to further limit load - such as not getting the player's education status while they're travelling, because nothing could effect it while travelling anyway.
Even with the most rudimentary cache invalidation strategy, the API could return 'not modified's for the vast majority of calls. I'm talking -very- rudimentary, in-memory-"any field related to the user was modified"-boolean level.
In ideal world - yes. But Torn is old and very complicated system. Building even a simple proper caching mechanics for all requests types may require a lot of development hours, this is a good thing of course, but we have a strict development schedule - many important gameplay update can't wait because of this I afraid.
Also, most requests returns many different fields and there is a huge probability, that this fields will be already not up-to-date during next request. This should be investigated first, but I afraid that it will be like that.
Current API system was designed as a simple alternative to citywatch to allow you to build your own clients. Of course it can be used to gather some statistics, but not to track everything in the live mode. 100 requests per minute should be actually enough for most tasks I believe, not sure, for what you need 5000?
I don't need 5000-- that was just the example about how many requests 3000 users would generate at 100 calls/minute. 100 is indeed more than enough for most tasks, no objection there.