Tak jak w ab – definiujemy liczbę połączeń oraz ich jednoczesność. W raporcie otrzymujemy jednak nieco więcej danych, w tym dane o obciążeniu maszyny.
Warto zwrócić uwagę na parametr Reply size, który określa rozmiar zwracanej odpowiedzi w bajtach. Jeśli wydaje się nam ona za duża, upewnijmy się, czy na serwerze webowym stosowana jest kompresja wysyłanych danych gzip.
Graficzna reprezentacja wyników testu obciążenia serwera w Apache Jmeter
Oczywiście najważniejszym parametrem jest Connection time, który określa, w jakim czasie udało się uzyskać od serwera odpowiedź w rozbiciu na czas minimalny, średni i maksymalny. Przydatne są także liczniki statusów odpowiedzi podane w polu Reply status. Warto upewnić się, czy przy obciążeniu nie pojawiają się, oprócz poprawnych odpowiedzi z kodem 200 czy 302 w przypadku przekierowania, także niepokojące błędy z innymi kodami – np. 503. Będzie to oznaczać, że przy testowanym obciążeniu któryś z elementów architektury nie działa wydajnie lub przestaje działać – np. do bazy danych kierowanych jest za dużo zapytań albo maksymalna liczba połączeń do serwera webowego została przekroczona.
Jeśli w httperf nie zdefiniujemy parametru Connection rate, to program wykona test z jak największą możliwą liczbą połączeń. Pomocny w znalezieniu maksymalnej obciążalności jest także parametr hug.
Apache Jmeter
Rozproszone testy obciążenia z wykorzystaniem Apache Jmeter
Kolejną godną polecenia aplikacją jest Apache Jmeter. Jest to narzędzie napisane w Javie. Można jej z powodzeniem używać do testowania zarówno zasobów statycznych, jak i dynamicznych – PHP, Java, ASP.NET, ale także Java Objects, baz danych i zapytań do nich oraz serwerów FTP. Lista możliwych testów jest zresztą znacznie dłuższa – obejmuje przykładowo także testowanie web services. Podobnie jak we wspomnianych wcześniej narzędziach, Jmeter symuluje wysokie obciążenie i zapisuje wyniki pracy w raporcie – tym razem od razu jest to raport graficzny i nie wymaga stosowania dodatkowych narzędzi.
