Požadavky na výkon: Uživatelé a správci
Uživatelé hodnotí výkon aplikací podle svých zkušeností:
- Je aplikace rychlá reagovat?
- Zobrazuje se ikona přesýpacích hodin během provádění operací na pozadí?
- Spustí se aplikace a zavře se rychle?
- Řeší se chyby srozumitelným způsobem?
Aby uživatelé mohli shrnout, chtějí, aby aplikace byly rychlé a předvídatelné.
Správci naproti tomu často hodnotí výkon aplikace, jak efektivně využívá síťové prostředky. Správci se můžou zeptat:
- Má aplikace nízkou režii a efektivní využití sítě?
- Používá se minimální počet připojení, takže server může obsluhovat co nejvíce uživatelů najednou?
- Neustále volám helpdesk?
Stručně řečeno, správci chtějí škálovat aplikace.
Osvědčené postupy pro potřeby výkonu
Při vývoji aplikace Windows Sockets se tyto požadavky na výkon překládají na užitečná pravidla.
Rychle inicializují síťové aplikace.
Uživatelské rozhraní by nemělo čekat na síťové odpovědi. Některé úlohy je možné provést před dostupností sítě nebo bez sítě. Pokud síť nereaguje, může uživatel potřebovat uživatelské rozhraní pro jednoduché operace, jako je zavření aplikace.
Nečekejte na vypnutí sítě.
Správně napsané aplikace klientského serveru zpracovávají přerušení bez problémů. Nespouštět potenciálně dlouhou operaci, například synchronizaci souborů nebo složek se serverem, které nelze přerušit při vypnutí. Sítě nejsou konzistentně responzivní, takže i malé operace můžou být časově náročné. Poskytněte uživatelům pozitivní zpětnou vazbu, včetně informací o průběhu a odhadované době dokončení.
Zajistěte responzivní uživatelské rozhraní.
Odezva aplikace pomáhá eliminovat nepotřebná volání helpdesku. Dobrým vodítkem pro interaktivní odezvu je 500 milisekund. Uživatelé vnímají prodlevu delší než 500 milisekund jako prodlevu v výkonu. Aplikace by měly být dostatečně responzivní, aby uživateli poskytly jistotu o aplikaci.
Prověřte chyby sítě.
Ne všechny chyby sítě jsou kritické. Například aplikace, která přijala nebo zveřejnila všechna svá data, může při zavírání připojení ignorovat chyby. Nepředpokládáte, že síť nebo je uživatel k dispozici; buď zpracujte chyby bez zásahu uživatele, nebo je ignorujte, pokud jsou chyby nekritické.
Aplikace by měla definovat vlastní přiměřené časové limity.
Například požadavek Windows Sockets connect() může za určitých podmínek blokovat až 21 sekund. Aplikace můžou potřebovat zavést vlastní časové limity podle potřeby pro své uživatele.
Minimalizujte režii protokolu.
Úspora šířky pásma sítě je částečně o minimalizaci režijních nákladů na protokol, které vaše aplikace způsobila. Jde také o odstranění zbytečného síťového provozu. K přenosu aplikačních dat je možné použít protokoly s nižší režií hlavičky. Pokud například odesíláte menší množství nekritických nebo opakovatelných dat, použijte na rozdíl od protokolu TCP protokol UDP, abyste snížili režii spojenou se zřízením a údržbou připojení. Pokud musí být stejná data odeslána více příjemcům, zvažte vícesměrové vysílání. Mějte na paměti, že aplikace UDP nejsou řízeny tokem – zasahování nad dostupnou šířku pásma může způsobit závažné selhání sítě. Nástroj Netstat lze použít s jeho -e a -s možnosti zobrazení statistik pro různé protokoly.
Úspora systémových prostředků.
Systémové prostředky je možné rychle využívat, pokud se nepoužívá správné omezení. Například sokety a připojení TCP spotřebovávají prostředky. Nepoužívejte několik připojení TCP na klienta, kde jeden bude sloužit účelu aplikace.
U transakčních aplikací nejsou dobré uživatelské prostředí a nízké využití sítě konfliktní cíle. Síť je kritickým bodem. Aplikace náročné na síť tráví více času čekáním a dobře napsané síťové aplikace jsou navrženy tak, aby minimalizovaly nepotřebnou dobu čekání, a to jak pro uživatelské rozhraní, tak pro síťové přenosy.
Související témata