Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/6189976). © Jaarbeurs IT Media.
?

 

Reacties

Is het niet mogelijk UDP te gebruiken ipv TCP als het dan toch om snelheid gaat?

@TECHNICUSS dat is echt niet wenselijk. TCP garandeerd dat het packet goed is aangekomen en repareert indien er wat misgaat. UDP is versturen van packet en hopen dat goed aankomt.

Het versnellen van een app kan ook met local storage. Caching en hoeft nog lang niet altijd direct in de tweaks te zitten. Ontwikkelaars zouden alleen soms misschien meer moeten leren dat ze ook langs het framework kunnen werken. Met andere woorden neem een deel van de code in eigen beheer en tweak daar op. Daarnaast doet een goede UX ook helpen bij het verminderen van gevoel van vertraging. (denk aan spinners, load what is visible etc.)

Dennis, het lijkt er een beetje op alsof je precies de vinger op de zere plek legt waneer we het over design paterns hebben.
Het niet kunnen begrijpen van code is gewoon een kwestie van onkundigheid, niet van een foutieve implementatie.

Goed verhaal !

In tegenstelling tot wat vaak gedacht (en geroepen) wordt is het verschil tussen UDP en TCP veel kleiner dan het lijkt. In beide gevallen zorgt uiteindelijk de client- en server-zijde van een applicatie (mogelijk(!) samen met het onderliggende OS) voor een betrouwbaar en veilig data transport.

At best kan je stellen dat TCP een aantal mechanismes aan boord heeft waarmee applicaties, al dan niet met hulp van het onderliggende OS, in staat worden gesteld om probleemgevallen te herkennen en te corrigeren.
Bij UDP dient de betreffende applicatie zelf voor die mechanismes te zorgen; mocht zoiets al wenselijk zijn. Afgezien van een CRC-tjek zijn netwerk en OS niet meer als een doorgeefluik.

Dit is een van de pijlers in het bestaansrecht van load-balancers, proxyservers, WAN-optimizers en wat dies meer zij. Ze helpen de client- en server-zijde van een applicatie door dit soort corrigerende taken van ze over te nemen. In veel gevallen gaat dit gepaard met een (min-of-meer) "eigen" interpretatie van een bepaald protocol en/of onderliggende TCP stack.
Door dit te combineren met vormen van data reductie en het off-loaden van SSL en andere security functies zijn er substantiële prestatiewinsten te boeken… of juist niet… ;-)

Want hoe dan ook, uiteindelijk hebben zowel de client- als server-zijde van een applicatie het laatste “woord”! Tis juist hier dat er voor veel applicatie ontwikkelaars nog wel wat verbeterslagen te maken zijn... al zou dat voor een aantal fabrikanten wel resulteren in een stevige aanslag op hun omzetcijfers… ;-)

Wat in dat kader vaak vergeten wordt is dat VDI-achtigen zoals XenDesktop, XenApp, Horizon en RDS hier ook weer zo hun eigen "smaakjes" van gemaakt hebben om hun "kunstje" goed te kunnen doen... dus een load-balancer combineren met (bijvoorbeeld) een Citrix Netscaler is lang niet altijd een handige!

Maar goed, de oplossing voor deze problematiek en complexiteit hangt natuurlijk in de "wolken"; eenmaal voorbij dat punt is het enkel nog zonneschijn... of was het nou rozengeur en maneschijn…

:-)

Jouw reactie


Je bent niet ingelogd. Je kunt als gast reageren, maar dan wordt je reactie pas zichtbaar na goedkeuring door de redactie. Om je reactie direct geplaatst te krijgen, moet je eerst rechtsboven inloggen of je registreren

Je naam ontbreekt
Je e-mailadres ontbreekt
Je reactie ontbreekt
Computable Expert
Dennis de Leest

Dennis de Leest
Sr. System Engineer, F5 Networks. Expert van Computable voor het topic Security.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×