[Redis] – Đánh giá hiệu suất của server Redis

Công cụ redis-benchmark

Redis đi kèm với một công cụ đánh giá được gọi là redis-benchmark. Chương trình này được dùng để mô phỏng một số lượng client kết nối cùng một lúc và thực hiện các hành động trên server , đo lường thời gian các yêu cầu được hoàn thành. Dữ liệu kết quả sẽ cung cấp cho chúng ta ý tưởng về số lượng yêu cầu trung bình mà server Redis của chúng ta có thể xử lý mỗi giây.

Một số tùy chọn phổ biến được sử dụng với lệnh của redis-benchmark:

• -h : Địa chỉ ip/host của Redis. Mặc định là 127.0.0.1 .
• -p : Port của Redis. Mặc định là 6379 .
• -a : Nếu server của chúng ta yêu cầu xác thực, chúng ta có thể sử dụng tùy chọn này để cung cấp password .
• -c : Số lượng client (kết nối song song) để mô phỏng. Giá trị mặc định là 50.
• -n : Có bao nhiêu yêu cầu thực hiện. Mặc định là 100000.
• -d : Kích thước dữ liệu cho các giá trị SET và GET , được đo bằng byte. Mặc định là 3.
• -t : Chỉ chạy một tập hợp con các lệnh cần kiểm tra hiệu suất (xem ví dụ bên dưới). Ví dụ, chúng ta có thể sử dụng -t get,set để xem hiệu suất của các lệnh GET và SET .
• -P : Sử dụng pipelining để cải thiện hiệu suất.
• -q : Chế độ im lặng, chỉ hiển thị thông tin yêu cầu trung bình trên giây .

Ví dụ: nếu chúng ta muốn kiểm tra số lượng yêu cầu trung bình mỗi giây mà server Redis local của chúng ta có thể xử lý, chúng ta có thể sử dụng:

$ redis-benchmark -q  

chúng ta sẽ nhận được kết quả tương tự như thế này, nhưng với các chỉ số khác:

chúng ta cũng có thể giới hạn các lệnh cần kiểm tra bằng cách sử dụng tham số -t . Lệnh sau chỉ hiển thị giá trị trung bình cho các lệnh GET và SET :

$ redis-benchmark -t set,get -q 

Các tùy chọn mặc định sẽ sử dụng 50 kết nối song song để tạo 100000 yêu cầu đến server Redis. Nếu chúng ta muốn tăng số lượng kết nối song song để mô phỏng mức sử dụng cao nhất, chúng ta có thể sử dụng tùy chọn -c cho điều đó:

$ redis-benchmark -t set,get -q -c 1000 

Bởi vì điều này sẽ sử dụng 1000 kết nối đồng thời thay vì 50 kết nối mặc định, chúng ta sẽ thấy hiệu suất giảm:

Nếu chúng ta muốn thông tin chi tiết trong kết quả , chúng ta có thể loại bỏ tùy chọn -q .

$ redis-benchmark -t set -c 100 -n 1000 

chúng ta sẽ nhận được kết quả tương tự như sau:

Cài đặt mặc định sử dụng 3 byte cho dữ liệu test. chúng ta có thể thay đổi điều này bằng tùy chọn -d . Ví dụ sử dụng dữ liệu test 1MB:

$ redis-benchmark -t set,get -d 1000000 -n 1000 -q 

Vì lần này server đang làm việc với tải trọng lớn hơn nhiều, hiệu suất sẽ giảm đáng kể:

Điều quan trọng là nhận ra rằng mặc dù những con số này hữu ích như một cách nhanh chóng để đánh giá hiệu suất của một server Redis, nhưng chúng không đại diện cho thông lượng tối đa mà một server Redis có thể xử lý. Bằng cách sử dụng pipelining , các ứng dụng có thể gửi nhiều lệnh cùng một lúc để cải thiện số lượng yêu cầu mỗi giây mà server có thể xử lý. Với redis-benchmark , chúng ta có thể sử dụng tùy chọn -P để mô phỏng các ứng dụng trong thế giới thực sử dụng tính năng Redis này.

Để so sánh sự khác biệt, trước tiên hãy chạy lệnh redis-benchmark với các giá trị mặc định và không có pipelining đối với các bài kiểm tra GET và SET :

$ redis-benchmark -t get,set -q 
Output
SET: 135869.56 requests per second
GET: 129366.11 requests per second

Lệnh tiếp theo sẽ chạy các thử nghiệm tương tự, nhưng sẽ kết hợp 8 lệnh với nhau:

$ redis-benchmark -t get,set -q -P 8 
Output
SET: 729927.06 requests per second
GET: 952457.19 requests per second

