Dlaczego czas odpowiedzi eksploduje, gdy spada częstotliwość żądań?

Korekta : czas odpowiedzi ( %D) to μs nie ms! 1

Nie zmienia to nic w dziwności tego wzoru, ale oznacza, że ​​jest on praktycznie o wiele mniej niszczycielski.

Dlaczego czas odpowiedzi jest odwrotnie skorelowany z częstotliwością żądania?

Czy serwer nie powinien reagować szybciej, gdy jest mniej zajęty obsługą żądań?

Wszelkie sugestie, jak sprawić, by Apache „wykorzystywał” mniej obciążenia?

Ten wzór jest okresowy. Oznacza to, że wyświetli się, jeśli liczba wyświetleń spadnie poniżej około 200 żądań na minutę - co dzieje się (z powodu naturalnej aktywności użytkowników) od późnej nocy do wczesnego rana.

Żądania są bardzo prostymi testami POST wysyłającymi JSON o długości mniejszej niż 1000 znaków - ten JSON jest przechowywany (dołączany do pliku tekstowego) - to wszystko. Odpowiedź brzmi „-”.

Dane pokazane na wykresach zostały zarejestrowane w samym Apache:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

Jest to typowe zachowanie w centrach danych. Czas, w którym czas odpowiedzi jest wolny, odpowiada tak zwanemu Oknu wsadowemu. Jest to okres, w którym oczekuje się, że aktywność użytkownika będzie niska i można będzie uruchomić procesy wsadowe. W tym okresie wykonywane są również kopie zapasowe. Te działania mogą obciążać zasoby serwera i sieci, powodując problemy z wydajnością, takie jak widoczne.

Istnieje kilka zasobów, które mogą powodować problemy:

• Wysokie obciążenie procesora. Może to spowodować, że Apache będzie czekać na wycinek czasu w celu przetworzenia żądania.
• Wysokie wykorzystanie pamięci. Może to opróżnić bufory, które umożliwiają apache do obsługi zasobów bez odczytywania ich z dysku. Może również powodować stronicowanie / zamianę pracowników Apache.
• Wysoka aktywność dysku. Może to spowodować, że aktywność we / wy dysku zostanie umieszczona w kolejce z odpowiednim opóźnieniem w udostępnianiu treści.
• Wysoka aktywność sieci. Może to spowodować umieszczenie pakietów w kolejce do transmisji, zwiększenie liczby ponownych prób i pogorszenie jakości usługi.

Używam sardo badania takich wydań. atsarmożna wykorzystać do gromadzenia sardanych w codziennych plikach danych. Można je zbadać, aby zobaczyć, jak zachowuje się system w ciągu dnia, gdy wydajność jest normalna, i bez zmian, gdy wydajność jest zmienna.

Jeśli monitorujesz system za pomocą muninlub innego systemu, który gromadzi i wykresuje wykorzystanie zasobów, możesz tam znaleźć pewne wskaźniki. Nadal uważam za sarbardziej precyzyjne.

Istnieją narzędzia, jak nicei ionicektóre mogą być stosowane w procesach wsadowych w celu zminimalizowania ich wpływu. Działają tylko w przypadku problemów z procesorem lub I / O. Jest mało prawdopodobne, aby rozwiązały problemy z pamięcią lub aktywnością sieci.

Przeniesienie kopii zapasowej do oddzielnej sieci i zmniejszenie rywalizacji sieci. Niektóre programy do tworzenia kopii zapasowych można skonfigurować w celu ograniczenia przepustowości, która będzie używana. To może rozwiązać konflikt sieci.

W zależności od tego, w jaki sposób uruchamiane są procesy wsadowe, można ograniczyć liczbę równoległych procesów wsadowych. Może to faktycznie poprawić wydajność procesów wsadowych, ponieważ prawdopodobnie doświadczają one tej samej rywalizacji o zasoby.

Relacja ta może się zdarzyć w przeciwnym kierunku, jeśli nadawcy żądania zaczekają na wypełnienie poprzedniego żądania przed przesłaniem nowego. W takim przypadku ruch spada wraz ze wzrostem czasu żądania (z dowolnego powodu) z powodu kolejkowania po stronie klienta.

Lub może to być artefakt pomiaru - jeśli powyższy wykres pokazuje ukończone żądania , w przeciwieństwie do żądań przychodzących , szybkość spada wraz ze wzrostem czasu przetwarzania żądań (przy założeniu skończonej pojemności: D).

Chociaż odpowiedź @ BillThor może być poprawna, wydaje się mało prawdopodobne, aby okres niskiego obciążenia został całkowicie zajęty przez procesy tworzenia kopii zapasowych (tj. Czy okresy są dokładnie dopasowane).

