溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“Redis基準參數怎么查看”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Redis基準參數怎么查看”吧!
Redis 自帶了一個叫redis-benchmark的工具來模擬 N 個客戶端同時發出 M 個請求。 （類似于 Apacheab程序）。你可以使用redis-benchmark -h來查看基準參數。
以下參數被支持： Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>] -h <hostname> Server hostname (default 127.0.0.1) -p <port> Server port (default 6379) -s <socket> Server socket (overrides host and port) -c <clients> Number of parallel connections (default 50) -n <requests> Total number of requests (default 10000) -d <size> Data size of SET/GET value in bytes (default 2) -k <boolean> 1=keep alive 0=reconnect (default 1) -r <keyspacelen> Use random keys for SET/GET/INCR, random values for SADD Using this option the benchmark will get/set keys in the form mykey_rand:000000012456 instead of constant keys, the <keyspacelen> argument determines the max number of values for the random number. For instance if set to 10 only rand:000000000000 - rand:000000000009 range will be allowed. -P <numreq> Pipeline <numreq> requests. Default 1 (no pipeline). -q Quiet. Just show query/sec values --csv Output in CSV format -l Loop. Run the tests forever -t <tests> Only run the comma separated list of tests. The test names are the same as the ones produced as output. -I Idle mode. Just open N idle connections and wait.
你需要在基準測試之前啟動一個 Redis 實例。一般這樣啟動測試：
redis-benchmark -q -n 100000
這個工具使用起來非常方便，同時你可以使用自己的基準測試工具， 不過開始基準測試時候，我們需要注意一些細節。
你不必每次都運行 redis-benchmark 默認的所有測試。 使用-t參數可以選擇你需要運行的測試用例，比如下面的范例：
$ redis-benchmark -t set,lpush -n 100000 -q SET: 74239.05 requests per second LPUSH: 79239.30 requests per second
在上面的測試中，我們只運行了 SET 和 LPUSH 命令， 并且運行在安靜模式中（使用-q參數）。
也可以直接指定命令來直接運行，比如下面的范例：
$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
script load redis.call('set','foo','bar'): 69881.20 requests per second默認情況下面，基準測試使用單一的 key。在一個基于內存的數據庫里， 單一 key 測試和真實情況下面不會有巨大變化。當然，使用一個大的 key 范圍空間， 可以模擬現實情況下面的緩存不命中情況。
這時候我們可以使用-r命令。比如，假設我們想設置 10 萬隨機 key 連續 SET 100 萬次，我們可以使用下列的命令：
$ redis-cli flushall OK $ redis-benchmark -t set -r 100000 -n 1000000 ====== SET ====== 1000000 requests completed in 13.86 seconds 50 parallel clients 3 bytes payload keep alive: 1 99.76% `<=` 1 milliseconds 99.98% `<=` 2 milliseconds 100.00% `<=` 3 milliseconds 100.00% `<=` 3 milliseconds 72144.87 requests per second $ redis-cli dbsize (integer) 99993
默認情況下，每個客戶端都是在一個請求完成之后才發送下一個請求 （benchmark 會模擬 50 個客戶端除非使用-c指定特別的數量）， 這意味著服務器幾乎是按順序讀取每個客戶端的命令。Also RTT is payed as well.
真實世界會更復雜，Redis 支持/topics/pipelining，使得可以一次性執行多條命令成為可能。 Redis pipelining 可以提高服務器的 TPS。
下面這個案例是在 Macbook air 11" 上使用 pipelining 組織 16 條命令的測試范例：
$ redis-benchmark -n 1000000 -t set,get -P 16 -q SET: 403063.28 requests per second GET: 508388.41 requests per second
記得在多條命令需要處理時候使用 pipelining。
第一點是顯而易見的：基準測試的黃金準則是使用相同的標準。 用相同的任務量測試不同版本的 Redis，或者用相同的參數測試測試不同版本 Redis。 如果把 Redis 和其他工具測試，那就需要小心功能細節差異。
Redis 是一個服務器：所有的命令都包含網絡或 IPC 消耗。這意味著和它和 SQLite， Berkeley DB， Tokyo/Kyoto Cabinet 等比較起來無意義， 因為大部分的消耗都在網絡協議上面。
Redis 的大部分常用命令都有確認返回。有些數據存儲系統則沒有（比如 MongoDB 的寫操作沒有返回確認）。把 Redis 和其他單向調用命令存儲系統比較意義不大。
簡單的循環操作 Redis 其實不是對 Redis 進行基準測試，而是測試你的網絡（或者 IPC）延遲。想要真正測試 Redis，需要使用多個連接（比如 redis-benchmark)， 或者使用 pipelining 來聚合多個命令，另外還可以采用多線程或多進程。
Redis 是一個內存數據庫，同時提供一些可選的持久化功能。 如果你想和一個持久化服務器（MySQL, PostgreSQL 等等） 對比的話， 那你需要考慮啟用 AOF 和適當的 fsync 策略。
Redis 是單線程服務。它并沒有設計為多 CPU 進行優化。如果想要從多核獲取好處， 那就考慮啟用多個實例吧。將單實例 Redis 和多線程數據庫對比是不公平的。
一個普遍的誤解是 redis-benchmark 特意讓基準測試看起來更好， 所表現出來的數據像是人造的，而不是真實產品下面的。
Redis-benchmark 程序可以簡單快捷的對給定硬件條件下面的機器計算出性能參數。 但是，通常情況下面這并不是 Redis 服務器可以達到的最大吞吐量。 事實上，使用 pipelining 和更快的客戶端（hiredis）可以達到更大的吞吐量。 redis-benchmark 默認情況下面僅僅使用并發來提高吞吐量（創建多條連接）。 它并沒有使用 pipelining 或者其他并行技術（僅僅多條連接，而不是多線程）。
如果想使用 pipelining 模式來進行基準測試（了達到更高吞吐量），可以使用-P參數。這種方案的確可以提高性能，有很多使用 Redis 的應用在生產環境中這樣做。
最后，基準測試需要使用相同的操作和數據來對比，如果這些不一樣， 那么基準測試是無意義的。
比如，Redis 和 memcached 可以在單線程模式下面對比 GET/SET 操作。 兩者都是內存數據庫，協議也基本相同，甚至把多個請求合并為一條請求的方式也類似 （pipelining）。在使用相同數量的連接后，這個對比是很有意義的。
下面這個很不錯例子是在 Redis（antirez）和 memcached（dormando）測試的。
antirez 1 - On Redis, Memcached, Speed, Benchmarks and The Toilet
dormando - Redis VS Memcached (slightly better bench)
antirez 2 - An update on the Memcached/Redis benchmark
你可以發現相同條件下面最終結果是兩者差別不大。請注意最終測試時候， 兩者都經過了充分優化。
最后，當特別高性能的服務器在基準測試時候（比如 Redis、memcached 這類）， 很難讓服務器性能充分發揮，通常情況下，客戶端回事瓶頸限制而不是服務器端。 在這種情況下面，客戶端（比如 benchmark 程序自身）需要優化，或者使用多實例， 從而能達到最大的吞吐量。
有幾個因素直接決定 Redis 的性能。它們能夠改變基準測試的結果， 所以我們必須注意到它們。一般情況下，Redis 默認參數已經可以提供足夠的性能， 不需要調優。
網絡帶寬和延遲通常是最大短板。建議在基準測試之前使用 ping 來檢查服務端到客戶端的延遲。根據帶寬，可以計算出最大吞吐量。 比如將 4 KB 的字符串塞入 Redis，吞吐量是 100000 q/s，那么實際需要 3.2 Gbits/s 的帶寬，所以需要 10 GBits/s 網絡連接， 1 Gbits/s 是不夠的。 在很多線上服務中，Redis 吞吐會先被網絡帶寬限制住，而不是 CPU。 為了達到高吞吐量突破 TCP/IP 限制，最后采用 10 Gbits/s 的網卡， 或者多個 1 Gbits/s 網卡。
CPU 是另外一個重要的影響因素，由于是單線程模型，Redis 更喜歡大緩存快速 CPU， 而不是多核。這種場景下面，比較推薦 Intel CPU。AMD CPU 可能只有 Intel CPU 的一半性能（通過對 Nehalem EP/Westmere EP/Sandy 平臺的對比）。 當其他條件相當時候，CPU 就成了 redis-benchmark 的限制因素。
在小對象存取時候，內存速度和帶寬看上去不是很重要，但是對大對象（> 10 KB）， 它就變得重要起來。不過通常情況下面，倒不至于為了優化 Redis 而購買更高性能的內存模塊。
Redis 在 VM 上會變慢。虛擬化對普通操作會有額外的消耗，Redis 對系統調用和網絡終端不會有太多的 overhead。建議把 Redis 運行在物理機器上， 特別是當你很在意延遲時候。在最先進的虛擬化設備（VMWare）上面，redis-benchmark 的測試結果比物理機器上慢了一倍，很多 CPU 時間被消費在系統調用和中斷上面。
如果服務器和客戶端都運行在同一個機器上面，那么 TCP/IP loopback 和 unix domain sockets 都可以使用。對 Linux 來說，使用 unix socket 可以比 TCP/IP loopback 快 50%。 默認 redis-benchmark 是使用 TCP/IP loopback。
當大量使用 pipelining 時候，unix domain sockets 的優勢就不那么明顯了。
當使用網絡連接時，并且以太網網數據包在 1500 bytes 以下時， 將多條命令包裝成 pipelining 可以大大提高效率。事實上，處理 10 bytes，100 bytes， 1000 bytes 的請求時候，吞吐量是差不多的，詳細可以見下圖。
在多核 CPU 服務器上面，Redis 的性能還依賴 NUMA 配置和 處理器綁定位置。 最明顯的影響是 redis-benchmark 會隨機使用 CPU 內核。為了獲得精準的結果， 需要使用固定處理器工具（在 Linux 上可以使用 taskset 或 numactl）。 最有效的辦法是將客戶端和服務端分離到兩個不同的 CPU 來高校使用三級緩存。 這里有一些使用 4 KB 數據 SET 的基準測試，針對三種 CPU（AMD Istanbul, Intel Nehalem EX， 和 Intel Westmere）使用不同的配置。請注意， 這不是針對 CPU 的測試。
在高配置下面，客戶端的連接數也是一個重要的因素。得益于 epoll/kqueue， Redis 的事件循環具有相當可擴展性。Redis 已經在超過 60000 連接下面基準測試過， 仍然可以維持 50000 q/s。一條經驗法則是，30000 的連接數只有 100 連接的一半吞吐量。 下面有一個關于連接數和吞吐量的測試。
在高配置下面，可以通過調優 NIC 來獲得更高性能。最高性能在綁定 Rx/Tx 隊列和 CPU 內核下面才能達到，還需要開啟 RPS（網卡中斷負載均衡）。更多信息可以在thread。Jumbo frames 還可以在大對象使用時候獲得更高性能。
在不同平臺下面，Redis 可以被編譯成不同的內存分配方式（libc malloc, jemalloc, tcmalloc），他們在不同速度、連續和非連續片段下會有不一樣的表現。 如果你不是自己編譯的 Redis，可以使用 INFO 命令來檢查內存分配方式。 請注意，大部分基準測試不會長時間運行來感知不同分配模式下面的差異， 只能通過生產環境下面的 Redis 實例來查看。
任何基準測試的一個重要目標是獲得可重現的結果，這樣才能將此和其他測試進行對比。
一個好的實踐是盡可能在隔離的硬件上面測試。如果沒法實現，那就需要檢測 benchmark 沒有受其他服務器活動影響。
有些配置（桌面環境和筆記本，有些服務器也會）會使用可變的 CPU 分配策略。 這種策略可以在 OS 層面配置。有些 CPU 型號相對其他能更好的調整 CPU 負載。 為了達到可重現的測試結果，最好在做基準測試時候設定 CPU 到最高使用限制。
一個重要因素是配置盡可能大內存，千萬不要使用 SWAP。注意 32 位和 64 位 Redis 有不同的內存限制。
如果你計劃在基準測試時候使用 RDB 或 AOF，請注意不要讓系統同時有其他 I/O 操作。 避免將 RDB 或 AOF 文件放到 NAS 或 NFS 共享或其他依賴網絡的存儲設備上面（比如 Amazon EC2 上 的 EBS）。
將 Redis 日志級別設置到 warning 或者 notice。避免將日志放到遠程文件系統。
避免使用檢測工具，它們會影響基準測試結果。使用 INFO 來查看服務器狀態沒問題， 但是使用 MONITOR 將大大影響測試準確度。
這些測試模擬了 50 客戶端和 200w 請求。
使用了 Redis 2.6.14。
使用了 loopback 網卡。
key 的范圍是 100 w。
同時測試了 有 pipelining 和沒有的情況（16 條命令使用 pipelining）。
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (with pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q SET: 552028.75 requests per second GET: 707463.75 requests per second LPUSH: 767459.75 requests per second LPOP: 770119.38 requests per second
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (without pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q SET: 122556.53 requests per second GET: 123601.76 requests per second LPUSH: 136752.14 requests per second LPOP: 132424.03 requests per second
Linode 2048 instance (with pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q -P 16 SET: 195503.42 requests per second GET: 250187.64 requests per second LPUSH: 230547.55 requests per second LPOP: 250815.16 requests per second
Linode 2048 instance (without pipelining)
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q SET: 35001.75 requests per second GET: 37481.26 requests per second LPUSH: 36968.58 requests per second LPOP: 35186.49 requests per second
$ redis-benchmark -n 100000 ====== SET ====== 100007 requests completed in 0.88 seconds 50 parallel clients 3 bytes payload keep alive: 1 58.50% <= 0 milliseconds 99.17% <= 1 milliseconds 99.58% <= 2 milliseconds 99.85% <= 3 milliseconds 99.90% <= 6 milliseconds 100.00% <= 9 milliseconds 114293.71 requests per second ====== GET ====== 100000 requests completed in 1.23 seconds 50 parallel clients 3 bytes payload keep alive: 1 43.12% <= 0 milliseconds 96.82% <= 1 milliseconds 98.62% <= 2 milliseconds 100.00% <= 3 milliseconds 81234.77 requests per second ====== INCR ====== 100018 requests completed in 1.46 seconds 50 parallel clients 3 bytes payload keep alive: 1 32.32% <= 0 milliseconds 96.67% <= 1 milliseconds 99.14% <= 2 milliseconds 99.83% <= 3 milliseconds 99.88% <= 4 milliseconds 99.89% <= 5 milliseconds 99.96% <= 9 milliseconds 100.00% <= 18 milliseconds 68458.59 requests per second ====== LPUSH ====== 100004 requests completed in 1.14 seconds 50 parallel clients 3 bytes payload keep alive: 1 62.27% <= 0 milliseconds 99.74% <= 1 milliseconds 99.85% <= 2 milliseconds 99.86% <= 3 milliseconds 99.89% <= 5 milliseconds 99.93% <= 7 milliseconds 99.96% <= 9 milliseconds 100.00% <= 22 milliseconds 100.00% <= 208 milliseconds 88109.25 requests per second ====== LPOP ====== 100001 requests completed in 1.39 seconds 50 parallel clients 3 bytes payload keep alive: 1 54.83% <= 0 milliseconds 97.34% <= 1 milliseconds 99.95% <= 2 milliseconds 99.96% <= 3 milliseconds 99.96% <= 4 milliseconds 100.00% <= 9 milliseconds 100.00% <= 208 milliseconds 71994.96 requests per second
注意：包大小從 256 到 1024 或者 4096 bytes 不會改變結果的量級 （但是到 1024 bytes 后，GETs 操作會變慢）。同樣的，50 到 256 客戶端的測試結果相同。 10 個客戶端時候，吞吐量會變小（譯者按：總量到不了最大吞吐量）。
不同機器可以獲的不一樣的結果，下面是Intel T5500 1.66 GHz 在 Linux 2.6下面的結果：
$ ./redis-benchmark -q -n 100000 SET: 53684.38 requests per second GET: 45497.73 requests per second INCR: 39370.47 requests per second LPUSH: 34803.41 requests per second LPOP: 37367.20 requests per second
另外一個是 64 位 Xeon L5420 2.5 GHz 的結果：
$ ./redis-benchmark -q -n 100000 PING: 111731.84 requests per second SET: 108114.59 requests per second GET: 98717.67 requests per second INCR: 95241.91 requests per second LPUSH: 104712.05 requests per second LPOP: 93722.59 requests per second
Redis2.4.2 。
默認連接數，數據包大小 256 bytes。
Linux 是SLES10 SP3 2.6.16.60-0.54.5-smp，CPU 是 2 xIntel X5670 @ 2.93 GHz。
固定 CPU，但是使用不同 CPU 內核。
使用 unix domain socket：
$ numactl -C 6 ./redis-benchmark -q -n 100000 -s /tmp/redis.sock -d 256 PING (inline): 200803.22 requests per second PING: 200803.22 requests per second MSET (10 keys): 78064.01 requests per second SET: 198412.69 requests per second GET: 198019.80 requests per second INCR: 200400.80 requests per second LPUSH: 200000.00 requests per second LPOP: 198019.80 requests per second SADD: 203665.98 requests per second SPOP: 200803.22 requests per second LPUSH (again, in order to bench LRANGE): 200000.00 requests per second LRANGE (first 100 elements): 42123.00 requests per second LRANGE (first 300 elements): 15015.02 requests per second LRANGE (first 450 elements): 10159.50 requests per second LRANGE (first 600 elements): 7548.31 requests per second
使用 TCP loopback：
$ numactl -C 6 ./redis-benchmark -q -n 100000 -d 256 PING (inline): 145137.88 requests per second PING: 144717.80 requests per second MSET (10 keys): 65487.89 requests per second SET: 142653.36 requests per second GET: 142450.14 requests per second INCR: 143061.52 requests per second LPUSH: 144092.22 requests per second LPOP: 142247.52 requests per second SADD: 144717.80 requests per second SPOP: 143678.17 requests per second LPUSH (again, in order to bench LRANGE): 143061.52 requests per second LRANGE (first 100 elements): 29577.05 requests per second LRANGE (first 300 elements): 10431.88 requests per second LRANGE (first 450 elements): 7010.66 requests per second LRANGE (first 600 elements): 5296.61 requests per second
到此，相信大家對“Redis基準參數怎么查看”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