Như chúng ta thấy từ kết quả , có một sự cải thiện hiệu suất đáng kể với việc sử dụng pipelining.

Kiểm tra độ trễ bằng redis-cli

Nếu chúng ta muốn một phép đo đơn giản về thời gian trung bình mà một yêu cầu cần để nhận được phản hồi, chúng ta có thể sử dụng ứng dụng client Redis để kiểm tra độ trễ trung bình của server . Trong ngữ cảnh của Redis, độ trễ là thước đo thời gian để lệnh ping nhận được phản hồi từ server .

Lệnh sau sẽ hiển thị thống kê độ trễ thời gian thực cho server Redis của chúng ta:

$ redis-cli --latency 
Output
min: 0, max: 1, avg: 0.18 (970 samples) 

chúng ta sẽ nhận được kết quả tương tự như thế này, hiển thị số lượng mẫu ngày càng tăng và độ trễ trung bình thay đổi. Lệnh này sẽ tiếp tục chạy vô thời hạn. chúng ta có thể dừng nó bằng CTRL+C.

Để theo dõi độ trễ trong một khoảng thời gian nhất định, chúng ta có thể sử dụng:

$ redis-cli --latency-history 
Output
min: 0, max: 2, avg: 0.33 (1429 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.33 (1430 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.30 (1432 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.28 (1434 samples) -- 15.01 seconds range

Điều này sẽ theo dõi độ trễ trung bình theo thời gian, với khoảng thời gian có thể cấu hình được đặt thành 15 giây theo mặc định. chúng ta sẽ nhận được kết quả tương tự như trên.

Vì server Redis trong ví dụ của ta không hoạt động, không có nhiều sự khác biệt giữa các mẫu độ trễ. Tuy nhiên, nếu chúng ta có mức sử dụng cao nhất, điều này sẽ được phản ánh khi độ trễ trong kết quả tăng lên.

Nếu chúng ta chỉ muốn đo độ trễ của hệ thống , chúng ta có thể sử dụng tùy chọn --intrinsic-latency cho điều đó. Độ trễ nội tại là cố hữu đối với môi trường, tùy thuộc vào các yếu tố như phần cứng, kernel ,… và các yếu tố khác không được Redis kiểm soát.

chúng ta có thể xem độ trễ nội tại làm cơ sở cho hiệu suất Redis tổng thể của chúng ta . Lệnh sau sẽ kiểm tra độ trễ nội tại của hệ thống, chạy thử nghiệm trong 30 giây:

$ redis-cli --intrinsic-latency 30 
Output
Max latency so far: 1 microseconds.
Max latency so far: 19 microseconds.
Max latency so far: 21 microseconds.
Max latency so far: 26 microseconds.
Max latency so far: 28 microseconds.
Max latency so far: 29 microseconds.
Max latency so far: 30 microseconds.
Max latency so far: 243 microseconds.
Max latency so far: 253 microseconds.
Max latency so far: 272 microseconds.
Max latency so far: 274 microseconds.
^C
820256082 total runs (avg latency: 0.0366 microseconds / 36.57 nanoseconds per run).
Worst run took 7492x longer than the average latency.

chúng ta sẽ nhận được kết quả tương tự như trên.

So sánh cả hai bài kiểm tra độ trễ có thể hữu ích để xác định các tắc nghẽn phần cứng hoặc hệ thống có thể ảnh hưởng đến hiệu suất của server Redis của chúng ta. Ví dụ xem xét tổng độ trễ cho một yêu cầu đến server mẫu của ta có trung bình 0,18 micro giây để hoàn thành, độ trễ nội tại là 0,06 micro giây nghĩa là một phần ba tổng thời gian yêu cầu được hệ thống sử dụng trong các quy trình không được Redis kiểm soát.

Sử dụng Công cụ Điểm chuẩn Memtier

Memtier là một công cụ điểm chuẩn thông lượng cao cho Redis và Memcached do Redis Labs tạo ra. Mặc dù rất giống với redis-benchmark ở nhiều khía cạnh khác nhau, Memtier có một số tùy chọn cấu hình có thể được điều chỉnh để mô phỏng tốt hơn loại tải chúng ta có thể mong đợi trên server Redis của chúng ta , ngoài việc cung cấp hỗ trợ cụm.

Để cài đặt Memtier trên server của chúng ta, chúng ta cần phải biên dịch phần mềm từ nguồn. Trước tiên, hãy cài đặt các phụ thuộc cần thiết để biên dịch mã:

$ sudo apt-get install build-essential autoconf automake libpcre3-dev libevent-dev pkg-config zlib1g-dev -y

Tiếp theo, vào folder chính của chúng ta và sao chép dự án memtier_benchmark từ kho lưu trữ Github của nó:

$ cd 
$ git clone https://github.com/RedisLabs/memtier_benchmark.git 

Điều hướng đến folder dự án và chạy lệnh autoreconf để tạo các tập lệnh cấu hình ứng dụng:

$ cd memtier_benchmark 
$ autoreconf -ivf 

Chạy tập lệnh configure để tạo các tạo tác ứng dụng cần thiết để biên dịch:

$ ./configure 

Bây giờ chạy make để biên dịch ứng dụng:

$ make 

Khi quá trình xây dựng hoàn tất, chúng ta có thể kiểm tra file thực thi bằng:

$ ./memtier_benchmark --version 

Điều này sẽ cung cấp cho chúng ta kết quả sau:

Output
memtier_benchmark 1.2.17 Copyright (C) 2011-2017 Redis Labs Ltd. This is free software.  You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law. 

Danh sách sau đây chứa một số tùy chọn phổ biến nhất được sử dụng với lệnh memtier_benchmark :

• -s : Server lưu trữ. Mặc định là localhost .
• -p : Cổng server . Mặc định là 6379 .
• -a : Xác thực yêu cầu bằng password được cung cấp.
• -n : Số lượng yêu cầu trên mỗi client (mặc định là 10000).
• -c : Số lượng khách hàng (mặc định là 50).
• -t : Số stream (mặc định là 4).
• –pipeline : Bật pipelining.
• –ratio : Tỷ lệ giữa lệnh SET và GET , mặc định là 1:10.
• –hide-histogram : Ẩn thông tin kết quả chi tiết.

Hầu hết các tùy chọn này rất giống với các tùy chọn có trong redis-benchmark , nhưng Memtier kiểm tra hiệu suất theo một cách khác. Để mô phỏng các môi trường thực tế phổ biến tốt hơn, điểm chuẩn mặc định do memtier_benchmark thực hiện sẽ chỉ kiểm tra các yêu cầu GET và SET , theo tỷ lệ từ 1 đến 10. Với 10 hoạt động GET cho mỗi hoạt động SET trong thử nghiệm, sự sắp xếp này đại diện hơn cho một ứng dụng web phổ biến sử dụng Redis làm database hoặc bộ nhớ cache. chúng ta có thể điều chỉnh giá trị tỷ lệ bằng tùy chọn –ratio .

Lệnh sau chạy memtier_benchmark với cài đặt mặc định, trong khi chỉ cung cấp thông tin kết quả cấp cao:

$ ./memtier_benchmark --hide-histogram 

Lưu ý: nếu chúng ta đã cấu hình server Redis của chúng ta để yêu cầu xác thực, chúng ta nên cung cấp tùy chọn -a cùng với password Redis của chúng ta cho lệnh memtier_benchmark :

$ ./memtier_benchmark --hide-histogram -a your_redis_password 

chúng ta sẽ thấy kết quả tương tự như sau:

Output
...  4         Threads 50        Connections per thread 10000     Requests per client   ALL STATS ========================================================================= Type         Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec  ------------------------------------------------------------------------- Sets         8258.50          ---          ---      2.19800       636.05  Gets        82494.28     41483.10     41011.18      2.19800      4590.88  Waits           0.00          ---          ---      0.00000          ---  Totals      90752.78     41483.10     41011.18      2.19800      5226.93  

Theo lần chạy memtier_benchmark , server Redis của ta có thể thực thi khoảng 90 nghìn thao tác mỗi giây theo tỷ lệ SET / GET 1:10.

Điều quan trọng cần lưu ý là mỗi công cụ điểm chuẩn có thuật toán riêng để kiểm tra hiệu suất và trình bày dữ liệu. Vì lý do đó, bình thường có các kết quả hơi khác nhau trên cùng một server , ngay cả khi sử dụng các cài đặt tương tự.

Kết luận

Trong hướng dẫn này, ta đã trình bày cách thực hiện các bài kiểm tra điểm chuẩn trên server Redis bằng hai công cụ riêng biệt: redis-benchmark và công cụ memtier_benchmark do Redis Labs phát triển. Ta cũng đã biết cách kiểm tra độ trễ của server bằng redis-cli . Dựa trên dữ liệu thu được từ các thử nghiệm này, chúng ta sẽ hiểu rõ hơn về những gì có thể mong đợi từ server Redis của chúng ta về hiệu suất và đâu là điểm nghẽn của cài đặt hiện tại của chúng ta.

Nguồn:

• https://galaxyz.net/cach-danh-gia-hieu-suat-cua-server-redis-tren-ubuntu-1804.125.anews