Alternatywnym wyjaśnieniem jest po prostu buforowanie. Jeśli dany skrypt / baza danych / cokolwiek nie było ostatnio używane, odpowiednie buforowane dane mogły zostać usunięte, aby zwolnić pamięć dla reszty systemu operacyjnego. Mogą to być indeksy bazy danych, bufory O / S w stosunku do pliku lub cokolwiek innego. Zapytanie będzie wówczas musiało odtworzyć tę informację, jeśli minęło trochę czasu od ostatniego zapytania. W okresach zajętości nie będzie to miało miejsca, ponieważ ostatnie zapytanie będzie częste. To by również wyjaśniało, dlaczego widzisz niskie czasy reakcji i wysokie czasy odpowiedzi w okresie zajętości.

To, co tam widzisz, wydaje mi się, że może to być problem statystyczny. Może nie być, odpowiedź @ BillThora może być słuszna, ale opublikuję to dla kompletności.

Wykresy czasu odpowiedzi są oparte na percentylach. Przykładowa pula 800-1000 żądań to dobra liczba próbek do tego celu, pula 50-100 żądań może nie tak bardzo.

Jeśli założymy, że liczba wolnych żądań nie jest liniową funkcją objętości żądań, tak że wzrost rzędu żądań nie powoduje wzrostu rzędu żądań wolniejszych, wówczas większe wolumeny zgłoszeń niższy średni czas zapytania.

Są kłamstwa, wielkie kłamstwa i statystyki.

Moja hipoteza: masz trzy różne kategorie wniosków:

1. Normalny strumień zmienny, który zawiera większość żądań i wszystkie one są realizowane w ciągu 200–300 μs.
2. Mały strumień o stałej szybkości około 20 żądań na minutę (nawet w nocy). Każda z nich zajmuje około 2500 μs.
3. Mały strumień o stałej szybkości około 10 żądań na minutę (nawet w nocy). Każda trwa znacznie powyżej 4.000 μs.

W nocy 50 żądań na minutę to odpowiednio 20 + 20 + 10. I tak, wynik 50% percentyla silnie zależy teraz od wyniku strumienia 2. A 95% percentyla zależy od strumienia 3, więc nigdy nie będzie nawet widoczny na wykresie.

W ciągu dnia strumienie 2 + 3 są dobrze ukryte powyżej 95% percentyla.

Im dłużej na to patrzę, tym bardziej skłonny jestem myśleć, że istnieje problem z gromadzeniem danych.

Po pierwsze, z Twoim TPS dzieje się coś naprawdę dziwnego. Podczas gdy ogólny wzór wygląda normalnie, występuje bardzo ostra przerwa o około 21 wieczorem, a następnie o około 7 rano. Normalny wykres będzie znacznie płynniejszy podczas przejścia do godzin poza szczytem.

Sugeruje to zmianę profilu i możliwe, że masz 2 różne typy klientów:

1. Taki, który działa tylko między 7 rano (ish) a 9pm (ish), przy dużych głośnościach i
2. inny, który prawdopodobnie działa przez całą dobę, przy niższych poziomach głośności.

Druga wskazówka to około 18:00. Przez większość czasu przed i po mamy profil wysokiego poziomu głośności - wysokie TPS i małe opóźnienia. Ale około 18:00 następuje nagły spadek z 800-1000 RPM do mniej niż 400 RPM. Co może to spowodować?

Trzecią wskazówką jest obniżenie czasów reakcji w piątym percentylu. Właściwie wolę patrzeć na minimalne czasy odpowiedzi (ale 5. percentyl jest prawdopodobnie lepszy) z dwóch powodów: Mówi mi o czasie usługi (tj. Czas odpowiedzi minus kolejkowanie), a czasy odpowiedzi mają tendencję do podążania za rozkładem Weibulla, co oznacza, że ​​tryb (lub najczęstszą wartością) jest nieco powyżej minimum.

Tak więc obniżenie piątego percentyla mówi mi, że nastąpiła nagła przerwa w serii, a czas obsługi faktycznie skrócił się, mimo że zarówno wariancja, jak i średni czas reakcji znacznie wzrosły.

Następne kroki

Na tym etapie zagłębiałbym się w dzienniki, aby dowiedzieć się, co różni się w próbkach o małej objętości 18:00 w porównaniu do próbek o dużej objętości przed i po nim.

Szukałbym:

• różnice w lokalizacji geograficznej (w przypadku, gdy opóźnienie wpływa na $ request_time)
• różnice w adresie URL (nie powinny być żadne)
• różnice w metodzie HTTP (POST / GET) (nie powinny być żadne)
• powtarzające się żądania z tego samego adresu IP
• i wszelkie inne różnice ...

BTW, „zdarzenie” o 18:00 jest dla mnie wystarczającym dowodem na to, że nie ma to nic wspólnego z przeciążeniem / aktywnością centrum danych. Aby to było prawdą, przeciążenie musiałoby spowodować spadek TPS, co jest możliwe o godzinie 18:00, ale jest bardzo mało prawdopodobne, aby powodowało trwały i płynnie zakrzywiony spadek TPS przez 10 godzin między 21:00 a 7:00.