Het was slechts een paar jaar geleden dat een responstijd van 2-seconde werd beschouwd als een grote. De sterk concurrerende wereld van Internet (en eventueel de high-frequency trading in Wall Street) heeft dat allemaal veranderd. Normaal gesproken duurt het knipperen van een oog 300-400 milliseconden. Mensen kunnen gemakkelijk tijd van een paar honderd milliseconden waarnemen. Google zegt dat gebruikers een site zullen bezoeken vaak als er 250 ms (1/4 sec) trager dan de concurrent.
Dus is het nieuwe eindgebruiker reactie tijd doel te schieten voor 250 ms in de snel veranderende en dynamische internetwereld van e-commerce en reclame. Ik geloof niet dat de collectieve wereld heeft bewogen in dezelfde richting voor responstijd voor haar interne toepassingen - 2-seconde responstijd mogelijk nog niet goed genoeg; APM industrie zou anders plotseling ontploffen in inkomsten!
Interessant is dat deze lange orde in de verwachtingen van de gebruiker kan worden uitgevoerd op de Smartphone en mobiele netwerk wereld ook. Als we moeten begrijpen waar de tijd wordt besteed in een transactie van toepassing moeten we onderzoeken het fysieke pad van een transactie-
1. De PC, laptop, Tablet PC of een Smartphone (zeggen in New York)
2. LAN of Wifi of GSM-netwerk
3. Het ISP-netwerk of een particuliere bedrijfsnetwerk
4. Voornaamste Server complex (zeg in San Francisco)
5. Aanvullende servers (zoals Ad servers voor een web-pagina)
Laten we aannemen dat we de nieuwste en grootste clientapparaat hebben en de vertraging van punt #1 negeren.
#2 - Item in een bekabeld LAN-omgeving (licht geladen) naar zijn de retourvlucht latenties in de orde van een paar milliseconden consequent. In een rustige Wifi-netwerk, afhankelijk van de frequentieband (2,4-GHZ of 5 GHZ) de retourvlucht latenties zijn in de range van 1-10 ms.
De retourvlucht latenties voor de mobiele netwerken zijn sterk afhankelijk van de generatie en de onderliggende technologie gebruikt - dus het hangt af van welk netwerk u thuis op (2G, 2, 3 G, LTE, enz.). AT&T ingesteld retourvlucht latenties van 40-50 ms voor LTE. Maar voor de oudere technologieën HSPA en HSPA + bereiken zijn 100-200 ms en 150-400 ms respectievelijk. Het is 600-750 ms voor de veel oudere EDGE en GPRS-netwerken.
Object #3 is afhankelijk van de relatieve locatie van het clientapparaat en de server complexe - in dit voorbeeld, de retourvlucht latentie zou 42 ms. als de complexe server Londen, Bombay is, of Sydney de retourvlucht latenties hoger - 56 ms, 126 ms en 160 ms respectievelijk zijn zal.
Wat dit allemaal betekent is van een recentste Smartphone, een één retourvlucht uit NY naar SF via een netwerk van LTE zou kosten ongeveer 100 ms. de meeste toepassingen moeten eerst een TCP/IP verbinding voordat alle gegevens opvragen bij de server instellen. Dit houdt in dat we voor een enkele aanvraag-antwoord interactie ten minste 200 MS dus zelfs voor deze ideale toepassing en waar alle andere Prestatiefactoren zijn perfect besteden zou, dat we naderen al deze wenselijk limiet van 250 ms.
Er is nauwelijks toepassing die een paar één verzoek-antwoord heeft - wat wij noemen toepassing chattiness als het aantal aanvraag-antwoord zou kunnen in tientallen of zelfs honderden zijn. Als een Smartphone App 10 rondreizen die niet gebruikelijk is heeft, zoekt reeds wij op een reactietijd van één seconde!
In dit artikel onderzoeken we hoe de bar op de reactietijd van de eindgebruiker is gestegen tot het knipperen van een oog en hoe het is een uitdaging om deze lange orde zelfs in een ideale situatie. We gericht op latency problemen zoals het is de beperking factor - we hebben zelfs niet overwogen server, database, bandbreedte en toepassing codering aspecten die nog meer nadelige zou kunnen zijn. Maar er zijn innovatieve APM beste praktijken en technieken om deze kwesties en de aanpak van deze uitdagende doelstelling (dit kan het onderwerp voor vele toekomstige artikelen).