Geregistreerd: vrijdag 22 september 2006
Berichten: 2973
Desondanks de "belofte" dat men spaarzaam met de API om zal gaan, caching toe zal passen en niet onnodig gaat hameren hebben we helaas moeten constateren dat ontwikkelaars te makkelijk met de API om gaan.
Sommige applicaties - ik zal geen namen noemen - maken vele verbindingen per seconde of vragen regelmatig informatie op die ze al gecached hadden moeten hebben.
Het mogen dan maar korte/simpele calls zijn, het is wel een verspilling van resources en bandbreedte van zowel ons als de gebruiker van de applicatie.
De API is en blijft een secundaire dienst voor de website, maar het aantal aanvragen wat we per dag verwerken van sommige applicaties is echt schokkend.
De website heeft dan tenminste nog advertenties om de immer stijgende kosten enigszins te kunnen dekken, maar de API heeft dat niet en wordt daarnaast ook nog eens veel gebruikt door mensen die geen eens een account op de site hebben en daarom ook niet investeren in de community als een geheel.
De #1 grootverbruiker (wederom: geen namen) heeft op het moment van schrijven in totaal 14.640.063 API calls gedaan in een periode van een paar maanden tijd en dat aantal stijgt per minuut met zo'n ~200+ requests.
Op een gegeven moment moeten een lijn trekken om hier iets tegen te doen. We kunnen heel drastisch de API gaan beperken tot bepaalde gebruikers of tot apps van onszelf, of wat beperkingen op leggen.
Een aantal opties:
Beperken van aantal API calls per IP per seconde. Dit omdat sommige apps regelmatig 10+ connecties per seconden maken.
Beperken van aantal API calls per IP per uur/dag. Dit om te voorkomen dat men om de haverklap dezelfde requests gaat doen
API keys van asociale applicaties (tijdelijk) suspenden tot het probleem is verholpen
Limiteren van dure API calls per uur/dag (zoals FindShowByName)
Afstraffen van repeated requests in een kort timeframe, zoals 6x in 2 minuten de Show ID op gaan zoeken terwijl je dat prima kan (session)cachen.
Opleggen van bandbreedtebeperking voor dure API calls
Opleggen van bandbreedtebeperking voor alle API calls
Bovenstaande is een greep uit de mogelijkheden welke zelfstandig of gecombineerd doorgevoerd kunnen worden. Alles heeft natuurlijk z'n voor- en nadelen, waarbij sommige wijzigingen vereisen aan de API clients om er voor te zorgen dat deze er goed mee om gaan.
Maar ja, als men die wijziging nu wel ineens kan toepassen kan je toch ook er voor zorgen dat je niet 10+ connecties per seconde maakt of herhaaldelijk dezelfde calls doet voor gegevens die je gewoon moet cachen.
Misschien hebben jullie nog een betere oplossing. Developers aanspreken is in het verleden al gedaan, maar helaas zijn de oplossingen die deze hebben ingevoerd blijkbaar nog niet afdoende.
Sypher wijzigde dit bericht op 18-10-2012 om 19:45, totaal 2 keer bewerkt
Geregistreerd: zaterdag 21 november 2009
Berichten: 26
Hallo, kan het zijn dat de limieten nog niet goed werken?
Ik start net mijn Mediaportal op met de Subtitledownloader plugin en krijg bij de eerste poging een 429 error dat ik mijn quota reeds overschreden zou hebben.
Geregistreerd: maandag 11 januari 2010
Berichten: 6
Beste heren,
Hier ook een MediaPortal gebruiker en inderdaad lijkt het ophalen van de ondertitels niet meer te werken met de Subtitle Downloader. Kan het zijn dat de subtitles via een extern IP worden opgehaald en niet met het IP van de gebruiker (die van mij dus), waardoor alle duizenden gebruikers via het zelfde IP adres requests maken naar jullie API?
Geregistreerd: maandag 11 januari 2010
Berichten: 6
Ik denk dat ik weet waarom het niet werkt. Er worden snel achterelkaar 2 requests gemaakt:
1st:http://api.bierdopje.com/XXXXXXXXXXX/FindShowByName/revolution
2nd:http://api.bierdopje.com/XXXXXXXXXXX/GetAllSubsFor/16464/1/1/nl
Aangezien er slechts 1 request per seconde gedaan mag worden, gaat dit niet werken..
Sypher wijzigde dit bericht op 18-10-2012 om 06:40, totaal 1 keer bewerkt
Geregistreerd: vrijdag 22 september 2006
Berichten: 2973
Er is een limiet van 1 per seconde, als er meer gedaan worden worden die inderdaad geweigerd.
Ook al zetten we dit op 2, de kans bestaat dat applicaties alsnog gaan hameren want sommigen maken 2..3..4...5...6 requests per seconde en dat is nu juist wat we willen voorkomen.
Het per-seconde limiet zou weg kunnen, maar dat kan vervolgens ook resulteren in dat je binnen een paar minuten al door je dag-limiet heen bent. Of dat wenselijk is?
Sypher wijzigde dit bericht op 18-10-2012 om 07:24, totaal 1 keer bewerkt
Geregistreerd: zaterdag 11 september 2010
Berichten: 2
Ik gebruik Subliminal op m'n NAS en, als die niets gevonden heeft, de subtitle plugin voor XBMC. Ik weet niet welke addons verantwoordelijk zijn voor het hameren, maar is er iets wat ik aan mijn kant kan doen om het tegen te gaan? Of andere dingen die ik in kan stellen?
Subliminal staat ingesteld op 1 x per dag zoeken, maar die scant bijvoorbeeld wel mijn hele "series" map. Is dat teveel?
Graag tips over hoe ik jullie hierbij van dienst kan zijn.
Dat is lastig te zeggen. Als applicaties inefficiënt geschreven zijn kunnen ze onnodige API calls doen (zoals het opvragen van het show ID, terwijl deze statisch is en prima lokaal bewaard kan worden) kan je op die manier snel door je dag-limiet heen zijn.
Het is aan de ontwikkelaars om er voor te zorgen dat hun applicatie een nette API consument is en goed omgaat met de nieuwe 429 melding (en sowieso met alle niet-200 meldingen omdat dat handiger is voor iedereen).
Als eindgebruiker kan je daar wat aan doen, door de developer - zover deze er nog niet vanaf weet - te vragen om er voor te zorgen dat deze de applicatie aanpast zodat deze beter met de API om gaat.
continu doet is dat wel een zware belasting op de api (ergens anders gelezen) dus vermoedelijk zal de dev van de plugin de caching moeten gaan inregelen
en tot die tijd een seconde pauze houden tussen de requests
Geregistreerd: maandag 05 maart 2012
Berichten: 10
Is die 1 request per seconde niet een beetje onrealistisch? Als Subliminal gebruiker (zullen er zeker wel veel meer zijn) kan dat nooit. Of elke Subliminal gebruiker moet zich bij Bierdopje als aparte developer registreren en een eigen API key gaan gebruiken.
Suits, White Collar, Person of Interest, The Walking Dead
Geregistreerd: donderdag 24 januari 2008
Berichten: 160
Quote:
Ultimation schreef op donderdag 18 oktober 2012 @ 13:00:
Is die 1 request per seconde niet een beetje onrealistisch? Als Subliminal gebruiker (zullen er zeker wel veel meer zijn) kan dat nooit. Of elke Subliminal gebruiker moet zich bij Bierdopje als aparte developer registreren en een eigen API key gaan gebruiken.
Het limit is niet gebaseerd op de API key maar op het IP adres van de eindgebruiker. Je zal geen last hebben van calls van andere gebruikers.
Geregistreerd: dinsdag 20 juli 2010
Berichten: 985
Zelf gebruik ik er helemaal niks van, maar was het niet handiger om dit eerst even op de homepage te plaatsen voordat er meteen een lock op wordt gezet? Nu hebben de developers geen tijd meer om het aan te passen.
From what I'm looking here is that there is and never has been a way to search subtitles by making a single query like Search(showname, seasonnumber, episodenumber). Then they wonder why there are so many requests to their API? Suggesting "caching" as a solution for every single client that uses the API is not the right way.
EDIT: Since there seems to be Dutch users here it would be nice if someone would try to explain this on Bierdopje forum thread. I honestly think that the API needs changes, not restrictions.
Dus hij vind dat het jullie schuld is dat er zoveel requests worden gemaakt, omdat jullie geen mogelijkheid bieden om het zelfde te doen in 1 request. Daar ben ik het wel mee eens. Misschien dat jullie dat (die search actie die hij beschrijft) kunnen implementeren? Zo is er in ieder geval geen caching nodig voor de SubtitleDownloader (wat trouwens niet alleen een MediaPortal plugin is, maar een openbare library:
Quote:
SubtitleDownloader is a C# API library for downloading subtitles from various multi-language subtitle sites.
It was originally developed to be used with MediaPortal plugins but it can be also used in any .NET project.
If you find the project useful, you can support the development by donating via PayPal
Het is een kwestie van eenmalig onze show ID opvragen (die verandert niet) en lokaal cachen of de functie het TheTVDB id meegeven. MediaPortal gebruikt zelf ook TheTVDB om informatie op te halen, dus die informatie moeten ze dus gewoon voorhanden hebben.
Clearly you have a problem here which is that your API is getting too many requests from the clients. Did you even consider that the root cause for this problem could be the reason I said? That the API is not suitable for the needs of the clients, causing problems for you.
Take a look at other subtitle APIs, they all provide means to search by show/movie name and are working very well:
Geregistreerd: vrijdag 22 september 2006
Berichten: 2973
We already have a function for that: GetAllSubsFor
Feed it the TheTVDB (which MediaPortal has access to IIUC) or our show ID (once retrieved, which should be done only once) and you're in business.
With the current limit it means you can download 250 files per 24 hours which should be more than sufficient, unless you are unable to retrieve/save the show ID in a local cache then it would be half of that. But still, that'll be 125 files a day then.
Using the show name will most likely not work, because the name provided can be different which would mean that it may not get results and then requiring another API call until a hit is found. This is very impractical.
Why would your application need to retrieve the ID for show six times in a 2 minute window (and that was most likely delayed a bit due to the 429)? Doesn't look very optimal, and this is not just a one-time thing we regularly see your client making repeated requests in a short timeframe.
We have mentioned quite a few times in the past years (sure, it was dutch but so is this site and its main audience) that developers have to make sure their application behaves. Hammering and repeated requests are a waste of resources and bandwidth.
Feel free to make suggestions/provide us with feature requests for our new API.
Geregistreerd: zaterdag 28 november 2009
Berichten: 4
Ik heb zelf een script geschreven voor de Popcorn Hour die de Tv map afscant naar media bestanden zonder bijbehorend .srt bestand. Het klopt dat ie bij iedere show een search doet naar het id, ik kan dat id opslaan in een tekstbestandje in elke show map maar echt netjes is dat ook weer niet. En 1 database bestand aanmaken is ook nog lastig op de popcorn ivm rechtenstructuur. Desalniettemin, ik kan daar veel energie instoppen maar dan ben ik er nog niet.
De 'browser' op de popcorn stopt een aanvraag als hij langer dan 30 seconden duurt. Als ik een heel seizoen download betekent dat ik nu minimaal 12 seconden langer bezig ben. Ik moet nu dus binnen 18 seconden een hele map afscannen, 24 api requests sturen, 24 .srt bestanden selecteren, 24 srt bestanden downloaden, hernoemen en in de juiste map plaatsen... Ik kan je verzekeren, dat werkt niet
Als ik dan ook nog een paar oude series heb waar nooit NL ondertitels van zullen komen dan moet ik daar ook nog op wachten. Dat zijn ook nutteloze queries, maar hoe kan mijn script dat weten?
Daarnaast snap ik de combi van minuut en daglimiet niet zo. Als ik het daglimiet wil bereiken moet ik dat over een tijdsspanne van 2 minuten doen? Wat schieten jullie daarmee op om dat uit te smeren ipv alles in 1 keer? Als developers een delay inbouwen gaat dat alleen maar ten koste van de gebruikerservaring, de CPU cycles en data worden toch verstookt op die manier...
Zie dit aub niet als kritiek of negatief, ik geef alleen aan hoe het tot gebruiker/developer overkomt. Ik ben echt super blij met jullie site en uiteraard ook de vertalers!
Misschien is het een idee om alleen dure queries zoals FindShowByName te limiteren? Dat zet developers aan om dingen te cachen waar dat mogelijk is...
Geregistreerd: vrijdag 22 september 2006
Berichten: 2973
Quote:
Daarnaast snap ik de combi van minuut en daglimiet niet zo. Als ik het daglimiet wil bereiken moet ik dat over een tijdsspanne van 2 minuten doen? Wat schieten jullie daarmee op om dat uit te smeren ipv alles in 1 keer? Als developers een delay inbouwen gaat dat alleen maar ten koste van de gebruikerservaring, de CPU cycles en data worden toch verstookt op die manier...
Zie dit aub niet als kritiek of negatief, ik geef alleen aan hoe het tot gebruiker/developer overkomt. Ik ben echt super blij met jullie site en uiteraard ook de vertalers!
Dit topic is juist om feedback te vergaren.
Quote:
Misschien is het een idee om alleen dure queries zoals FindShowByName te limiteren? Dat zet developers aan om dingen te cachen waar dat mogelijk is...
Dat zou inderdaad ook nog een optie zijn.
De 2r/sec beperking blijft dan ook (vanwege de eerder genoemde reden), maar kunnen we op die manier wel de dure requests (zoals inderdaad FindShowByName) limiteren tot X per dag of iets in die strekking.
Wat ook nog een mogelijkheid is, is het beperken van de bandbreedte dat de API mag gebruiken. Op die manier reageren de API calls iets trager, waardoor je in principe minder snel opvolgende calls kan doen.
Ja dit vertraagt je request, maar brengt verder geen 429 meldingen mee die afgevangen moeten worden.
Een nadeel hiervan is dat de webserver dan alsnog een open connectie heeft, terwijl je normaal gesproken zo snel mogelijk je connecties wil afhandelen zodat je de volgende kan verwerken.
Geregistreerd: vrijdag 22 september 2006
Berichten: 2973
De plannen zijn iets bijgesteld, maar wil niet zeggen dat ze van de baan zijn.
Lees vooral even de topicstart van dit topic even goed door, deze heb ik voor zien van de originele tekst van het andere topic met de nodige uitbreidingen.
Geregistreerd: zaterdag 28 november 2009
Berichten: 4
Ik heb mijn script aangepast en een delay van 550msec voor iedere request ingesteld en een detectie als het script te lang loopt alvast netjes te stoppen zodat het nog een keer uitgevoerd kan worden. Zoals ik al zei, dit haalt mss pieken weg maar het aantal requests blijft hetzelfde, misschien iets meer nu aangezien sub requests voor series door meerdere runs van het script onnodig opgevraagd worden. Als jullie een definitieve oplossing hebben voor het probleem, zal ik mijn script weer aanpassen en dan ook kijken naar caching, ik heb geen behoefte aan dubbel werk Scheelt dat ik maar zo'n 50 gebruikers heb, dus mijn impact zal niet al te hoog mogen zijn...
Zou het jullie helpen om batch queries uit te voeren?
Geregistreerd: donderdag 18 oktober 2012
Berichten: 13
By the way, as you can see from your server logs, I'm currently doing
var showId = FindShowByName(showName)
var subs = GetAllSubsFor(showId)
(2 requests)
Since you already have a method for finding the show by name, why don't you just let me do
var subs = GetAllSubsFor(showName)
(1 request)
This would change nothing, only the number of requests required. Just introduce a new method and implement it internally using the stuff you already have in your API.
Geregistreerd: vrijdag 22 september 2006
Berichten: 2973
But what is the reason for not caching the "FindShowByName" output in the first place?
As the output showed earlier one of your users queried for this ID for 6 times in 2 minutes which is a bit much. This was just one show/user but if all of the API users are treating it like that it would lead to a lot of extra API calls that are a waste.
Adding showname support to a "get subs" call will complicate it even further because if the showname has no direct hit it will not give the desired information. Even if we included all shows just like FindShowByName, it would not improve anything: That output should then include ALL shows that look like the given query, making it both heavy on the backend and a bigger response.
Geregistreerd: donderdag 18 oktober 2012
Berichten: 13
Like I said above, the change I suggested would change absolutely nothing but 1) allow clients to do less requests 2) move the code & logic from clients to your internal API implementation. The end result in the client point of view is always the same, period. The show name is used in both cases, all same subs are returned eventually, hence there is no difference in size of the responses or anything. In fact, the extra request will sure cost more than executing the single new method in your API implementation.
I don't care about your show IDs. To find the correct show, I ALWAYS have to find the show first by show name, even if I do caching or not. To find the correct show, it is always up to the show name I'm using. Logic for finding the correct show by show name has to be somewhere. You are suggesting that this logic should be in (ALL) clients that are using your API which is totally wrong.
The problem is that your API depends too much of your internal IDs, otherwise there would be no need for caching those IDs IN EVERY SINGLE CLIENT. It's poor design since you expose methods that you DONT WANT TO BE CALLED. It's poor design since you are constantly telling what clients (which are your customers) should do. It's poor design since your API does not meet your customer requirements. It's poor design since you are required to make restrictions (hacks) for requests.
Finally, see again the examples of APIs I linked which work very fine.
Geregistreerd: vrijdag 22 september 2006
Berichten: 2973
We either let people do two calls, of which one is bigger but the output can (and should) be cached and subsequent calls are smaller or having them do a big call every time. Its not improving a single bit if we do that, because then the responses are always big and heavy on the backend.
Our API also accepts TheTVDB ID's, since MediaPortal is using this for scraping this ID is known so there's nothing "internal".
If a call was not to be used we would've not included it, but its pointless to do multiple calls to the same where the data will always return the same thing.
Take this for instance:
Client: Whats the ID for Lost?
API: Thats 5517 (BDID) or 73739 (thetvdb)
Client: Can I get the subs for show 5517/73939 season 3 episode 6?
API: Here is the link
Nice, I have received the subs for this episode but I also want them for 7 since so lets get it..
Client: Whats the ID for Lost?
API: Thats 5517 (BDID) or 73739 (thetvdb)
Client: Can I get the subs for show 5517/73939 season 3 episode 7?
API: Here is the link
The red part is repeated and thus pointless, this may happen up to 24 times if a whole season is being scraped or hundreds of calls if the whole Lost series is being scraped or a whole tv series library.
Why is it so hard for an API client to simply behave?
Why would it have to make 10+ connections in one second simply because the server is - at that moment - capable of handling it?
Why would it need to query the very same data time and time again even if it will never change?
Even if you cannot store it permanently, it could be stored in memory for subsequent calls for the same show. That would still save some calls.
ID's are static and will not change, there should be no reason for any API client to query this again after this has been done once. Its a waste of resources on the client and server side.
Je hebt geen rechten om een reactie te plaatsen of het topic is gesloten
Inloggen
Registreren
Sypher 
Scheelt dat ik maar zo'n 50 gebruikers heb, dus mijn impact zal niet al te hoog mogen zijn...
