7 odpovědí na toto téma

[medved2]

Ať zkouším stahovat přes Geocaching Live cokoliv, čeho je trochu víc, narážím pořád na limit api (nic neočekávaného či nepochopitelného). GG napíše, že vyčerpal limit, ale ať jsem v klidu, že to zkusí za chvíli znovu. Zkusí a nevyjde to, až pak napodruhé... To bude zřejmě minutový limit a čekačka je na necelou půlminutu.

 

Nemůžu Geogetu nějak říct, že může stahovat pomaleji (nějaké umělé prodlevy mezi jednotlivými voláními), tak aby se nepřekračoval ten minutový limit?

 

Radši bych koukal na to, jak se pomaleji zvětšuje počet zpracovaných keší, než na hlášku o překročení limitu a odpočet do dalšího pokusu. Je to taková kravina, v podstatě, protože překročení limitu není nijak penalizováno.

[HaLuMa]

no jo, ale oproc se pachtit s omelym zpomalovanim, kdyz to ve vysledku vyjde casove nastejno? Krom toho, ta logika, ktera by rozhodovala, kdy se ma zpomalovat a kdy ne, by byla dosti silena.

[medved2]

S logikou bych to moc nepřeháněl, klidně bych se spokojil s nějakým jedním nastavením, kolik milisekund počkat mezi voláními. Defaultně nula (odpovídající současnému stavu) a nastavením na vyšší hodnotu bych ukázal, že chci být hodný na servery Groundspeaku , za což by mě oni odměnili tím, že by přestali prudit s limitem. 

[Arne1]

A jseš si jist, že Zeměmluv ty limity občas nemění ?

[gord]

Nastaveni nejakych milisekund nic neresi. V tomto pripade se jedna o limit poctu volani API za nejaky cas. Ten pocet i ten cas GS jiz nekolikrat zmenil, navic se limity lisi pro jednotlive funkce. Takze GG by musel vzdy napred analyzovat jednotlive limity a pak v zavislosti na pouzite funkci vkladat nejake zbytecne casove pauzy (a informovat uzivatele o tom, ze nestahuje proto, ze ceka, aby nemusel cekat po vyprseni limitu!). Neni to zbytecne? Navic takto je to zpracovani jednotne a jednoduche pro vsechny funkce - pracuje do vyprseni limitu, pak chvili pocka a zkusi pokracovat.

Tento příspěvek byl upraven od gord: 24 říjen 2017 - 6:36

[mpik]

Otrava je to hlavně při stahování logů, tam limit změnili z 1000 na 30. Ale není důvod stahovat tisíce logů, mimo ten případ, kdy jsem hledal publikační (a to se současným limitem prakticky nejde). Jinak je to ale opravdu spíš psychologická záležitost, spousta lidí upřednostní pomalou jízdu před ostrou a neustálým brzděním. Výsledek je nakonec stejný.

[HaLuMa]

Tohle jsou navic jeste prkotiny. Informace o limitech se daji zjistit z API. Horsi je to s pouzitim v praxi. Jen si predstav tuto situaci:

1. Spustis neco, co potrebuje 20 volani API. Je duvod to zdrzovat? Proc? 20 volani se do limitu hrave vejde, proc to neudelat maximalne rychle a uzivatele zdrzovat?
2. Pak hned uzivatel spusti neco, co potrebuje take dvacet volani. Samo o sobe zase neni duvod to zdrzovat. Jenze zalezi na tom, kolik toho bylo volano pred tim, v teze minute.
3. Kazda API operace neco trva. Kazda jinak. To samo o sobe vytvari nejake to zpomaleni.

A ted si to cele zkomplikuj tim, ze ne vzdy dopredu tusis, kolikrat bude potreba to API volat. Nekdy to nevis, protoze pracujes stylem "jeste to neni vsechno? Tak mi daj dalsi stranku udaju...".

 

K tomu navic k obecnemu limitu X volani za minutu maji nektere konkretni funkce sve individualni limity.

 

Takze:

• K obecnemu zpomalovani "o neco" neni duvod, jsou operace, ktere by tozbytecne zpomalilo.
• rozhodovani, jestli a kdy zpomalit, je zavisle na tolika faktorech, ze by se kolem toho musel vystavit pomerne slozity aparat. To se nevyplati.
• Kdyz se to vezme kolem a koukolem, tak soucasny system je jednoduchy na implementaci, a z hlediska celkoveho casu vychazi i vcelku efektivne.

Nejak nemuzu prijit na to, proc by navrhovany brzdeny system mel byt lepsi?

[medved2]

mpik to shrnul docela dobře, je to jenom psychologické... kašlete na to. ;-)