Càng nhìn nó, tôi càng có xu hướng nghĩ rằng có vấn đề với việc thu thập dữ liệu.
Trước hết, có một cái gì đó thực sự kỳ lạ đang xảy ra với TPS của bạn. Trong khi mô hình tổng thể trông bình thường, có một sự phá vỡ rất sắc nét xảy ra vào khoảng 9 giờ tối, và sau đó một lần nữa vào khoảng 7 giờ sáng. Một biểu đồ bình thường sẽ mượt mà hơn nhiều trong quá trình chuyển đổi sang giờ thấp điểm.
Điều đó cho thấy rằng có một sự thay đổi trong hồ sơ và bạn có thể có 2 loại khách hàng riêng biệt:
- Một hoạt động chỉ trong khoảng từ 7 giờ sáng (ish) đến 9 giờ tối (ish), với khối lượng lớn và
- một cái khác có thể hoạt động suốt ngày đêm, với âm lượng thấp hơn.
Gợi ý thứ hai là khoảng 18:00. Phần lớn thời gian trước và sau, chúng tôi có cao hồ sơ khối lượng - TPS cao và độ trễ thấp. Nhưng vào khoảng 18:00, có sự sụt giảm đột ngột từ 800-1000 RPM xuống dưới 400 RPM. Điều gì có thể gây ra điều đó?
Gợi ý thứ ba là bước xuống trong thời gian đáp ứng 5 phần trăm. Tôi thực sự thích xem xét thời gian phản hồi tối thiểu (nhưng phân vị thứ 5 có thể tốt hơn) vì hai lý do: Nó cho tôi biết thời gian phục vụ (tức là thời gian phản hồi trừ hàng đợi) và thời gian phản hồi có xu hướng tuân theo phân phối Weibull có nghĩa là chế độ (hoặc giá trị phổ biến nhất) chỉ ở trên mức tối thiểu.
Vì vậy, bước xuống trong phân vị thứ 5 nói với tôi rằng có một sự đột ngột trong chuỗi và thời gian phục vụ đã thực sự giảm xuống mặc dù cả phương sai và thời gian phản hồi trung bình đều tăng lên rất nhiều.
Bước tiếp theo
Ở giai đoạn này, tôi sẽ đi sâu vào nhật ký để tìm hiểu sự khác biệt của các mẫu có khối lượng thấp 18:00 so với các mẫu có khối lượng cao trước và sau nó.
Tôi sẽ tìm kiếm:
- sự khác biệt về vị trí địa lý (trong trường hợp độ trễ ảnh hưởng đến $ request_time)
- sự khác biệt trong URL (không nên có)
- sự khác biệt trong phương thức HTTP (POST / GET) (không nên có)
- yêu cầu lặp lại từ cùng một IP
- và bất kỳ sự khác biệt nào khác ...
BTW, "sự kiện" 18:00 là đủ bằng chứng cho tôi rằng nó không liên quan gì đến hoạt động / tắc nghẽn của trung tâm dữ liệu. Để điều đó là sự thật, sự tắc nghẽn sẽ gây ra sự sụt giảm TPS, điều này có thể xảy ra vào lúc 18:00 nhưng cực kỳ khó có thể gây ra sự sụt giảm kéo dài và cong trơn tru trong TPS trong 10 giờ từ 9 giờ tối đến 7 giờ sáng.
