User talk:Garthagk
From EVEDev
Sigos
About the caching problem, I don't know exactly how the API works, but I have a couple little questions:
For general information such as sovereignty and alliances (and any other things you add later on, such as server status, etc), you could set up something like a cron job to generate it once per hour and store it as a static xml file. Obviously, this means that whenever someone looks for the non-authentication-needed, there is no query going on or anything like that and it simply sends a static page. There would be much less overhead on the server to serve this up.
Further, I would assume that any tool that works on the static information like that would not need to be updated every hour (how many alliances are born and die on any given day, and how many sovereignty changes are made). That means that these two things, along with possible other ones, would only have to be generated once per day. This could even be done in about 10 seconds during downtime, meaning that if the server hosting it is going to be hammered at any time, it will be happening at a non-critical time. Assuming 30 minutes for downtime, and saying this will be generated halfway through (again, not sure if this is quite possible), that would leave 15 minutes for all the EVE users that keep computers on all day/happen to be up at that time and have the tool open (I will be generous and say half of the 20,000 you mention, 10,000) to recover one or two static files. Sure, this may not be the greatest, but I would imagine the servers could probably handle this, albeit with some difficulty depending on the connection and server setup.
The tools that would be updated every hour would mostly be things that are unique to individual players, meaning that you could generate this from the game database and cache it however you want (static file if desired, or, most likely, in another database) to serve up on subsequent attempts until a time when the cache is due to be updated and it would regrab it. Sure, this would result in some extra traffic, but it would also allow people to regrab there data if something happens (ie: computer or program crashes while transferring/before processing data).
If you are worried about individuals hammering the servers, you could always log access to the api and suspend people that repeatedly access the same page more than 2-3 times in an hour (or in a day, for some of the other static information) for a set amount of time (most likely 3-6 hours, but perhaps 12-24 hours for those users who cannot learn their lesson). This would allow more flexible use of the api for responsible users while preventing malicious (or STUPID) users from doing any real damage.
Garthagk
In theory I might agree with you. It would be "possible" to set things up in such a way as to prevent catastrophe at the hands of stampeding clients. In fact, I'm pretty sure that the server won't fall over if we get a few tens of thousand of requests at the same time. It will just be very, very slow. (Aside from IIS's own protections, the API .NET application has built in throttling...)
What it comes down to is: there's no need for us to suffer through that. I can't imagine any reason you need to get the data the second it expires. Every reason anybody has ever given me has boiled down to "but I want it now!" Please, just obey the cachedUntil timers and all will be well. Thanks.
Sigos
I see what you mean, I was just wondering those things after I had read what you put in your profile here. For the applications I am working on, the current system is sufficient, though I do not use much character-dependent information like the wallet or journal.
I'll reserver further comment until I look at the api a bit more.
I wish there was an easier way to make decent nested comments...
