Trong phần trước, tôi đã thảo luận về các chủ đề và cách tiếp cận để ngăn phiên bản Redis của bạn trở nên chậm chạp. Bây giờ đã đến lúc kiểm tra các cách đo lường hiệu suất.
Đo lường cái gì
Đối với phần này, chúng tôi đang xem xét độ trễ của lệnh và các thành phần của nó. Tại sao? Bởi vì số lượng lệnh bạn có thể đẩy qua máy chủ / thư viện Redis là kết quả của tốc độ của mỗi lệnh.
Nhanh chóng và dễ dàng:CLI
Cách đầu tiên để kiểm tra độ trễ lệnh của bạn là sử dụng ứng dụng khách dòng lệnh redis-cli . Nó nhanh chóng và cung cấp cho bạn một điểm kiểm tra ngay lập tức để bắt đầu. Các ví dụ ở đây sẽ sử dụng localhost để đơn giản hóa, nhưng trong quá trình thiết lập, bạn nên sử dụng -h <host> các tùy chọn và nếu cần -a <auth> và -p <port> .
Độ trễ cơ bản
Để có được kết quả độ trễ cơ bản, hãy chạy redis-cli –latency. Điều này sẽ xuất ra một tập hợp các số cho biết tối thiểu, tối đa, trung bình và số lần lặp lại. Các lần lặp này bao gồm việc chạy lệnh Redis PING đối với một kết nối đang mở. Do đó, nó không bao gồm bất kỳ thời gian nào để kết nối với máy chủ. Nếu mã của bạn kết nối trên mọi lệnh, bạn sẽ thấy hiệu suất kém hơn nhiều so với lệnh này.
Lệnh này sẽ chạy cho đến khi bạn giết nó — dễ dàng thực hiện thông qua CTRL-C. Các con số về độ trễ tính bằng mili giây. Do đó, kết quả của:
min: 0, max: 1, avg: 0.11 (11369 samples)có nghĩa là độ trễ tối thiểu dưới 1 mili giây, tối đa là 1 mili giây, với độ trễ trung bình trên mỗi PING là 0,11 mili giây. Có, đây là kết nối localhost. Những con số này là kết quả được tính toán từ 11.369 "mẫu" hoặc lệnh PING.
Ngoài ra, bạn có thể sử dụng –latency-history để thay thế. Tùy chọn này cho phép bạn chia nhỏ nó thành các lát cắt tạm thời. Chạy redis-cli –latency-history sẽ sử dụng cửa sổ mặc định là 15 giây. Kết quả sẽ giống như sau:
min: 0, max: 1, avg: 0.11 (1475 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.10 (1474 samples) -- 15.01 seconds rangeGiống như –latency, lệnh này sẽ chạy cho đến khi bạn giết nó. Nếu bạn muốn chạy với một khoảng thời gian khác, bạn có thể vượt qua -i. Ví dụ:
redis-cli --latency-history -i 10
min: 0, max: 1, avg: 0.11 (984 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds rangeVì các thao tác này chỉ cần sử dụng lệnh PING, nên lệnh này sẽ hoạt động với bất kỳ phiên bản nào của Redis.
Độ trễ nội tại
Thoạt nhìn, cái tên có thể khiến bạn tin rằng chế độ độ trễ nội bộ đang đo độ trễ nội tại của máy chủ. Nó không phải. Nếu bạn xem nguồn redis-cli trên GitHub, bạn sẽ thấy nó thậm chí không kết nối với máy chủ:
start = ustime();
compute_something_fast();
end = ustime();
latency = end-start;Theo nguồn bình luận về chế độ độ trễ nội tại:
Đo độ trễ tối đa của một quá trình đang chạy không do cuộc gọi tổng hợp. Về cơ bản, phần mềm này sẽ cung cấp gợi ý về thời gian hạt nhân rời khỏi tiến trình mà không có cơ hội chạy.
Điều này đang làm là kiểm tra độ trễ nội tại trên máy chủ khách hàng của bạn . Điều này hữu ích để biết liệu vấn đề có thực sự nằm ở phía máy khách chứ không phải bản thân máy chủ.
Vì vậy, mặc dù hữu ích, nó có thể không nằm trong các bước đầu tiên của bạn khi kiểm tra độ trễ của bạn. Cập nhật :Sau khi nói chuyện với Salvatore, anh ta đã xác nhận ý định chạy lệnh này từ máy chủ. Điều này có nghĩa là nó có thể hữu ích nếu bạn có quyền truy cập shell vào máy chủ Redis của mình, nhưng không hữu ích bằng cách khác — trường hợp này thường xảy ra nếu bạn sử dụng nhà cung cấp dịch vụ Redis.
Sử dụng Commissar
Commissar là một bộ phần mềm nhỏ mà tôi đang làm việc để theo dõi và kiểm tra độ trễ cũng như hiệu suất tổng thể của Redis. Cảnh báo:nó đang được phát triển sớm và nhiều khả năng sẽ thay đổi. Vì lý do này, chỉ sử dụng nó nếu bạn cảm thấy thoải mái khi sử dụng phần mềm chất lượng không phải do sản xuất. Commissar có trong The Github Commissar Repository.
Cụ thể cho bài viết này, chúng ta sẽ xem xét công cụ / thư mục độ trễ.
Công cụ này, được cấu hình thông qua các biến môi trường, sẽ kết nối với một phiên bản Redis nhất định và chạy cùng một cơ chế “thời gian lệnh PING” như redis-cli. Tôi đã làm điều này để duy trì tính ngang bằng của bài kiểm tra. Nó khác ở chỗ ở khả năng xuất ra nhiều thông tin hơn và (hiện tại) lưu trữ nó trong MongoDB — với nhiều cửa hàng hơn sẽ đến.
Độ trễ có thể trông như thế này, mặc dù kết quả đầu ra có thể đã thay đổi kể từ khi bài viết này được viết:
./latency
Connected to <host:ip>
100000 iterations over 53698us, average 536us/operation
Percentile breakout:
====================
99.00%: 3,876.99us
95.00%: 640.00us
90.00%: 514.00us
75.00%: 452.00us
50.00%: 414.00us
Min: 243us
Max: 44,686us
Mean: 536.98us
Jitter: 764.37usLưu ý rằng đơn vị thời gian là 'us' (tức là micro giây) trong lần chạy này. Ngoài ra, bạn có thể thấy nó sẽ cung cấp cho bạn sự đột phá về phần trăm. Điều này cho phép bạn có bức tranh rõ hơn về độ trễ trông như thế nào so với mức tối thiểu / tối đa / trung bình đơn giản. Trong ngữ cảnh này, 'Jitter' là độ lệch chuẩn của mẫu.
Kết quả này cho chúng tôi biết rằng nhìn chung, chúng tôi trông khá ổn. Ví dụ cụ thể này là qua một mạng riêng. Chúng ta có thể thấy đỉnh cao hơn nhiều so với mức trung bình, nhưng 95% số lần lặp lại ở mức hoặc dưới 640 micro giây. Điều này cho chúng ta biết điều gì?
Nó có thể cho chúng tôi biết rằng có một sự cố mạng lẻ tẻ, một sự chậm trễ lẻ tẻ phía máy chủ hoặc thậm chí một cái gì đó như kiểm soát rác trong máy khách thử nghiệm ảnh hưởng đến kết quả đầu ra. Đây là lý do tại sao việc phân phối các yêu cầu được cung cấp:vì vậy bạn có thể thấy mức độ phổ biến của kết quả "cao".
Để xác định vấn đề nằm ở đâu, trước tiên bạn sẽ muốn xem các lệnh trên máy chủ đang diễn ra trong bao lâu. Điều này sẽ cho chúng tôi biết nếu máy chủ có vấn đề.
Trong trường hợp này, chẳng hạn, bạn có thể muốn kiểm tra kết quả thông tin redis, xem cụ thể phần Commandstats:
redis-cli info commandstats
# Commandstats
cmdstat_ping:calls=32497193,usec=22213723,usec_per_call=0.68Ở đây chúng ta có thể thấy rằng thời gian trung bình để thực thi PING trên máy chủ là 0,68 micro giây. Rõ ràng bản thân lệnh ping không có khả năng là thủ phạm. Tuy nhiên, có thể có các lệnh khác được thực hiện trong quá trình kiểm tra đã hỗ trợ quá trình Redis gây ra sự chậm trễ.
Một bổ sung gần đây cho công cụ độ trễ là khả năng chạy các bài kiểm tra độ trễ đồng thời. Bằng cách đặt biến môi trường trong LATENCY_CLIENTCOUNT, bạn có thể chạy nhiều kết nối đến máy chủ Redis của mình và xem mức độ đồng thời ảnh hưởng đến kết quả độ trễ của bạn như thế nào. Ví dụ, bạn có thể thấy sự khác biệt mà một lệnh Redis PING đơn giản thấy khi bạn có 10 máy khách so với 100 hoặc thậm chí 1000 máy khách đồng thời. Điều này có thể hữu ích để thấy sự khác biệt mà bạn có thể gặp phải giữa phát triển / dàn dựng và sản xuất.
Kiểm tra từ Vùng chứa
Bạn muốn chạy thử nghiệm của mình từ vùng chứa Docker? Bây giờ tôi đẩy các vùng chứa Docker được xây dựng chỉ có công cụ golatency trong đó vào sổ đăng ký Docker công khai. Nếu bạn thực hiện một docker kéo therealbill / golatency, bạn sẽ nhận được hình ảnh, sẵn sàng chạy sau vài giây (nó hiện chỉ nặng ở kích thước hình ảnh dưới 4MB).
Đơn giản chỉ cần gọi docker chạy với các biến môi trường để kết nối và cấu hình như ReadMe chỉ ra. Sau đó, kéo đầu ra từ stdout hoặc, nếu chạy dưới dạng daemon, thông qua nhật ký docker và bạn không phải xây dựng bất kỳ thứ gì. Bất cứ khi nào tôi thực hiện các thay đổi quan trọng đối với công cụ, kho lưu trữ Docker được cập nhật với một hình ảnh mới. Ngoài ra, có một Dockerfile trong repo, cho phép bạn tùy chỉnh theo ý muốn.
Lời kết
Việc phân tích hiệu suất của bạn với Redis có thể rất phức tạp. May mắn thay, với sự hiểu biết về độ trễ và thông lượng cũng như cách chúng ảnh hưởng đến ứng dụng của bạn, bạn có thể tập trung nhiều hơn vào việc phân tích việc sử dụng Redis của ứng dụng hơn là bản thân Redis. Bạn sẽ cải thiện việc sử dụng và hiểu cách sử dụng Redis tốt nhất bằng cách ghi nhớ cụm từ Zen của Redis “Chìa khóa để đạt hiệu suất là không làm chậm Redis”, đồng thời tạo ra các ứng dụng thông minh hơn, hiệu quả hơn bằng cách tách biệt các vấn đề mạng và các lựa chọn thay thế cấu trúc dữ liệu , dẫn đến hiệu suất tốt hơn.