Redis datang dengan alat yang dipanggil penanda aras redis untuk mensimulasikan N pelanggan yang mengeluarkan permintaan M pada masa yang sama. (serupa dengan program Apacheab). Gunakan arahan redis-benchmark -h untuk melihat parameter penanda aras.
以下参数被支持： 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.</tests></numreq></numreq></keyspacelen></keyspacelen></boolean></size></requests></clients></socket></port></hostname></boolean></requests></clients></port></host>
Anda perlu memulakan contoh Redis sebelum menanda aras. Secara umumnya, ujian dimulakan seperti ini:
redis-benchmark -q -n 100000
Alat ini sangat mudah digunakan, dan anda boleh menggunakan alat ujian penanda aras anda sendiri Walau bagaimanapun, apabila memulakan ujian penanda aras, kami perlu memberi perhatian kepada beberapa butiran .
Anda tidak perlu menjalankan semua ujian secara lalai setiap kali anda menjalankan penanda aras semula. Anda boleh menggunakan parameter "-t" untuk menentukan kes ujian yang perlu dijalankan, seperti contoh berikut:
$ redis-benchmark -t set,lpush -n 100000 -q SET: 74239.05 requests per second LPUSH: 79239.30 requests per second
Dalam ujian di atas, kami hanya menjalankan arahan SET dan LPUSH, dan menjalankan dalam mod senyap (menggunakan parameter -q).
Anda juga boleh menentukan secara langsung arahan untuk dijalankan secara langsung, seperti contoh berikut:
$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
script load redis.call('set','foo','bar'): 69881.20 requests per secondSecara lalai, ujian penanda aras menggunakan satu kunci. Dalam pangkalan data dalam memori, tidak akan ada perbezaan besar antara ujian kunci tunggal dan dunia sebenar. Sudah tentu, meluaskan julat utama boleh mensimulasikan kehilangan cache dunia sebenar.
Pada masa ini kita boleh menggunakan arahan -r. Sebagai contoh, jika kita ingin melakukan 1 juta operasi SET secara berterusan, menggunakan 100,000 kekunci rawak setiap kali, kita boleh menggunakan arahan berikut:
$ 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% `<h3>Gunakan saluran paip</h3><p>Secara lalai, setiap pelanggan Seterusnya permintaan dihantar hanya selepas satu permintaan selesai (penanda aras akan mensimulasikan 50 pelanggan melainkan nombor khas ditentukan dengan -c), yang bermaksud pelayan membaca arahan setiap klien hampir mengikut urutan. RTT juga dibayar.</p><p>Dunia sebenar akan menjadi lebih kompleks, dan Redis menyokong /topics/pipelining, menjadikannya mungkin untuk melaksanakan berbilang arahan sekaligus. Gunakan saluran paip Redis untuk meningkatkan transaksi pelayan anda pada kadar sesaat. </p><p>Kes berikut ialah contoh ujian menggunakan pipelining untuk mengatur 16 arahan pada Macbook air 11": </p><pre class="brush:php;toolbar:false">$ redis-benchmark -n 1000000 -t set,get -P 16 -q SET: 403063.28 requests per second GET: 508388.41 requests per second
Ingat untuk menggunakan pipelining apabila berbilang arahan perlu diproses.
Perkara pertama adalah jelas: peraturan emas penanda aras ialah menggunakan standard yang sama apabila menguji versi Redis yang berbeza, anda boleh menguji dengan beban kerja yang sama atau menggunakan parameter yang sama uji Redis dengan alat lain, anda perlu berhati-hati tentang perbezaan dalam butiran fungsi
Redis ialah pelayan: semua arahan termasuk penggunaan rangkaian atau IPC, yang bermaksud ia berbeza daripada SQLite. , Berkeley DB, Tokyo/Kyoto Cabinet, dsb. tidak bermakna jika dibandingkan, kerana kebanyakan penggunaan adalah pada protokol rangkaian
Kebanyakan arahan biasa Redis mempunyai pengembalian pengesahan. Operasi tulis MongoDB tidak mengembalikan pengesahan, tetapi beberapa sistem storan data tidak masuk akal untuk membandingkan Redis dengan sistem storan perintah panggilan sehala yang lain
Malah, operasi gelung yang mudah pada Redis. Daripada menanda aras Redis, uji kependaman rangkaian anda (atau IPC) Untuk benar-benar menguji Redis, anda perlu menggunakan berbilang sambungan (seperti penanda aras semula), atau menggunakan saluran paip untuk mengagregatkan berbilang arahan. threading atau berbilang proses.
Redis ialah pangkalan data dalam memori dan juga menyediakan beberapa keupayaan kegigihan pilihan jika anda ingin membandingkan dengan pelayan kegigihan (MySQL, PostgreSQL, dll.). Jika ya, maka anda perlu mempertimbangkan untuk mendayakan AOF dan strategi fsync yang sesuai
Redis tidak direka untuk dioptimumkan untuk berbilang CPU. instance Redis dengan pangkalan data berbilang benang
Salah tanggapan biasa ialah penanda aras semula direka untuk menjadikan penanda aras kelihatan lebih baik, data yang ditunjukkan kelihatan tiruan dan bukan produk sebenar.
Alat penanda aras Redis boleh mengira parameter prestasi mesin dengan cepat dan mudah dalam keadaan perkakasan tertentu Walau bagaimanapun, perkara berikut biasanya berlaku saluran paip dan pelanggan yang lebih pantas (seperti hiredis), adalah mungkin untuk mencapai daya tampung yang lebih tinggi Secara lalai, penanda aras semula hanya menggunakan konkurensi untuk meningkatkan daya tampung (mewujudkan berbilang baris). Ia tidak menggunakan saluran paip atau teknik konkurensi lain, ia hanya menggunakan berbilang sambungan dan bukannya berbilang benang.
Jika anda ingin menggunakan mod saluran paip untuk penanda aras (untuk mencapai daya pemprosesan yang lebih tinggi), anda boleh menggunakan parameter -P. Banyak aplikasi yang menggunakan Redis dalam persekitaran pengeluaran menggunakan pendekatan ini untuk meningkatkan prestasi.
Akhir sekali, penanda aras perlu menggunakan operasi dan data yang sama untuk perbandingan Jika ini tidak sama, maka ujian penanda aras tidak bermakna.
Sebagai contoh, Redis dan memcached boleh membandingkan operasi GET/SET dalam mod satu benang. Kedua-duanya adalah pangkalan data dalam memori, dan protokol pada dasarnya adalah sama Malah cara menggabungkan berbilang permintaan ke dalam satu permintaan adalah serupa (penyambungan paip). Perbandingan ini bermakna selepas menggunakan bilangan sambungan yang sama.
Berikut ialah contoh hebat yang diuji pada Redis (antirez) dan memcached (dormando).
antirez 1 - On Redis, Memcached, Speed, Benchmarks and The Toilet
dormando - Redis VS Memcached (bangku yang lebih baik sedikit)
antirez 2 - Kemas kini pada penanda aras Memcached/Redis
Anda boleh mendapati bahawa keputusan akhir dalam keadaan yang sama tidak jauh berbeza. Sila ambil perhatian bahawa pada masa ujian akhir, kedua-duanya telah dioptimumkan sepenuhnya.
Akhir sekali, apabila pelayan berprestasi tinggi terutamanya ditanda aras (seperti Redis, memcached, dll.), sukar untuk menggunakan prestasi pelayan sepenuhnya Biasanya, kesesakan terletak pada sisi klien dan bukannya pada bahagian pelayan. Dalam kes ini, pelanggan (seperti program penanda aras itu sendiri) perlu dioptimumkan atau menggunakan berbilang kejadian untuk mencapai daya pemprosesan maksimum.
Terdapat beberapa faktor yang secara langsung menentukan prestasi Redis. Mereka boleh mengubah keputusan penanda aras, jadi kita mesti memberi perhatian kepada mereka. Biasanya, parameter lalai Redis mencukupi untuk memberikan prestasi yang cekap, jadi penalaan tidak diperlukan.
Jalur lebar dan kependaman rangkaian biasanya merupakan kelemahan terbesar. Saya cadangkan menggunakan arahan ping untuk mengesan kependaman antara pelayan dan klien sebelum menanda aras. Berdasarkan lebar jalur, daya pemprosesan maksimum boleh dikira. Sebagai contoh, jika rentetan 4 KB dimasukkan ke dalam Redis dan daya pemprosesan ialah 100,000 q/s, maka 3.2 Gbits/s lebar jalur sebenarnya diperlukan, jadi sambungan rangkaian 10 Gbits/s tidak mencukupi . Dalam kebanyakan perkhidmatan dalam talian, lebar jalur rangkaian sering menjadi faktor pengehad dalam pemprosesan Redis lebih awal daripada CPU. Untuk mencapai daya pemprosesan yang tinggi dan menembusi had TCP/IP, kad rangkaian 10 Gbits/s akhirnya digunakan, atau berbilang kad rangkaian 1 Gbits/s.
CPU ialah satu lagi faktor penting yang mempengaruhi Memandangkan ia adalah model satu benang, Redis lebih suka cache yang besar dan CPU yang pantas berbanding berbilang teras. Dalam senario ini, CPU Intel lebih disyorkan. CPU AMD mungkin hanya separuh berkuasa daripada CPU Intel (berbanding platform Nehalem EP/Westmere EP/Sandy). Jika syarat lain adalah sama, maka CPU adalah kesesakan penanda aras semula.
Apabila mengakses objek kecil, kelajuan memori dan lebar jalur nampaknya tidak begitu penting, tetapi untuk objek besar (> 10 KB), ia menjadi penting. Secara umumnya, orang ramai tidak membeli modul memori prestasi lebih tinggi untuk mengoptimumkan Redis.
Redis boleh menjadi perlahan pada VM. Maya akan mempunyai penggunaan tambahan pada operasi biasa, manakala Redis tidak akan mempunyai banyak overhed pada panggilan sistem dan terminal rangkaian. Apabila kependaman menjadi kebimbangan khusus, adalah disyorkan untuk menggunakan Redis dan menjalankannya pada pelayan fizikal. Pada peranti virtualisasi paling maju (VMware), hasil ujian penanda aras semula adalah dua kali lebih perlahan berbanding pada mesin fizikal, dan banyak masa CPU digunakan dalam panggilan sistem dan gangguan.
Jika kedua-dua pelayan dan pelanggan berjalan pada mesin yang sama, kedua-dua soket gelung balik TCP/IP dan domain unix boleh digunakan. Untuk Linux, menggunakan soket unix boleh menjadi 50% lebih pantas daripada gelung balik TCP/IP. penanda aras redis menggunakan antara muka gelung balik TCP/IP secara lalai.
Faedah soket domain Unix menjadi kurang ketara apabila saluran paip berat digunakan.
Apabila menggunakan sambungan rangkaian dan saiz paket Ethernet kurang daripada 1500 bait, pembungkusan berbilang arahan ke dalam saluran paip boleh meningkatkan kecekapan dengan ketara. Malah, apabila memproses permintaan 10 bait, 100 bait dan 1000 bait, daya pemprosesan adalah hampir sama Lihat rajah di bawah untuk butiran.
Prestasi redis pada pelayan CPU berbilang teras juga bergantung pada konfigurasi NUMA dan kedudukan mengikat pemproses. Kesan paling ketara penanda aras Redis ialah ia menggunakan teras CPU secara rawak. Untuk mendapatkan hasil yang tepat, anda perlu menggunakan alat pemproses tetap (di Linux, anda boleh menggunakan set tugas atau numactl). Cara paling berkesan ialah memisahkan klien dan pelayan kepada dua CPU berbeza untuk menggunakan cache peringkat ketiga. Berikut ialah beberapa penanda aras menggunakan SET data 4 KB, menggunakan konfigurasi berbeza untuk tiga CPU (AMD Istanbul, Intel Nehalem EX dan Intel Westmere). Sila ambil perhatian bahawa ini bukan ujian khusus CPU.
Di bawah konfigurasi yang tinggi, bilangan sambungan pelanggan juga merupakan faktor penting. Gelung acara Redis mendapat manfaat daripada epoll/kqueue dan oleh itu sangat berskala. Redis telah ditanda aras dengan lebih daripada 60,000 sambungan dan masih boleh mengekalkan 50,000 q/s. Peraturan praktikal ialah 30,000 sambungan hanya mempunyai separuh daya pemprosesan 100 sambungan. Di bawah ialah ujian tentang bilangan sambungan dan daya pemprosesan.
在高配置下面，可以通过调优 NIC 来获得更高性能。最高性能在绑定 Rx/Tx 队列和 CPU 内核下面才能达到，还需要开启 RPS（网卡中断负载均衡）。更多信息可以在thread。Jumbo frames 还可以在大对象使用时候获得更高性能。
在不同平台下面，Redis 可以被编译成不同的内存分配方式（libc malloc, jemalloc, tcmalloc），他们在不同速度、连续和非连续片段下会有不一样的表现。若非编译自行进行的 Redis，可用 INFO 命令验证内存分配方式。 请注意，大部分基准测试不会长时间运行来感知不同分配模式下面的差异， 只能通过生产环境下面的 Redis 实例来查看。
任何基准测试的一个重要目标是获得可重现的结果，这样才能将此和其他测试进行对比。
一个好的实践是尽可能在隔离的硬件上面测试。需要检查基准测试是否受到其他服务器活动的影响，如果无法实现的话。
有些配置（桌面环境和笔记本，有些服务器也会）会使用可变的 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% <p>注意：包大小从 256 到 1024 或者 4096 bytes 不会改变结果的量级 （但是到 1024 bytes 后，GETs 操作会变慢）。同样的，50 到 256 客户端的测试结果相同。当使用10个客户端时，总吞吐量无法达到最大吞吐量。</p><p>不同机器可以获的不一样的结果，下面是Intel T5500 1.66 GHz 在 Linux 2.6下面的结果：</p><pre class="brush:php;toolbar:false">$ ./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
Atas ialah kandungan terperinci Bagaimana untuk menyemak parameter penanda aras Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
Perisian pangkalan data yang biasa digunakan
Apakah pangkalan data dalam memori?
Yang manakah mempunyai kelajuan bacaan yang lebih pantas, mongodb atau redis?
Cara menggunakan redis sebagai pelayan cache
Bagaimana redis menyelesaikan ketekalan data
Bagaimanakah mysql dan redis memastikan konsistensi penulisan dua kali?
Apakah data yang biasanya disimpan oleh redis cache?
Apakah 8 jenis data redis
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
