Wymagania dotyczące wydajności: użytkownicy i administratorzy

Użytkownicy oceniają wydajność aplikacji według ich doświadczenia:

• Czy aplikacja szybko odpowiada?
• Czy ikona klepsydry jest wyświetlana podczas wykonywania operacji w tle?
• Czy aplikacja jest uruchamiana i zamykana szybko?
• Czy błędy są obsługiwane w zrozumiały sposób?

Podsumowując, użytkownicy chcą, aby aplikacje byłyby szybkie i przewidywalne.

Z kolei administratorzy często oceniają wydajność aplikacji na temat tego, jak efektywnie korzysta z zasobów sieciowych. Administratorzy mogą poprosić:

• Czy aplikacja ma niskie obciążenie i wydajne użycie sieci?
• Czy minimalna liczba połączeń jest używana, więc mój serwer może obsługiwać jak naraz jak najwięcej użytkowników?
• Czy stale dzwonię do pomocy technicznej?

Krótko mówiąc, administratorzy chcą skalować aplikacje.

Najlepsze rozwiązania dotyczące potrzeb w zakresie wydajności

Podczas tworzenia aplikacji Windows Sockets te wymagania dotyczące wydajności przekładają się na przydatne reguły.

• Szybkie inicjowanie aplikacji sieciowych.

  Interfejs użytkownika nie powinien czekać na odpowiedzi sieciowe. Niektóre zadania można wykonać przed udostępnieniem sieci lub bez sieci. Jeśli sieć nie odpowiada, użytkownik może potrzebować interfejsu użytkownika do wykonywania prostych operacji, takich jak zamykanie aplikacji.

• Nie czekaj na zamknięcie sieci.

  Poprawnie napisane aplikacje klient-serwer obsługują przerywanie rozłączania w sposób bezproblemowy. Nie należy inicjować potencjalnie długiej operacji, takiej jak synchronizowanie plików lub folderów z serwerem, których nie można przerwać po zamknięciu. Sieci nie reagują spójnie, więc nawet małe operacje mogą okazać się czasochłonne. Prześlij pozytywną opinię dla użytkowników, w tym wskazania postępu i szacowane czasy ukończenia.

• Zapewnij dynamiczny interfejs użytkownika.

  Czas odpowiedzi aplikacji pomaga wyeliminować niepotrzebne połączenia pomocy technicznej. Dobrą wskazówką dla odpowiedzi interakcyjnej jest 500 milisekund. Użytkownicy postrzegają przerwy dłuższe niż 500 milisekund jako opóźnienie w wydajności. Aplikacje powinny odpowiadać wystarczająco szybko, aby zapewnić użytkownikowi pewność co do aplikacji.

• Przeszukuj błędy sieci.

  Nie wszystkie błędy sieci są krytyczne. Na przykład aplikacja, która odebrała lub opublikowała wszystkie jej dane, może prawdopodobnie zignorować błędy podczas zamykania połączenia. Nie zakładaj, że sieć lub użytkownik jest dostępny; obsługa błędów bez interwencji użytkownika lub ignorowanie ich, jeśli błędy są niekrytyczne.

• Aplikacja powinna zdefiniować własne rozsądne limity czasu.

  Na przykład żądanie windows Sockets connect() może blokować w pewnych warunkach nawet przez 21 sekund. Aplikacje mogą wymagać wprowadzenia własnych limitów czasu odpowiednio dla użytkowników.

• Zminimalizuj obciążenie protokołu.

  Oszczędzanie przepustowości sieci częściowo polega na zminimalizowaniu nakładu pracy związanego z protokołem spowodowanym przez aplikację. Chodzi również o wyeliminowanie niepotrzebnego ruchu sieciowego. Protokoły z niższym obciążeniem nagłówka mogą służyć do transferu danych aplikacji. Na przykład podczas wysyłania mniejszych ilości niekrytycznych lub powtarzalnych danych użyj protokołu UDP, a nie tcp, aby zmniejszyć obciążenie związane z ustanowieniem połączenia i konserwacją. Jeśli te same dane muszą być wysyłane do wielu adresatów, rozważ multiemisję. Należy pamiętać, że aplikacje UDP nie są kontrolowane przez przepływ — wypychanie poza dostępną przepustowość może spowodować katastrofalne awarie sieci. Narzędzie Netstat może być używane ze swoimi -e -e i -s -s opcje do wyświetlania statystyk dla różnych protokołów.

• Oszczędzaj zasoby systemowe.

  Zasoby systemowe mogą być używane szybko, jeśli nie jest używana odpowiednia powściągliwość. Na przykład gniazda i połączenia TCP zużywają zasoby. Nie należy używać kilku połączeń TCP na klienta, gdzie jeden będzie obsługiwać cel aplikacji.

W przypadku aplikacji transakcyjnych dobre środowisko użytkownika i niskie wykorzystanie sieci nie powodują konfliktu celów. Sieć jest wąskim gardłem. Aplikacje intensywnie korzystające z sieci poświęcają więcej czasu na oczekiwanie, a dobrze napisane aplikacje sieciowe mają na celu zminimalizowanie niepotrzebnego czasu oczekiwania, zarówno dla interfejsu użytkownika, jak i transmisji sieci.

Tematy pokrewne

aplikacje Windows Sockets o wysokiej wydajności

wymiary wydajności