Bijna dertig procent van de gebruikers buiten het hoofdkantoor is zo’n twee tot drie uur per week bezig met toegang krijgen tot documenten en applicaties op het bedrijfsnetwerk. Twintig procent van de ondervraagden verliest één tot twee uur per week door netwerkproblemen en bijna een derde van de medewerkers wacht dertig minuten tot een uur om bij bestanden te komen. Slechts veertien procent van de medewerkers in een bijkantoor is volledig tevreden met de snelheid van applicaties en is minder dan een half uur per week kwijt aan lange wachttijden.
Dit blijkt uit onderzoek van Riverbed Technology onder 362 medewerkers van internationale bedrijven in Europa, de VS en Australië. Eén van de belangrijkste oorzaken hiervan is dat ze trage toegang hebben tot de centrale applicaties en data via Wide Area Networks (WAN), zo zegt Riverbed. Volgens de leverancier van WAN-optimalisatieoplossingen zijn er grofweg drie mogelijke oorzaken voor deze WAN-problemen: ontoereikende bandbreedte, gebruik van inefficiënte netwerkprotocollen en inefficiëntie ‘communicatie' van applicaties over het WAN.
Surfen of koffie drinken
De helft van de ondervraagden moet gemiddeld één tot twee keer per week stoppen met een taak door de trage responstijd. Voor ruim een kwart van de medewerkers is het nog erger. Zij moeten drie tot vijf keer hun werk onderbreken. Bijna 20 procent geeft aan meer dan vijf keer per week een taak te moeten staken, omdat er niet langer kan worden gewacht op de gevraagde data. Slechts 5 procent van de ondervraagden zegt zijn taken altijd te kunnen afronden zonder storingen.
Medewerkers gaan tijdens lange wachttijden meestal surfen op het internet (32 procent) of nemen koffiepauze (29 procent). Anderen bezoeken tijdens deze ‘verplichte' pauzes sociale netwerken (ruim 12 procent) of lezen hun privé-e-mail (8 procent). Ruim vijf procent van de ondervraagden gaat een sigaret roken en een magere 14 procent zegt dat ze deze tijd gebruiken om met andere werkgerelateerde taken aan de slag te gaan.
De gegeven cijfers zijn lastig te controleren omdat deze toch te vaak rond subjectieve gegevens van gebruikers zijn gestoeld maar wat we wel heel duidelijk zien is dat door het toenemende gebruik van gecentraliseerde services en datacenter consolidatie, bottle necks in het netwerk kunnen ontstaan. Als leverancier van ondermeer wereldwijde WAN gerelateerde diensten zien we een sterk toenemende vraag naar allerlei additionele diensten die ervoor moeten zorgen dat de beschikbare bandbreedte zo efficient mogelijk wordt gebruikt. Riverbed is er daar inderdaad eentje van. De network managers bij onze klanten (meest multinationals) willen steeds vaker weten hoe een applicatie zich gedraagd op het WAN waarvoor we dan analyses uitvoeren. Met name als een applicatie in een datacenter aan de andere kant van de wereld wordt geraadpleegd. Het kan in die gevallen namelijk voorkomen dat door een inefficiente applicatie handshake met de gebruiker PC, tijdens bijvoorbeeld een database query, een slechte gebruikers ervaring kan ontstaan. Dit zal met name voorkomen in combinatie met applicaties die voorrang op het netwerk krijgen zoals video conferencing en IP telefonie. Een goed ingeregelde WAN optimalisatie dienst kan in deze gevallen wonderen verrichten.
Misschien moeten ze die 120Gigabyte maar niet meer over die backup SDSL-lijn laten synchroniseren op Vrijdag, na 08:00 uur ’s ochtends, in de hoop dat de Sync om 17:00 uur is afgerond, dat aangezien de meerderheid op diezelfde Vrijdagmiddag zit te internetten bij bandbreedte slurper YouTube.com…
“Onderschat nooit de bandbreedte van een vrachtwagen vol met backup tapes” 🙂
Wat ook kan helpen is eens kritisch te kijken naar het gedrag van applicaties.
Een heel mooi voorbeeld hiervan heb ik een aantal jaren geleden zelf gezien:
Onze nieuwe helpdesk-applicatie werd door heel Europa heen gebruikt, de server zelf stond in Nederland.
De collega’s in Engeland klaagden steen en been over de performance; het duurde tientallen seconden eer het beeld was opgebouwd.
– ter info: het beeld had de opbouw van een matrix, met een aantal rijen (de incidenten) en kolommen (de gegevens van de incidenten –
Al snel werd gewezen naar onze groep: de netwerkgroep. Er zou te weinig bandbreedte zijn, het netwerk was te traag enz. enz.
Dus…wij aan het meten. We zagen geen overmatige netwerkbelasting, en aan de responstijd op een ping tussen Nederland en Engeland was ook niks schokkends gewijzigd afgelopen maanden.
Na het opzetten van wat tracing kwam de aap uit de mouw: de applicatie was zo gemaakt dat na het versturen van iedere cel uit de eerder genoemde matrix een bevestiging werd gevraagd aan de client of de data goed aangekomen was.
Dus…wij gekeken naar de ping-snelheid, en dit vermenigvuldigd met het aantal cellen van de matrix en het aantal keer over en weer gezend voor de bevestigng, en toen kwamen we aardig in de buurt van de vertraging die onze collega’s in Engeland meldden
Uiteindelijk dus geen netwerk probleem, geen server probleem, maar keihard een gevolg van de keuze om na ieder stukje data een bevestiging te vragen aan de client.
Het kostte wat moeite om de leverancier te overtuigen dan het probleem toch echt bij hem lag
Maar wat ik dus wilde zeggen: wijs niet zomaar naar het netwerk of de servers; ook aan de applicatiekant kan er vaak nog wat geoptimaliseerd worden
Het is zo dat applicaties, maar ook besturingssystemen niet altijd effici?nt omgaan met de bandbreedte. Afhankelijk van de situatie kan Riverbed dus best gelijk hebben. Maar ik zie wel een tendens dat dit aan het verbeteren is. Applicatiesschrijvers houden meer rekening met wisselende netwerk kwaliteit en beschikbaarheid. Ik verwacht dat leveranciers van Operating Systems intelligentie zullen aanbrengen om de effici?nter om te gaan met bandbreedte. Bijvoorbeeld door het gebruik van Peer-2-Peer technieken waardoor clients binnen het bijkantoor bepaalde informatie met elkaar onderling kunnen delen en zo het WAN ontlasten. Dit is feitelijk de Riverbed gedachte gedistribueerd over de clients op een kantoor.
Alhoewel WAN acceleratie zeer goed kan werken (spreek uit ervaring) is het jammer dat het weer een artikel uit de reeks “wij van wc-eend, adviseren wc-eend is”.
De laatste jaren is er maar op los geprogrammeerd, want CPU power, memory en bandbreedte kosten toch niks meer. Maar wat meer zorgvuldigheid EN achtergrondkennis van applicatieontwikkelaars over de door applicatie gebruikte infrastructuur kan heel wat onnodige investeringen en ergernissen voorkomen.
Zo kan ik nog tientallen redenen bedenken waarom mensen zitten te wachten:
De werknemers kletsen te lang bij de koffieautomaat.
Diegene die de cijfers moest invoeren, zat te lang op de wc.
Diegene die de cijfers moest controleren had te veel vette kroketten gegeten in de kantine en was misselijk.
Kortom, net als TNS/NIPO die in opdracht van trosradar een onderzoek met ‘gewenste’ uitkomsten levert, alle onderzoek op deze manier is tendentieus. 🙁
@ EH, 01-09-2009 11:31
Dat de kern van de meeste problemen ligt in de applicatie die niet geschikt voor een WAN die nu eenmaal een hogere latency heeft dan een lokaal netwerk is een waarheid als een koe. WAN optimalisatie is in die gevallen alleen maar een lapmiddel dat helaas nodig is. Maar om deze problemen ?berhaupt te vinden en te analyseren op een netwerk dat overbevolkt is met vele andere applicaties en het probleem bij de bron op te lossen, (als dat al binnen redelijke kosten mogelijk is..)is dergelijke apparatuur wel nodig…