Redakcja
Aby poprawnie zaplanować testy, trzeba się zastanowić jakie są wymagania.
- Najważniejszy parametr to czas odpowiedzi: jak szybko system ma odpowiedzieć po wysłaniu zapytania?
- Ilu użytkowników średnio i maksymalnie może mieć serwis w zakresie akceptowalnego czasu odpowiedzi?
Niestety powyższe rzadko kiedy udaje się określić. Przy istniejących systemach można te wartości określić poprzez badanie, ale dla systemów nowych albo tych, do których nie mamy dostępu, wymagania stają się zagadką.
Głównym kosztem testowania wydajności jest zazwyczaj sprzęt. Gdy więc stajemy przed zadaniem przetestowania aplikacji aż do jej przeciążenia, to pytanie brzmi: jakie maszyny należy skonfigurować? W przypadku testów zdalnych nie ma kłopotu, by uruchomić wszystkie procesory, jakie się ma. Co jednak jeśli testów nie można przeprowadzić zdalnie? Co jeśli ze sprzętem należy pojechać do klienta?
Czasami się zdarza, że "wpięcie się" w infrastrukturę klienta nie jest możliwe. W takim wypadku to zlecający jest zmuszony do dostarczania hardware'u - my jedynie musimy zarekomendować, jakie maszyny należy przygotować. I po raz kolejny: jeśli nie wiemy, jakie obciążenie należy wygenerować, jak przygotować taką rekomendację?
Pozostaje doświadczenie i kalkulator. Sprawdzamy wydajność aplikacji wobec najlepszych praktyk, benchmarków i rekomendacji, bazując na tym, co wiemy i czego możemy się dowiedzieć.
Przykładowo: standardowy polski serwis utrzymywany na realnym serwerze nie wytrzyma więcej niż 15.000 zapytań na sekundę. Źródłem tej wiedzy jest doświadczenie w testach wydajności.
Postawienie i skonfigurowanie odpowiednio „dużej” maszyny: przy średnio skomplikowanym skrypcie testowym 1 000 wirtualnych użytkownik potrzebuje około 2,6 GHz CPU. Jeśli będziesz mnożył ilość wirtualnych użytkowników, to w miarę liniowo będzie przyrastała ilość procesorów/mocy obliczeniowej.
Obliczając (bardzo zgrubnie): aby doprowadzić do przeciążenia "standardowej" aplikacji, potrzebujemy maszyny lub maszyn dysponujących 15 procesorami o mocy 2,6 GHz.
