De maximale snelheid van een app

Ontwikkelaars kunnen vaak geen kant op: Er wordt van ze verwacht dat ze toepassingen bedenken die supersnel functioneren, terwijl ze aan regels moeten voldoen die dat juist tegenhouden. Ze hebben de kennis echt wel in huis om met trucs de prestaties van een app te verbeteren, maar krijgen vervolgens het deksel op de neus omdat de onderhoudskosten oplopen. Is er een maximale snelheid van een app?

Ter illustratie, bit-shifting technieken om apps met milliseconden te versnellen worden niet altijd begrepen dus leveren op de langere termijn vragen op bij beheerders. Ontwikkelaars zeggen graag ‘het was niet makkelijk om het te schrijven, dus logisch dat het moeilijk te lezen is’, maar dat is in de praktijk lastiger uit te leggen. Codeer-standaarden zijn gemaakt om iets van uniformiteit te realiseren met het oog op de langere termijn. Optimalisatie staat dus onder druk van leesbaarheid, of liever onderhoudsvriendelijkheid.

Balans, optimalisatie en beheer

Dr. Joseph Newcomer, specialist in optimalisatie, schreef in 2000 al: ‘Optimalisatie is alleen van belang als het van belang is. En wanneer dat is, is het ook gelijk heel erg van belang. Maar tot die tijd hoef je er niet veel tijd aan te besteden, omdat het zo lastig is om je vinger op de zere plek te leggen. De juiste plek om te optimaliseren is vaak lastig te bepalen waardoor heel veel tijd verloren gaat aan zoeken. Dat kost (ontwikkel)tijd en het is maar de vraag of het effect heeft.’

Je moet dus altijd op zoek naar een balans tussen optimalisatie en beheer. En meestal wint die laatste, hoewel prestatie wel degelijk een impact op de business kan hebben. Je praat over snelheden vergelijkbaar met het knipperen van je ogen, zo’n honderd milliseconden. Het lijkt niet veel, maar het kan een verschil maken van vele miljoenen. Een vertraging van honderd milliseconden kost Amazon 1 procent (660 miljoen dollar) aan omzet, zorgt voor 0,2 procent minder zoekopdrachten bij Google (ter waarde van 45 miljoen dollar) en levert bij Walmart 2 procent minder verkopen op (244 miljoen dollar).

Netwerk beperkt snelheid

Maar wat als je elke milliseconde uit de code hebt weten te persen en nog steeds geen topsnelheid hebt? Dat heeft met de omgeving van de app te maken. De app kan niet sneller zijn dan de mogelijkheden die het netwerk biedt. Je hebt te maken met de netwerkstack van platformen en besturingssystemen, en als die niet geoptimaliseerd zijn, is de app dat ook niet. Denk maar aan http-compressie. Goed toegepast binnen een lage bandbreedte verbinding als wan of mobiel kan het van waarde zijn om de gebruikerservaring van een app of website te verbeteren. Bij toepassing in een hoge bandbreedte (lan) kan het zelfs een omgekeerde werking hebben en vertraging opleveren. Hoe dan ook ga je dus een groep gebruikers teleurstellen.

Daarom is het van belang stroomopwaarts te kijken, verder weg van de app en zijn netwerkstack, naar de proxy die ervoor zit en proberen die te optimaliseren. Die netwerkstack is ontworpen om getweaked te worden. Het is ontworpen om op app-basis geconfigureerd te worden en specifieke TCP en HTTP optimalisaties te bieden om apps en Aapis te versnellen. Bij een full-proxy kunnen die optimalisaties zelfs dubbel effect sorteren door de separate netwerkstacks te tweaken. Hierbij kunnen extra caching en offload-mogelijkheid worden gerealiseerd om de druk op de apps en api’s te verlichten, waardoor de performance verbetert.

Soms is er gewoon niets wat een ontwikkelaar of DevOps kan doen om die extra milliseconden uit de app, api of zijn infrastructuur te persen. Als dat zo is, moet je verderop gaan kijken. Alleen daar zitten nog mogelijkheden om een extra boost te geven die bedrijven zo hard nodig hebben.