ceph--磁碟和rbd、rados效能測試工具和方法
我在物理機上建立了5臺虛擬機器，搭建了一個ceph叢集，結構如圖：
具體的安裝步驟參考文件：http://docs.ceph.org.cn/start/
http://www.centoscn.com/CentosServer/test/2015/0521/5489.html
一、磁碟讀寫效能
1. 單個osd磁碟寫效能
[[email protected] osd]# echo 3 > /proc/sys/vm/drop_caches #清除快取頁，目錄項和inodes
注：兩個OSD同時寫效能
[[email protected] osd]# for i in `mount | grep osd | awk '{print $3}'`; do (dd if=/dev/zero of=$i/lrr01 bs=1G count=1 oflag=direct $) ; done
2. 單個OSD同時讀效能
[[email protected] osd]# dd if=/var/lib/ceph/osd/lrr01 of=/dev/null bs=2G count=1 iflag=direct
0+1 records in
0+1 records out
1073741824 bytes (1.1 GB) copied, 7.13509 s, 150 MB/s
注：兩個OSD同時讀效能
[[email protected] osd]# for i in `mount | grep osd | awk '{print $3}'`; do (dd if=$i/lrr01 of=/dev/null bs=1G count=1 iflag=direct &); done
二、CEPH 效能測試方法
ceph效能的測試包括：RADOS效能測試和RBD效能測試；
Rados效能測試工具：使用ceph自帶的rados bench工具、使用rados losd-gen工具；
RBD效能測試工具：rbd bench-write進行塊裝置寫效能測試、fio+rbd ioengine測試、fio +libaio測試。
1. Rados效能測試
1.1 使用ceph自帶的rados bench工具進行測試
該工具的語法是：rados bench -p <pool_name> <seconds> <write|seq|rand> -b <block size> -t --no-cleanup
pool_name：測試所針對的儲存池；
seconds：測試所持續的秒數；
<write|seq|rand>：操作模式，write：寫，seq：順序讀；rand：隨機讀；
-b：block size，即塊大小，預設為 4M；
-t：讀/寫並行數，預設為 16；
--no-cleanup 表示測試完成後不刪除測試用資料。在做讀測試之前，需要使用該引數來執行一遍寫測試來產生測試資料，在全部測試結束後可以執行 rados -p <pool_name> cleanup 來清理所有測試資料。
i 寫測試：
[[email protected] ~]# rados bench -p rbd 10 write --no-cleanup
Maintaining 16 concurrent writes of 4194304 bytes to objects of size 4194304 for up to 10 seconds or 0 objects
Object prefix: benchmark_data_lrr-ceph2_4445
sec Cur ops started finished avg MB/s cur MB/s last lat(s) avg lat(s)
0 0 0 0 0 0 - 0
1 16 16 0 0 0 - 0
2 16 16 0 0 0 - 0
。。。。
17 13 19 6 1.41038 0 - 10.7886
18 13 19 6 1.33207 0 - 10.7886
19 13 19 6 1.26201 0 - 10.7886
Total time run: 19.698032
Total writes made: 19
Write size: 4194304
Object size: 4194304
Bandwidth (MB/sec): 3.85825
Stddev Bandwidth: 0.551976
Max bandwidth (MB/sec): 1.71429
Min bandwidth (MB/sec): 0
Average IOPS: 0
Stddev IOPS: 0
Max IOPS: 0
Min IOPS: 0
Average Latency(s): 15.5797
Stddev Latency(s): 5.09105
Max latency(s): 19.6971
Min latency(s): 5.51094
ii 順序讀測試：
iii 隨機讀測試：
1.2 rados load-gen 工具
該工具的語法為：
# rados -p rbd load-gen --num-objects 初始生成測試用的物件數，預設 200 --min-object-size 測試物件的最小大小，預設 1KB，單位byte --max-object-size 測試物件的最大大小，預設 5GB，單位byte --min-op-len 壓測IO的最小大小，預設 1KB，單位byte --max-op-len 壓測IO的最大大小，預設 2MB，單位byte --max-ops 一次提交的最大IO數，相當於iodepth --target-throughput 一次提交IO的歷史累計吞吐量上限，預設 5MB/s，單位B/s --max-backlog 一次提交IO的吞吐量上限，預設10MB/s，單位B/s --read-percent 讀寫混合中讀的比例，預設80，範圍[0, 100] --run-length 執行的時間，預設60s，單位秒
在 ceph1上執行
rados -p pool100 load-gen --read-percent 0 --min-object-size 1073741824 --max-object-size 1073741824 --max-ops 1 --read-percent 0 --min-op-len 4194304 --max-op-len 4194304 --target-throughput 1073741824 --max_backlog 1073741824
的結果為：
WRITE : oid=obj-y0UPAZyRQNhnabq off=929764660 len=4194304 op 19 completed, throughput=16MB/sec WRITE : oid=obj-nPcOZAc4ebBcnyN off=143211384 len=4194304 op 20 completed, throughput=20MB/sec WRITE : oid=obj-sWGUAzzASPjCcwF off=343875215 len=4194304 op 21 completed, throughput=24MB/sec WRITE : oid=obj-79r25fxxSMgVm11 off=383617425 len=4194304 op 22 completed, throughput=28MB/sec
該命令的含義是：在 1G 的物件上，以 iodepth = 1 順序寫入 block size 為 4M 的總量為 1G 的資料。其平均結果大概在 24MB/s，基本和 rados bench 的結果相當。
在 client 上，同樣的配置，順序寫的BW大概在 20MB/s，順序讀的 BW 大概在 100 MB/s。
可見，與 rados bench 相比，rados load-gen 的特點是可以產生混合型別的測試負載，而 rados bench 只能產生一種型別的負載。但是 load-gen 只能輸出吞吐量，只合適做類似於 4M 這樣的大block size 資料測試，輸出還不包括延遲。
2 rbd效能測試
2.1 使用rbd bench-write 進行塊裝置寫效能測試
2.1.1 客戶端準備
在執行如下命令來準備 Ceph 客戶端：
[email protected]:/var# rbd create bd2 --size 1024 [email protected]:/var# rbd info --image bd2 rbd image 'bd2': size 1024 MB in 256 objects order 22 (4096 kB objects) block_name_prefix: rb.0.3841.74b0dc51 format: 1 [email protected]:/var# rbd map bd2 [email protected]:/var# rbd showmapped id pool image snap device 1 pool1 bd1 - /dev/rbd1 2 rbd bd2 - /dev/rbd2 [email protected]:/var# mkfs.xfs /dev/rbd2 log stripe unit (4194304 bytes) is too large (maximum is 256KiB) log stripe unit adjusted to 32KiB meta-data=/dev/rbd2 isize=256 agcount=9, agsize=31744 blks = sectsz=512 attr=2, projid32bit=0 data = bsize=4096 blocks=262144, imaxpct=25 = sunit=1024 swidth=1024 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=8 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 [email protected]:/var# mkdir -p /mnt/ceph-bd2 [email protected]:/var# mount /dev/rbd2 /mnt/ceph-bd2/ [email protected]:/var# df -h /mnt/ceph-bd2/ Filesystem Size Used Avail Use% Mounted on /dev/rbd2 1014M 33M 982M 4% /mnt/ceph-bd2
2.1.2 測試
rbd bench-write 的語法為：rbd bench-write <RBD image name>，可以帶如下引數：
- --io-size：單位 byte，預設 4096 bytes = 4K
- --io-threads：執行緒數，預設 16
- --io-total：總寫入位元組，單位為位元組，預設 1024M
- --io-pattern <seq|rand>：寫模式，預設為 seq 即順序寫
分別在叢集 OSD 節點上和客戶端上做測試：
（1）在 OSD 節點上做測試
[email protected]:~# rbd bench-write bd2 --io-total 171997300 bench-write io_size 4096 io_threads 16 bytes 171997300 pattern seq SEC OPS OPS/SEC BYTES/SEC 1 280 273.19 2237969.65 2 574 286.84 2349818.65 ... 71 20456 288.00 2358395.28 72 20763 288.29 2360852.64 elapsed: 72 ops: 21011 ops/sec: 288.75 bytes/sec: 2363740.27
此時，塊大小為 4k，IOPS 為 289，BW 為 2.36 MB/s （怎麼 BW 是 block_size * IOPS 的兩倍呢？）。
（2）在客戶端上做測試
[email protected]:/home/s1# rbd bench-write pool.host/image.ph2 --io-total 1719973000 --io-size 4096000 bench-write io_size 4096000 io_threads 16 bytes 1719973000 pattern seq SEC OPS OPS/SEC BYTES/SEC 1 5 3.41 27937685.86 2 19 9.04 68193147.96 3 28 8.34 62237889.75 5 36 6.29 46538807.31 ... 39 232 5.86 40792216.64 40 235 5.85 40666942.19 elapsed: 41 ops: 253 ops/sec: 6.06 bytes/sec: 41238190.87
此時 block size 為 4M，IOPS 為 6， BW 為 41.24 MB/s。
[email protected]:/home/s1# rbd bench-write pool.host/image.ph2 --io-total 1719973000 bench-write io_size 4096 io_threads 16 bytes 1719973000 pattern seq SEC OPS OPS/SEC BYTES/SEC 1 331 329.52 2585220.17 2 660 329.57 2521925.67 3 1004 333.17 2426190.82 4 1331 332.26 2392607.58 5 1646 328.68 2322829.13 6 1986 330.88 2316098.66
此時 block size 為 4K，IOPS 為 330 左右， BW 為 24 MB/s 左右。
備註：從 rbd bench-write vs dd performance confusion 中看起來，rados bench-write 似乎有bug。我所使用的Ceph 是0.80.11 版本，可能補丁還沒有合進來。
2 使用fio+rbd ioengine
執行 apt-get install fio 來安裝 fio 工具。建立 fio 配置檔案：
[email protected]:/home/s1# cat write.fio [write-4M] description="write test with block size of 4M" ioengine=rbd clientname=admin pool=rbd rbdname=bd2 iodepth=32 runtime=120 rw=write #write 表示順序寫，randwrite 表示隨機寫，read 表示順序讀，randread 表示隨機讀 bs=4M
執行 fio 命令，但是出錯：
[email protected]:/home/s1# fio write.fio fio: engine rbd not loadable fio: failed to load engine rbd Bad option <clientname=admin> Bad option <pool=rbd> Bad option <rbdname=bd2> fio: job write-4M dropped fio: file:ioengines.c:99, func=dlopen, error=rbd: cannot open shared object file: No such file or directory
其原因是因為沒有安裝 fio librbd IO 引擎，因此當前 fio 無法支援 rbd ioengine：
[email protected]:/home/s1# fio --enghelp Available IO engines: cpuio mmap sync psync vsync pvsync null net netsplice libaio rdma posixaio falloc e4defrag splice sg binject
在執行 apt-get install librbd-dev 命令安裝 librbd 後，fio 還是報同樣的錯誤。參考網上資料，下載 fio 程式碼重新編譯 fio：
$ git clone git://git.kernel.dk/fio.git $ cd fio $ ./configure [...] Rados Block Device engine yes [...] $ make
此時 fio 的 ioengine 列表中也有 rbd 了。fio 使用 rbd IO 引擎後，它會讀取 ceph.conf 中的配置去連線 Ceph 叢集。
下面是 fio 命令和結果：
[email protected]:/home/s1/fio# ./fio ../write.fio write-4M: (g=0): rw=write, bs=4M-4M/4M-4M/4M-4M, ioengine=rbd, iodepth=32 fio-2.11-12-g82e6 Starting 1 process rbd engine: RBD version: 0.1.8 Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/128.0MB/0KB /s] [0/32/0 iops] [eta 00m:00s] write-4M: (groupid=0, jobs=1): err= 0: pid=19190: Sat Jun 4 22:30:00 2016 Description : ["write test with block size of 4M"] write: io=1024.0MB, bw=17397KB/s, iops=4, runt= 60275msec slat (usec): min=129, max=54100, avg=1489.10, stdev=4907.83 clat (msec): min=969, max=15690, avg=7399.86, stdev=1328.55 lat (msec): min=969, max=15696, avg=7401.35, stdev=1328.67 clat percentiles (msec): | 1.00th=[ 971], 5.00th=[ 6325], 10.00th=[ 6325], 20.00th=[ 6521], | 30.00th=[ 6718], 40.00th=[ 7439], 50.00th=[ 7439], 60.00th=[ 7635], | 70.00th=[ 7832], 80.00th=[ 8291], 90.00th=[ 8356], 95.00th=[ 8356], | 99.00th=[14615], 99.50th=[15664], 99.90th=[15664], 99.95th=[15664], | 99.99th=[15664] bw (KB /s): min=245760, max=262669, per=100.00%, avg=259334.50, stdev=6250.72 lat (msec) : 1000=1.17%, >=2000=98.83% cpu : usr=0.24%, sys=0.03%, ctx=50, majf=0, minf=8 IO depths : 1=2.3%, 2=5.5%, 4=12.5%, 8=25.0%, 16=50.4%, 32=4.3%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=97.0%, 8=0.0%, 16=0.0%, 32=3.0%, 64=0.0%, >=64=0.0% issued : total=r=0/w=256/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0 latency : target=0, window=0, percentile=100.00%, depth=32 Run status group 0 (all jobs): WRITE: io=1024.0MB, aggrb=17396KB/s, minb=17396KB/s, maxb=17396KB/s, mint=60275msec, maxt=60275msec Disk stats (read/write): sda: ios=0/162, merge=0/123, ticks=0/19472, in_queue=19472, util=6.18%
如果 iodepth = 1 的話，結果是：
[email protected]:/home/s1# fio/fio write.fio.dep1 write-4M: (g=0): rw=write, bs=4M-4M/4M-4M/4M-4M, ioengine=rbd, iodepth=1 fio-2.11-12-g82e6 Starting 1 process rbd engine: RBD version: 0.1.8 Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/8192KB/0KB /s] [0/2/0 iops] [eta 00m:00s] write-4M: (groupid=0, jobs=1): err= 0: pid=19250: Sat Jun 4 22:33:11 2016 Description : ["write test with block size of 4M"] write: io=1024.0MB, bw=20640KB/s, iops=5, runt= 50802msec
3 使用fio+libaio進行測試
libaio 是 Linux native asynchronous I/O。
幾種測試模式：
隨機寫：
fio/fio -filename=/mnt/ceph-rbd2 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=libaio -bs=4M -size=1G -numjobs=1 -runtime=120 -group_reporting -name=read-libaio
這些引數的含義是：
filename：表示待測試的裝置名稱。
iodepth： libaio 會用這個 iodepth 值來呼叫 io_setup 準備個可以一次提交 iodepth 個 IO 的上下文，同時申請個io請求佇列用於保持IO。
iodepth_batch：在壓測進行的時候，系統會生成特定的IO請求，往io請求佇列裡面扔，當佇列裡面的IO個數達到 iodepth_batch 值的時候，
iodepth_batch_complete 和 iodepth_low： 呼叫 io_submit 批次提交請求，然後開始呼叫 io_getevents 開始收割已經完成的IO。 每次收割多少呢？由於收割的時候，超時時間設定為0，所以有多少已完成就算多少，最多可以收割 iodepth_batch_complete 值個。隨著收割，IO佇列裡面的IO數就少了，那麼需要補充新的IO。 什麼時候補充呢？當IO數目降到 iodepth_low 值的時候，就重新填充，保證 OS 可以看到至少 iodepth_low 數目的io在電梯口排隊著。
[email protected]:/home/s1# fio/fio -filename=/mnt/ceph-rbd2 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=libaio -bs=4M -size=1G -numjobs=1 -runtime=120 -group_reporting -name=read-libaio read-libaio: (g=0): rw=randwrite, bs=4M-4M/4M-4M/4M-4M, ioengine=libaio, iodepth=1 fio-2.11-12-g82e6 Starting 1 thread Jobs: 1 (f=1): [w(1)] [100.0% done] [0KB/94302KB/0KB /s] [0/23/0 iops] [eta 00m:00s] read-libaio: (groupid=0, jobs=1): err= 0: pid=20256: Sun Jun 5 10:00:55 2016 write: io=1024.0MB, bw=102510KB/s, iops=25, runt= 10229msec slat (usec): min=342, max=5202, avg=1768.90, stdev=1176.00 clat (usec): min=332, max=165391, avg=38165.11, stdev=27987.64 lat (msec): min=3, max=167, avg=39.94, stdev=28.00 clat percentiles (msec): | 1.00th=[ 8], 5.00th=[ 18], 10.00th=[ 19], 20.00th=[ 20], | 30.00th=[ 22], 40.00th=[ 25], 50.00th=[ 29], 60.00th=[ 31], | 70.00th=[ 36], 80.00th=[ 47], 90.00th=[ 83], 95.00th=[ 105], | 99.00th=[ 123], 99.50th=[ 131], 99.90th=[ 165], 99.95th=[ 165], | 99.99th=[ 165] bw (KB /s): min=32702, max=172032, per=97.55%, avg=99999.10, stdev=36075.23 lat (usec) : 500=0.39% lat (msec) : 4=0.39%, 10=0.39%, 20=21.48%, 50=57.81%, 100=14.45% lat (msec) : 250=5.08% cpu : usr=0.62%, sys=3.65%, ctx=316, majf=0, minf=9 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=0/w=256/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0 latency : target=0, window=0, percentile=100.00%, depth=1 Run status group 0 (all jobs): WRITE: io=1024.0MB, aggrb=102510KB/s, minb=102510KB/s, maxb=102510KB/s, mint=10229msec, maxt=10229msec Disk stats (read/write): sda: ios=0/1927, merge=0/1, ticks=0/30276, in_queue=30420, util=98.71%
隨機讀：fio/fio -filename=/mnt/ceph-rbd2 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=libaio -bs=4M -size=1G -numjobs=1 -runtime=120 - group_reporting -name=read-libaio 順序寫：fio/fio -filename=/mnt/ceph-rbd2 -direct=1 -iodepth 1 -thread -rw=write -ioengine=libaio -bs=4M -size=1G -numjobs=1 -runtime=120 -group_reporting -name=read-libaio 隨機寫：fio/fio -filename=/mnt/ceph-rbd2 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=libaio -bs=4M -size=1G -numjobs=1 -runtime=120 -group_reporting -name=read-libaio
三、總結
1 測試工具小結
| 工具 | 用途 | 語法 | 說明 |
| rados bench | RADOS 效能測試工具 | rados bench -p <pool_name> <seconds> <write|seq|rand> -b <block size> -t --no-cleanup |
|
| rados load-gen | RADOS 效能測試工具 |
# rados -p rbd load-gen --num-objects #產生的物件數目 --min-object-size #最小物件大小 --max-object-size #最大物件大小 --max-ops #最大運算元目 --min-op-len #最小操作長度 --max-op-len #最大操作長度 --read-percent #讀操作的百分比 --target-throughput #目標吞吐量，單位 MB --run-length #執行時長，單位秒 |
|
| rbd bench-write | ceph 自帶的 rbd 效能測試工具 |
rbd bench-write <RBD image name>
|
|
| fio + rbd ioengine | fio 結合 rbd IO 引擎的效能測試工具 | 參考 fio --help |
|
| fio + libaio | fio 結合 linux aio 的 rbd 效能測試 |
2 測試結果比較
所使用的命令：
-
- rbd bench-write pool.host/image.ph2 --io-total 1719973000 --io-size 4096000 --io-threads 1 --io-pattern rand/seq
- rados -p pool.host bench 20 write -t 1 --no-cleanup
- rados -p pool100 load-gen --read-percent 0 --min-object-size 1073741824 --max-object-size 1073741824 --max-ops 1 --read-percent 0/100 --min-op-len 4194304 --max-op-len 4194304 --target-throughput 1073741824 --max_backlog 1073741824
- ceph tell osd.0 bench
- fio/fio -filename=/dev/rbd4 -direct=1 -iodepth 1 -thread -rw=write/read/randwrite/randread -ioengine=libaio -bs=4M -size=1G -numjobs=1 -runtime=1800 -group_reporting -name=read-libaio
結果（僅在作者的測試環境的客戶端節點上執行以上命令的輸出）：
| 操作 | dd 一個 OSD | dd 兩個 OSD | rados load-gen | rados bench | rbd bench-write | ceph tell osd.0 bench | fio + rbd | fio + libaio |
| 順序寫 | 165 | 18 | 18 | 18 | 74 MB/s （IOPS 9） |
40 MB/s |
21 （iops 5） | 18（iops 4） |
| 隨機寫 | 67.8 MB/s （IOPS 8） | 19 （iops 4） | 16（iops 4） | |||||
| 順序讀 | 460 | 130 | 100 | 109 | N/A | 111（iops 27） | 111（iops 27） | |
| 隨機讀 | 112 | N/A | 115（iops 28） | 128（iops 31） |
簡單結論（由於環境、測試方法和資料有限，這些結論不一定正確，有些只是猜測，需要進一步研究，僅供參考）：
-
- rados bench 和在兩個 OSD 上同時做 dd 的效能差不多。
- fio + rbd 和 fio + libaio 的結果差不多，相比之下 fio + rbd 還要好一點點。
- fio 順序寫和讀的 BW 和兩個 OSD 同時寫和讀的 BW 差不多。
- fio 順序寫的 BW 差不多是 單個 OSD 的 bench 的一半 （因為我的 pool 的 size 為 2）。
- rados load-gen，rodos bench 和 fio rbd/libaio 的結果都差不多，可見都可以信任，只是每一種都有其特長，選擇合適你的測試應用場景的某個即可。
參考連結：
http://tracker.ceph.com/projects/ceph/wiki/Benchmark_Ceph_Cluster_Performance
Ceph Performance Analysis: fio and RBD
http://www.quts.me/page2/
http://events.linuxfoundation.org/sites/events/files/slides/Vault-2015.pdf
http://www.cnblogs.com/sammyliu/p/5557666.html
相關推薦
ceph--磁碟和rbd、rados效能測試工具和方法
我在物理機上建立了5臺虛擬機器，搭建了一個ceph叢集，結構如圖： 具體的安裝步驟參考文件：http://docs.ceph.org.cn/start/ http://www.centoscn.c
Apache AB效能測試工具使用方法簡介
這篇文章主要介紹了Apache AB效能測試工具使用教程,本文重點講解測試結果中的一些引數,對引數的含義一一解釋,需要的朋友可以參考下 伺服器負載太大而影響程式效率是很常見的，Apache伺服器自帶有一個叫ab(ApacheBench)的工具，在bin目錄下。ab專門用於HTTP Serve
系統吞吐量（TPS）、使用者併發量、效能測試概念和公式【轉】
PS：下面是效能測試的主要概念和計算公式，記錄下： 原文傳送門 一．系統吞度量要素： 一個系統的吞度量（承壓能力）與request對CPU的消耗、外部介面、IO等等緊密關聯。 單個reqeust 對CPU消耗越高，外部系統介面、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量（TPS）、使用者併發量、效能測試概念和公式
系統的吞吐量與請求對CPU的消耗，伺服器記憶體使用，IO等都有關係。 系統吞吐量幾個重要引數：QPS(TPS)、併發數、響應時間 QPS(TPS)：每秒處理的請求數 併發數：同時處理的請求數 響應時間：平均響應時間 三者的關係：QPS(TPS)=併發數/平均響應
系統吞吐量、TPS（QPS）、使用者併發量、效能測試概念和公式
PS：下面是效能測試的主要概念和計算公式，記錄下： 一．系統吞度量要素： 一個系統的吞度量（承壓能力）與request對CPU的消耗、外部介面、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統介面、IO影響速度越慢，系統吞吐能力越低，反之越高。 系統
[乾貨]系統吞吐量（TPS）、使用者併發量、效能測試概念和公式
在淘寶環境下，假設我們壓力測試出的TPS為100，那麼這個系統的日吞吐量=100*11*3600=396萬 這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際吞吐量還要小 無論有無思考時間（T_think），測試所得的TPS值和
效能測試--系統吞吐量（TPS）、使用者併發量、效能測試概念和公式
PS：下面是效能測試的主要概念和計算公式，記錄下： 一．系統吞度量要素： 一個系統的吞度量（承壓能力）與request對CPU的消耗、外部介面、IO等等緊密關聯。 單個reqeust 對CPU消耗越高，外部系統介面、IO影響速度越慢，系統吞吐能力越低，反之越高。 系統吞吐量幾個重要引數：QPS
1、接口測試概要和http基礎亂抄篇
錯誤 性能 返回 存儲 並且 邊界值 技術分享 電商 請求 一、接口測試的要點： 圖片是抄襲的，但是自己還是要總結下要點： 1、檢查接口返回的數據是否與預期的一致； 2、檢查接口的容錯性，驗證傳遞錯誤的數據類型時，能否正常的處理； 3、接口參數的邊界值；
系統吞吐量、TPS（QPS）、用戶並發量、性能測試概念和公式
可用 運算 連接數 高性能 表示 行數據 itl 不知道 進行 PS：以下是性能測試的主要概念和計算公式，記錄下： 一．系統吞度量要素： 一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。單個reqeust
系統吞吐量、TPS（QPS）、用戶並發量、性能測試概念和公式(分享二十二）
開始 其他 淘寶 分享圖片 項目計劃 基本概念 post 淘寶流量 日誌 一．系統吞度量要素： 一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低
系統吞吐量（TPS）、用戶並發量、性能測試概念和公式
而在 ssi 情況 它的 jdb nes bean 並發連接 eth 一．系統吞度量要素： 一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。 單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越
網站效能測試工具 webbench 的安裝和使用
1.webbench的下載和安裝 wget http://home.tiscali.cz/~cz210552/distfiles/webbench-1.5.tar.gz sudo tar xvf webbench-1.5.tar.gz -C /usr/local/ cd /usr/l
JMeter全程實戰、效能測試實戰、分散式效能測試、真實案例分析
測試需求描述 1、 本次測試的介面為http服務端介面 2、 介面的主要分成兩類，一類提供給查詢功能介面，一類提供儲存資料功能介面，這裡我們舉例2個儲存資料的介面，因為這兩個介面有關聯 性，比較有代表性； 儲存信用卡賬戶資訊介面： 傳入引數： args={ "clientNo":"43434
Jmeter效能測試工具學習（Jmeter中的函式和BeanShell）
函式 loadrunner中的函式 Jmeter中的函式 1）函式格式 ${__functionName(var1,var2,var3)} 2）如果函式沒有引數，那可以沒有括號 例如 ${__threadNum} 例子： BeanShell
Jmeter效能測試工具學習（4.指令碼組成和元件搭配）
Jmter指令碼開發原則 簡單：不要無用、無關的元件，同時能複用的儘量複用。比如：HTTP Request Ddfauits公共元件 正確：對指令碼或者業務正確性進行必要的判斷，不能少也不能多。（返回200） 高效：部分 元件僅僅使用在指令碼開發模式下，在真正生產環境下不要使用 。
效能測試工具VTune的功能和用法介紹
1.VTune介紹 VTune視覺化效能分析器（Intel VTune Performance Analyzer）是一個用於分析和優化程式效能的工具，作為Intel為開發者提供的專門針對尋找軟硬體效能瓶頸的一款分析工具，它能確定程式的熱點（hotspot），找
GCC高階測試功能擴充套件——程式效能測試工具gprof、程式覆蓋測試工具gcov
很多年前將伺服器程式碼從Windows移植到Linux時，用過gprof進行過優化，非常有幫助。時隔多年，為了保留記憶，轉一下這篇文章。 gprof是GNU組織下的一個比較有用的效能測試功能： 主要功能： 找出應用程式中消耗CPU時間最多的函式；
Qt總結之三：磁碟檔案操作、遍歷資料夾和檔案目錄，並過濾和獲取檔案資訊、字尾名、字首名（三）
前言 本節內容主要包括磁碟容量檢測、磁碟內指定或特定檔案的操作 話不多說，先上效果圖 共分為兩個部分，第一部分是檢測磁碟容量，第二部分是篩選磁碟內指定檔案(test.txt)或特定檔案(.txt / .png型別檔案) 獲取磁碟容量關鍵函式：【fileapi.h】
效能測試學習和效能瓶頸分析路線
做效能測試已經有一兩年時間了，一直都在胡亂碰撞，東學西學，都是一些表面的東西，很少想過把它們連貫起來。今天根據自己的理解寫一下效能測試到一定階段需要站到一個什麼樣子的高度去看待效能這個問題。 很多企業招聘都只寫效能測試，會使用LR，jmeter工具。其
MongoDB與MySQL的插入、查詢效能測試
1. 背景介紹 1.1 MongoDB的簡單介紹 在當今的資料庫市場上，MySQL無疑是佔有一席之地的。作為一個開源的關係型資料庫，MySQL被大量應用在各大網站後臺中，承擔著資訊儲存的重要作用。2009年，甲骨文公司（Oracle）收購Sun公司，MySQL成為Orac