API (te) traag?

[dannx1986]

Hey hallo

Ik zou graag wat ervaringen horen van mensen die vaker met API's geprogrammeerd hebben.
Ik begrijp dat elke situatie anders is, en zonder technische insights het lastig antwoorden is.

Ik ben momenteel bezig met een project samen met twee andere partijen.

Partij 1 is de firma waar ik voor werk.
Partij 2 is een firma dat artikelen verkoopt en sinds kort een API aanbied om als reseller artikelen op je eigen website te plaatsen en verkopen.
Partij 3 is een reseller van Partij 2.

Mijn taak is om een Wordpress plugin (PHP) te programmeren om middels de aangereikte API van partij 2 data op te halen en te tonen op de website van partij 3.

In mijn eerste opzet van de Wordpress plugin wordt via cURL data uit de API in JSON formaat opgehaald en in een decoded array gezet.

De eerste 3 dagen dat ik bezig ben geweest met testen van de API verliep alles vlotjes, de API calls werden netjes binnen 2 seconden afgehandeld.

So far so good.

Echter na die eerste 3 dagen zat er ineens een enorme vertraging op de API calls van gemiddeld 8 tot 20 seconden, en daarmee in een live situatie dus niet meer bruikbaar.

Wat ik zelf heb kunnen testen zit er geen verschil in tijd of ik 5 regels of 5000 regels ophaal, hij blijft langzaam.

Hieronder nog wat stats die ik ophaal met curl_getinfo.

Took 0.000222 seconds to do DNS nameloopup
Took 0.002131 seconds to connect to https://api.xxxxxxxx.nl/a...9-2019&EndDate=04-10-2019
Took 0.035566 seconds from start until just before file transfer
Took 8.587779 seconds to send (total) request
191127 bytes downloaded

Buiten de Swagger documentatie is er technisch niet veel ondersteuning vanuit partij 2 betreft de API.

Uiteraard wel contact opgenomen, en volgens hun zou de snelheid prima zijn, en is de API niet bedoeld om live requests te doen. We zouden de data uit de API eens per dag op moeten halen en zelf in een aparte database moeten zetten om van daaruit vervolgens de data te halen.

Het verschil in snelheid zou te maken hebben met de hoeveelheid data en het aantal gebruikers van de API op verschillende momenten van de dag. Ook geven ze aan bang te zijn dat door het live ophalen de database quote: "omver getrokken wordt"

Nu snap ik dat als hun aangeven dat het live ophalen niet de bedoeling is, ik daaraan gebonden ben.

Hoe denken jullie hierover?

[ Voor 3% gewijzigd door dannx1986 op 13-09-2019 12:48 ]

[Rensjuh]

Ik denk dat het sowieso verstandig is om dagelijks de informatie te vernieuwen en zelf lokaal op te slaan.
Wat nou als hun API onbereikbaar is, dan kun jij ook geen gegevens ophalen en heb je een lege webshop.

[ Voor 6% gewijzigd door Rensjuh op 13-09-2019 11:54 ]

[Morrar]

Zoals hierboven ook gezegd wordt; sowieso lokale kopie / cache aanleggen. Records kun je een timestamp meegeven en eventueel verversen als die timestamp ouder dan een dag/week/maand is, afhankelijk van hoe kritiek het is dat de info up to date is.

Als je lokaal een kopie maakt, kun je de updates vanuit de API ook op een tijdstip in de nacht doen, als het API hopelijk wat minder druk gebruikt wordt.

[Gertjuhjan]

Partij 2 bied gratis en voor niks een api aan. En dan vind jij dat je kan eisen dat de performance op orde is voor live requests.

Het is best practice om de guidelines te volgen die bij de API horen. Oftewel zorg dat je netjes cached en dit één keer per tijdseenheid (Dag, uur of etc) ververst.

[dannx1986]

Gertjuhjan schreef op vrijdag 13 september 2019 @ 12:11:
Partij 2 bied gratis en voor niks een api aan. En dan vind jij dat je kan eisen dat de performance op orde is voor live requests.

Het is best practice om de guidelines te volgen die bij de API horen. Oftewel zorg dat je netjes cached en dit één keer per tijdseenheid (Dag, uur of etc) ververst.

Wie zegt dat ik gratis en voor niks gebruik mag maken van de API

