Prestandabehov: Användare och administratörer

Användare bedömer programmets prestanda efter deras upplevelse:

• Svarar programmet snabbt?
• Visas en timglasikon när bakgrundsåtgärder utförs?
• Startar och stänger programmet snabbt?
• Hanteras fel på ett begripligt sätt?

Sammanfattnings varför användarna vill att programmen ska vara snabba och förutsägbara.

Administratörer bedömer däremot ofta ett programs prestanda på hur effektivt det använder nätverksresurser. Administratörer kan fråga:

• Har programmet låg omkostnad och effektiv nätverksanvändning?
• Används det minsta antalet anslutningar, så att min server kan betjäna så många användare samtidigt som möjligt?
• Ringer jag hela tiden supportavdelningen?

Kort och kort vill administratörer att program ska skalas.

Metodtips för prestandabehov

När du utvecklar ett Windows Sockets-program översätts dessa prestandakrav till användbara regler.

• Låt nätverksprogrammen initieras snabbt.

  Användargränssnittet ska inte behöva vänta på nätverkssvar. Vissa uppgifter kan utföras innan nätverket är tillgängligt eller utan nätverket. Om nätverket inte svarar kan användaren behöva användargränssnittet för enkla åtgärder, till exempel att stänga programmet.

• Vänta inte på att nätverket stängs av.

  Korrekt skrivna klient-serverprogram hanterar avbrutna frånkopplingar på ett korrekt sätt. Initiera inte en potentiellt lång åtgärd, till exempel synkronisering av filer eller mappar med en server, som inte kan avbrytas vid avstängning. Nätverk är inte konsekventa, så även små åtgärder kan visa sig vara tidskrävande. Ge positiv feedback till användarna, inklusive indikationer på förlopp och uppskattade slutförandetider.

• Kontrollera ett dynamiskt användargränssnitt.

  Programresponsivitet hjälper till att eliminera onödiga supportsamtal. En bra riktlinje för interaktivt svar är 500 millisekunder. Användare uppfattar pauser längre än 500 millisekunder som en fördröjning i prestanda. Program bör vara tillräckligt dynamiska för att ge användaren förtroende för programmet.

• Granska nätverksfel.

  Alla nätverksfel är inte kritiska. Till exempel kan ett program som har tagit emot eller publicerat alla sina data förmodligen ignorera fel när anslutningen stängs. Anta inte att nätverket eller användaren är tillgänglig. hantera fel utan användarintervention eller ignorera dem om felen är icke-kritiska.

• Ett program bör definiera sina egna rimliga tidsgränser.

  En Windows Sockets connect()-begäran kan till exempel blockeras under vissa förhållanden i upp till 21 sekunder. Program kan behöva införa sina egna tidsgränser efter behov för sina användare.

• Minimera protokollkostnader.

  Att bevara nätverksbandbredd handlar delvis om att minimera protokollkostnaderna för ditt program. Det handlar också om att eliminera onödig nätverkstrafik. Protokoll med lägre rubrikomkostnader kan användas för att överföra programdata. När du till exempel skickar mindre mängder icke-kritiska eller repeterbara data använder du UDP i stället för TCP för att minska kostnaderna för etablering och underhåll av anslutningar. Om samma data måste skickas till flera mottagare bör du överväga multicast. Tänk på att UDP-program inte är flödesstyrda – push-överföring utöver den tillgängliga bandbredden kan orsaka oåterkalleliga nätverksfel. Netstat-verktyget kan användas med dess -e och -s alternativ för att visa statistik för olika protokoll.

• Spara systemresurser.

  Systemresurser kan användas snabbt om rätt begränsning inte används. Till exempel förbrukar socketar och TCP-anslutningar resurser. Använd inte flera TCP-anslutningar per klient där en kommer att tjäna programmets syfte.

För transaktionsprogram är bra användarupplevelse och låg nätverksanvändning inte motstridiga mål. Nätverket är en flaskhals. Nätverksintensiva program ägnar mer tid åt att vänta och välskrivna nätverksprogram är utformade för att minimera onödig väntetid, både för användargränssnittet och för nätverksöverföringar.

Relaterade ämnen

Windows Sockets-program med höga prestanda

prestandadimensioner