Rate Limit

[SeaRoth]

I've hit the rate limit a few times over the passed 3 days and was wondering if anyone else is having this issue?

Step by step functions:

1. $api->summonerByNames (imaqtpie)
2. $api->currentGame (imaqtpie summonerId)
3. $api->league (imaqtpie summonerId)
4. $api->stats (imaqtpie summonerId)
5. $api->recentGames (imaqtpie summonerId)
6. $api->summonerById -total summonerIds from rcentGames.fellowPlayers = 90 -max per api call = 40 -max # calls: ceil(90 / 40) = 3 -usually 2 calls because I reduce the overlapping summonerIds
7. $api->recentGames (IWDFridge summonerId) -Most frequently played with person (orange in match history) -Used to calculate per minute deltas and the radar graph
8. $api->matchHistory (imaqtpie summonerId) (the 10th API call)

Notes:

• This is 10 API calls every time I refresh the page depending on revisionDate for said summoner

• I have recently added a 2nd key to riot.api.cache.key

• I have recently removed step 8 since realizing it's potentially the 10th API call

Rate Limit:

Config:

App:

App recentGames:

[d3sd1]

You should cache the data on database or json files, and then reload page by sections unless you've a production key. And more even optimise: $api->summonerByNames (imaqtpie) $api->currentGame $api->league $api->stats $api->recentGames $api->summonerByNames -recentGames summonerId's = 90 -summonerByNames max = 40 -total # calls: ceil(90 / 40) = 3 calls to $api->summonerByNames $api->recentGames (godrjsdnd)

So you can just cache summoners then you don't have to do 4 queries for know their names everytime. Also the page should load by sections, per example: leagues, recent games...

[SeaRoth]

My Mistake:

• The 3 calls to $api->summonerByNames should be $api->summonerById because of the ~90 fellowPlayers from $api->recentGames. (I have edited the original post)

Notes:

1. All data is cached in a Javascript Module, per session
2. The page loads in sections, per example: Step1: summonerByName (imaqtpie) Step2: currentGame & league & stats & recentGames (imaqtpie summonerId) Step3: Three calls to summonerById(fellowPlayers) Step4: recentGames (most frequent opponent summonerId) Step5: matchHistory (imaqtpie summonerId) (the 10th API call, likely causing all this headache)
3. Good suggestion about the Production API Key, I will apply for one since I want to get timeline data and take these graphs and algorithms to the next level

[d3sd1]

All data is cached in a Javascript Module, per session

You should have an internal cache with summonerid - summonername on a database that's on server, not on the user session, so it's harder to reach limit.

[d3sd1]

I'm working on a heavy update btw :]

[SeaRoth]

You should have an internal cache with summonerid - summonername on a database that's on server, not on the user session, so it's harder to reach limit.

1. Data is always cached on the user's computer (console.log of the object below):
2. Ajax communicates with OnLoL-Riot-API
3. Calculations are done in JavaScript because Server CPU & RAM is expensive (php)

Note:

1. Since removing the potential 10th API call in step 8 of the original post ($api->matchHistory) there have been no rate limit issues
2. I look forward to seeing the new update xD & I really appreciate the work you have put into this project

[d3sd1]

Yup, but if you cache this on user's browser, u can't have too many visits sincr you'll break the rate limit, because you have to load massive queries on every pc with the same api key to know summoner usernames, per example. Something that u would not if cached on server

[SeaRoth]

Your project does the caching on the server already though!

[d3sd1]

Yup but this doesn't works as good as mysql. Thats what am I updating, but works :P Forgot ir btw, that's not my day 🙀

[SeaRoth]

Oh it doesn't? I didn't even notice, lol! It just worked so perfect that I had the opportunity to focus on other goals.

I have worked with mysql for years and founds your way of storing all this json data pretty smart. I was actually in the process of making the backend mysql portion for my project when I came across your forum post.

I actually hit the rate limit again which is weird because it's been behaving perfectly for months! I will have to spread out the summoner searches until I get approved for the PROD key or your next update.

[d3sd1]

It works so good on splitted/short queries. If you have to save a timeline per example, it's harder and takes a long time to load all file data (It's like 1.5/3mb, even more) of pure json, which not so good, so I'm working for improving it, with a database or just doing some Bson, chuking 'em and etc.

And btw, the rate limit it's for hours/minutes, check requests per minute. I'll solve it on next update btw, dont worry. And get another key, I mean, with your account, refresh your key so it turns to another, maybe some1 got your key and is doing queries, or maybe rito is bugged.

[d3sd1]

http://prntscr.com/dj2zsu

[d3sd1]

Enjoy version 1.4 bro! Closing this. Hope you give me feedback!