Maar ik begrijp uit jullie reacties dat cached beter is i.v.m. eventuele downtimes.
Daar kan ik me wel in vinden.

[Gomez12]

Het is maar net de vraag wat er op de website van partij 3 getoond wordt.

Bevat de website van partij 3 alle basisinformatie en is de api enkel van toepassing voor extra / leuke data dan zou je de api kunnen gebruiken mbv caching.

Echter bevat de website van partij 3 niets dan zou ik vragen om een nachtelijk bulk bestand eventueel aangevuld met api-calls.
Puur en alleen al om dingen als search / facettering etc aan te kunnen bieden.
Plus dat je dan ook echt downtimes kan ondervangen (met caching kan de klant bij downtime leuk kijken naar de producten die hij net gezien heeft, maar niet naar nieuwe/andere producten omdat die nog niet in de cache staan).

En even in het algemeen, ik denk dat er heden ten dage heel weinig mensen zijn die daadwerkelijk 2 seconden per pagerequest acceptabel vinden voor een webshop en dan heb ik het over de complete pagina. Een API-request voor live-situatie zou bij mij echt gemiddeld 100 ms mogen duren.

2 seconden voor een api-request vind ik al totaal onacceptabel voor een live-website (daarom adviseren zij ook om het niet te doen)

[Hydra]

Heb je al contact met ze opgenomen? Hoe dan ook is dat bizar lang dus ik zou ook gewoon even uitzoeken wat de oorzaak is. Niet dat een cache perse een slecht idee is, maar overal maar een cache tegenaan smeren is vooral een lapmiddel.

[hellum]

Of 2 seconden snel of niet, is afhankelijk van de API en de hoeveelheid informatie. Maar een 2 seconde pageload is echt extreem traag. Je kunt er aan denken alle producten op te halen en in je eigen database op te slaan, de HTML output te cachen, asynchroon inladen (zodat er in ieder geval iets lijkt te gebeuren) of een combinatie.

[Guillome]

Hoe vind je 2 seconden wél acceptabel voor live data?
Zoiets haal je nooit live op bij een andere partij, veel te belastend, risicovol en hierdoor afhankelijk.
Gewoon elk uur of wat ophalen in een cronjob en in je eigen db opslaan.

Mooiste zou zijn als ze webhooks zouden ondersteunen naast de api, dat ze een call geven naar hun clients als er voorraad of iets gewijzigd wordt. Maar dat is aan partij 2.

[Gerco]

8-20 seconden is veel ja, maar niet uitzonderlijk. Ik werk met een partij waarbij de API responses vaak in de minuten zijn (tot 15 minuten heb ik tot nu toe gezien). Dat is niet ideaal, maar gebeurt gewoon in de echte wereld.

Zorg ervoor dat je weet of dat normaal is voor hen en houd er rekening mee. Laat je eigen gebruikers niet wachten op een langdurige API response als dat mogelijk is:

• Data syncen moet een achtergrondproces zijn, geen rare dingen als cron-via-web-request enzo.
• Als je een betaling of iets doet zorg dat een page-refresh of timeout geen problemen oplevert. Doe de API-call in de achtergrond en zorg dat de pagina die je bezoeker te zien krijgt alleen de status van dat proces weergeeft bijvoorbeeld.

[Webgnome]

Uiteraard wel contact opgenomen, en volgens hun zou de snelheid prima zijn, en is de API niet bedoeld om live requests te doen. We zouden de data uit de API eens per dag op moeten halen en zelf in een aparte database moeten zetten om van daaruit vervolgens de data te halen.

Ongeacht hoe je gebruik maakt van de api (betaald/gratis) dien je altijd de guidelines van de api in ere te houden. Als ze zelf aangeven dat de api niet is bedoeld realtime data op te halen dan zou ik dat dus ook niet doen. Oplossing is dan ook elke tijdseenheid de nodige requests doen om de data in je lokale cache te zetten. Dat is overigens ALTIJD een goed plan. Je wilt niet dat wanneer je eigen applicatie ineens heel veel meer gebruikers te verduren krijgt dat dan een api omver klapt omdat je je niet aan de limieten hebt gehouden.

Of het een in memory (redis) of een database cache is dat is dan om het even. Denk ook goed na over wat je precies cached.