Bagaimana untuk menyemak parameter penanda aras Redis-Redis-php.cn

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>

Salin selepas log masuk

Anda perlu memulakan contoh Redis sebelum menanda aras. Secara umumnya, ujian dimulakan seperti ini:

redis-benchmark -q -n 100000

Salin selepas log masuk

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 .

Jalankan hanya subset beberapa kes ujian

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

Salin selepas log masuk

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 second

Salin selepas log masuk

Pilih saiz julat kekunci ujian

Secara 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

Salin selepas log masuk

Ingat untuk menggunakan pipelining apabila berbilang arahan perlu diproses.

Perangkap dan salah faham

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.

Faktor yang mempengaruhi prestasi Redis

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.

Bagaimana untuk menyemak parameter penanda aras Redis

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.

Bagaimana untuk menyemak parameter penanda aras Redis

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.

Bagaimana untuk menyemak parameter penanda aras Redis

在高配置下面，可以通过调优 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

Salin selepas log masuk

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

Salin selepas log masuk

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

Salin selepas log masuk

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

Salin selepas log masuk

高性能硬件下面的基准测试

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

Salin selepas log masuk

使用 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

Salin selepas log masuk

Atas ialah kandungan terperinci Bagaimana untuk menyemak parameter penanda aras Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!