雲上關鍵業務測試及性能調優
原文鏈接 https://yq.aliyun.com/articles/632653?spm=a2c4e.11155435.0.0.a5a43312pX2g7n
1、 負載均衡選型及性能指標
負載均衡推薦使用性能保障性實例，它於性能共享型實例相比較，共享型負載均衡的資源是共享的，所以不能保障實例的性能指標。因爲車聯網的行業特點就是高併發場景推薦使用性能保障性實例。性能保障型實例的三個關鍵指標如下：
• 最大連接數-Max Connection
最大連接數定義了一個負載均衡實例能夠承載的最大連接數量。當實例上的連接超過規格定義的最大連接數時，新建連接請求將被丟棄。
• 每秒新建連接數-Connection Per Second (CPS)
每秒新建連接數定義了新建連接的速率。當新建連接的速率超過規格定義的每秒新建連接數時，新建連接請求將被丟棄。
• 每秒查詢數-Query Per Second (QPS)
每秒請求數是七層監聽特有的概念，指的是每秒可以完成的HTTP/HTTPS的查詢（請求）的數量。當請求速率超過規格所定義的每秒查詢數時，新建連接請求將被丟棄。
阿里雲負載均衡性能保障型實例開放了如下六種實例規格（各地域因資源情況不同，開放的規格可能略有差異，請以控制檯購買頁爲準）。
規格 最大連接數 每秒新建連接數 (CPS) 每秒查詢數(QPS)
規格 1 簡約型I (slb.s1.small) 5,000 3,000
規格 2 標準型I (slb.s2.small) 50,000 5,000
規格 3 標準型II (slb.s2.medium) 100,000 10,000
規格 4 高階型I (slb.s3.small) 200,000 20,000
規格 5 高階型II (slb.s3.medium) 500,000 50,000
規格 6 超強型I (slb.s3.large) 1,000,000 100,000
規格 最大連接數 每秒新建連接數 (CPS) 每秒查詢數(QPS)
_2018_08_31_5_16_02
注意：以上規格是在控制檯裏可以購買的，可以發現最大規格也就只有100w連接。但如果千萬級的車聯網企業，它的負載均衡最大連接能力要求達到1000w的時候怎麼辦？在控制檯買不到怎麼辦？彆着急，阿里雲雖然只在官網控制檯裏開放了6種規格實例給普通中小企業用戶。但是針對有更大規格要求的企業用戶可以通過聯繫阿里雲客戶經理來定製更高規格的負載均衡實例，最高可提供億級別最大連接數能力。
因爲性能保障性實例在最大連接數，每秒連接數，每秒查詢數等指標官方都有明確的SLA，所以我們這裏就不去測試了，平時的使用過程中可以通過雲監控實時觀察各項性能指標。
併發連接數監控
image107
新建連接監控
image108
QPS監控
image109
2、ECS選型及性能測試
雲服務器Elastic Compute Service（ECS）是阿里雲提供的一種基礎雲計算服務。使用雲服務器ECS就像使用水、電、煤氣等資源一樣便捷、高效。無需提前採購硬件設備，而是根據業務需要，隨時創建所需數量的雲服務器ECS實例。在使用過程中，隨着業務的擴展，可以隨時擴容磁盤、增加帶寬。如果不再需要雲服務器，也能隨時釋放資源，節省費用。
ECS選型，可以根據不同應用場景來選擇相應的ECS實例規格，如果不知怎麼選擇，可以參考官網的建議：
image110
image111
阿里雲ECS針對不同的應用場景推出了不同實例規格，極大的豐富了用戶多樣化需求。
針對物聯網行業特性，高併發，高吞吐等特點，建議web前端選擇計算型（C5）機型，實例規格推薦4核8g，推薦系統盤SSD雲盤；後端應用推薦使用通用型（g5）機型，實例規格推薦4核16g，推薦系統盤SSD雲盤。
image112
接下來我們測試一下其中一款實例的性能，例如通用型g5的4核16g SSD系統盤，操作系統爲centos6.8
測試分爲兩部分，一是針對CPU 的跑分測試，另一個是針對SSD系統盤的IOPS測試。
1） 性能跑分測試
登錄阿里雲控制檯，購買通用型g5,4核16gECS實例
image
登錄服務器，驗證下機器配置4核16G
image_jpeg
安裝測試工具Unixbench，安裝過程如下
安裝過程
http://soft.laozuo.org/scripts/UnixBench5.1.3.tgz
tar xf UnixBench5.1.3.tgz
cd UnixBench
make
./Run 安裝過程出錯：
Can’t locate Time/HiRes.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at ./Run line 6.
BEGIN failed–compilation aborted at ./Run line 6.
解決辦法：yum install perl-Time-HiRes -y
如果出現bash: make: command not found問題
解決辦法：yum -y install gcc automake autoconf libtool make
測試截圖
image
總結：最終跑分測試爲3911.9，通常4核8G臺式機這個分數爲2100. 由此可見阿里雲這款實例性能還是挺強的幾乎是臺式機的2倍。
2） SSD雲盤性能測試
IOPS是Input/Output Operations per Second，即每秒能處理的I/O個數，用於表示塊存儲處理讀寫（輸出/輸入）的能力。如果要部署事務密集型應用，需要關注IOPS性能。
官網公佈的SSD雲盤SLA爲：
_2018_08_31_5_26_54
針對Linux操作系統可以使用DD、fio或sysbench等工具測試塊存儲性能。
下面用fio工具測試下通用型g5的4核16g系統盤爲SSD雲盤實例的IPOS能力：
警告：
測試裸盤可以獲得真實的塊存儲盤性能，但直接測試裸盤會破壞文件系統結構，請在測試前提前做好數據備份。建議只在新購無數據的ECS實例上使用工具測試塊存儲性能，避免造成數據丟失。
登錄服務器並安裝測試命令fio
測試隨機寫IOPS，運行以下命令：
fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Write_Testing
測試隨機讀IOPS，運行以下命令：
fio -direct=1 -iodepth=128 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Read_Testing
測試順序寫吞吐量，運行以下命令：
fio -direct=1 -iodepth=64 -rw=write -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Write_PPS_Testing
測試順序寫吞吐量，運行以下命令：
fio -direct=1 -iodepth=64 -rw=write -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Write_PPS_Testing
下表以測試隨機寫IOPS的命令爲例，說明命令中各種參數的含義。
_2018_08_31_5_29_28
以下以一塊SSD雲盤隨機讀IOPS性能的測試結果爲例，說明如何理解fio測試結果。
Rand_Read_Testing: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=128
fio-2.2.8
Starting 1 process
Jobs: 1 (f=1): [r(1)] [21.4% done] [80000KB/0KB/0KB /s] [20.0K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [28.6% done] [80000KB/0KB/0KB /s] [20.0K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [35.7% done] [80000KB/0KB/0KB /s] [20.0K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [42.9% done] [80004KB/0KB/0KB /s] [20.1K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [50.0% done] [80004KB/0KB/0KB /s] [20.1K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [57.1% done] [80000KB/0KB/0KB /s] [20.0K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [64.3% done] [80144KB/0KB/0KB /s] [20.4K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [71.4% done] [80388KB/0KB/0KB /s] [20.1K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [78.6% done] [80232KB/0KB/0KB /s] [20.6K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [85.7% done] [80260KB/0KB/0KB /s] [20.7K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [92.9% done] [80016KB/0KB/0KB /s] [20.4K/0/0 iops] [eta 00Jobs: 1 (f=1): [r(1)] [100.0% done] [80576KB/0KB/0KB /s] [20.2K/0/0 iops] [eta 00m:00s]
Rand_Read_Testing: (groupid=0, jobs=1): err= 0: pid=9845: Tue Sep 26 20:21:01 2017
read : io=1024.0MB, bw=80505KB/s, iops=20126, runt= 13025msec
slat (usec): min=1, max=674, avg= 4.09, stdev= 6.11
clat (usec): min=172, max=82992, avg=6353.90, stdev=19137.18
lat (usec): min=175, max=82994, avg=6358.28, stdev=19137.16
clat percentiles (usec):
| 1.00th=[ 454], 5.00th=[ 668], 10.00th=[ 812], 20.00th=[ 996],
| 30.00th=[ 1128], 40.00th=[ 1256], 50.00th=[ 1368], 60.00th=[ 1480],
| 70.00th=[ 1624], 80.00th=[ 1816], 90.00th=[ 2192], 95.00th=[79360],
| 99.00th=[81408], 99.50th=[81408], 99.90th=[82432], 99.95th=[82432],
| 99.99th=[82432]
bw (KB /s): min=79530, max=81840, per=99.45%, avg=80064.69, stdev=463.90
lat (usec) : 250=0.04%, 500=1.49%, 750=6.08%, 1000=12.81%
lat (msec) : 2=65.86%, 4=6.84%, 10=0.49%, 20=0.04%, 100=6.35%
cpu : usr=3.19%, sys=10.95%, ctx=23746, majf=0, minf=160
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%
issued : total=r=262144/w=0/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=128
Run status group 0 (all jobs):
READ: io=1024.0MB, aggrb=80504KB/s, minb=80504KB/s, maxb=80504KB/s, mint=13025msec, maxt=13025msec
Disk stats (read/write):
vdb: ios=258422/0, merge=0/0, ticks=1625844/0, in_queue=1625990, util=99.30%
輸出結果中，主要關注以下這行內容：
read : io=1024.0MB, bw=80505KB/s, iops=20126, runt= 13025msec
表示fio做了1 GiB I/O，速率約爲80 MiB/s，總IOPS爲20126，運行時間爲13秒。由IOPS值可知，該SSD雲盤的IOPS性能爲 20126，而根據公式計算的數值爲：
min{1200+30 容量, 20000} = min{1200+30 800, 20000} = 20000
測試結果與公式計算結果相近。
3、數據庫RDS測試及調優
雲數據庫RDS是一種穩定可靠、可彈性伸縮的在線數據庫服務。基於飛天分佈式系統和全SSD盤高性能存儲，支持MySQL、SQL Server、PostgreSQL和PPAS（高度兼容Oracle）引擎，默認部署主備架構且提供了容災、備份、恢復、監控、遷移等方面的全套解決方案，徹底解決數據庫運維的煩惱。
1) RDS MySQL 版測試
今天我們基於阿里雲RDS MySQL5.6版本進行一個性能測試。
a) 測試環境
所有測試均在華東2（上海）地域的可用區B完成。
測試用的ECS爲系列II實例。
實例配置爲8核16GB。
網絡類型爲經典網絡。
壓測用的鏡像爲CentOS 7.0 64位。
b) 測試工具
SysBench是一個跨平臺且支持多線程的模塊化基準測試工具，用於評估系統在運行高負載的數據庫時相關核心參數的性能表現。它目的是爲了繞過複雜的數據庫基準設置，甚至在沒有安裝數據庫的前提下，快速瞭解數據庫系統的性能。
安裝方法
本文用的SysBench版本爲0.5
執行如下命令安裝SysBench
yum install gcc gcc-c++ autoconf automake make libtool bzr mysql-devel
unzip ysbench-0.5.zip
cd sysbench-0.5
./autogen.sh
./configure –prefix=/usr –mandir=/usr/share/man
make
make install
c) 測試
準備數據
sysbench –num-threads=32 –max-time=3600 –max-requests=999999999 –test= oltp.lua –oltp-table-size=10000000 –oltp-tables-count=64 –db-driver=mysql –mysql-table-engine=innodb –mysql-host= XXXX –mysql-port=3306 –mysql-user= XXXX –mysql-password= XXXX prepare
壓測性能
sysbench –num-threads=32 –max-time=3600 –max-requests=999999999 –test= oltp.lua –oltp-table-size=10000000 –oltp-tables-count=64 –db-driver=mysql –mysql-table-engine=innodb –mysql-host= XXXX –mysql-port=3306 –mysql-user= XXXX –mysql-password= XXXX run
清理環境
sysbench –num-threads=32 –max-time=3600 –max-requests=999999999 –test= oltp.lua –oltp-table-size=10000000 –oltp-tables-count=64 –db-driver=mysql –mysql-table-engine=innodb –mysql-host= XXXX –mysql-port=3306 –mysql-user= XXXX –mysql-password= XXXX cleanup
d) 測試模型
庫表結構
CREATE TABLE sbtest (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
k int(10) unsigned NOT NULL DEFAULT ‘0’,
c char(120) NOT NULL DEFAULT ”,
pad char(60) NOT NULL DEFAULT ”,
PRIMARY KEY (id),
KEY k_1 (k)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
數據格式
id: 1
k: 3718516
c:08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977
pad: 63188288836-92351140030-06390587585-66802097351-49282961843
SQL樣式
查詢：
SELECT c FROM sbtest64 WHERE id=4957216
SELECT c FROM sbtest43 WHERE id BETWEEN 4573346 AND 4573346+99
SELECT SUM(K) FROM sbtest57 WHERE id BETWEEN 5034894 AND 5034894+99
SELECT DISTINCT c FROM sbtest50 WHERE id BETWEEN 4959831 AND 4959831+99 ORDER BY c
寫入：
INSERT INTO sbtest3 (id, k, c, pad) VALUES (4974042, 4963580, ‘33958272865-80411528812-36334179010-84793024318-25708692091-43736213170-37853797624-40480626242-32131452190-24509204411’,’07716658989-39745043214-17284860193-80004426880-14154945098’)
更新：
UPDATE sbtest11 SET k=k+1 WHERE id=5013989
UPDATE sbtest14 SET c=’10695174948-02130015518-68664370682-70336600207-55943744221-72419172189-36252607855-75106351226-86920614936-86254476316’ WHERE id=5299388
e) 測試指標
TPS
Transactions Per Second，即數據庫每秒執行的事務數，以commit成功次數爲準。
QPS
Queries Per Second，即數據庫每秒執行的SQL數（含insert、select、update、delete等）。
f) 測試結果
通用型
獨享型
_2018_08_31_5_55_25
image116
image117
2) MySQL實例參數調優建議
對於雲數據庫MySQL版的實例，可以通過控制檯上修改一些參數。對於某些重要參數而言，不恰當的參數值會導致實例性能問題或應用報錯，所以本文將介紹一些重要參數的最優值建議以減少在設置參數時的疑慮。其中紅色標註的是針對車聯網場景的調優建議，車聯網場景的特點是高併發，數據量大，讀多寫多。
back_log（高併發場景需要提高此參數值）
默認值：3000
修改完後是否需要重啓：是
作用：MySQL每處理一個連接請求時都會創建一個新線程與之對應。在主線程創建新線程期間，如果前端應用有大量的短連接請求到達數據庫，MySQL會限制這些新的連接進入請求隊列，由參數back_log控制。如果等待的連接數量超過back_log的值，則將不會接受新的連接請求，所以如果需要MySQL能夠處理大量的短連接，需要提高此參數的大小。
現象：如果參數過小，應用可能出現如下錯誤。
SQLSTATE[HY000] [2002] Connection timed out;
修改建議：提高此參數值的大小。
innodb_autoinc_lock_mode（有助於避免死鎖，提升性能）
默認值：1
修改完後是否需要重啓：是
作用：在MySQL 5.1.22後，InnoDB爲了解決自增主鍵鎖表的問題，引入了參數innodb_autoinc_lock_mode，用於控制自增主鍵的鎖機制。該參數可以設置的值爲0、1、2，RDS默認的參數值爲1，表示InnoDB使用輕量級別的mutex鎖來獲取自增鎖，替代最原始的表級鎖。但是在load data（包括INSERT … SELECT和REPLACE … SELECT）場景下若使用自增表鎖，則可能導致應用在併發導入數據時出現死鎖。
現象：在load data（包括INSERT … SELECT和REPLACE … SELECT）場景下若使用自增表鎖，在併發導入數據時出現如下死鎖。
RECORD LOCKS space id xx page no xx n bits xx index PRIMARY of table xx.xx trx id xxx lock_mode X insert intention waiting. TABLE LOCK table xxx.xxx trx id xxxx lock mode AUTO-INC waiting；
修改建議：建議將該參數值改爲2，表示所有情況插入都使用輕量級別的mutex鎖（只針對row模式），這樣就可以避免auto_inc的死鎖，同時在INSERT … SELECT的場景下性能會有很大提升。
說明：當該參數值爲2時，binlog的格式需要被設置爲row。
query_cache_size（車輛網的特點是讀多寫多的場景，此參數建議關閉）
默認值：3145728
修改完後是否需要重啓：否
作用：該參數用於控制MySQL query cache的內存大小。如果MySQL開啓query cache，在執行每一個query的時候會先鎖住query cache，然後判斷是否存在於query cache中，如果存在則直接返回結果，如果不存在，則再進行引擎查詢等操作。同時，insert、update和delete這樣的操作都會將query cahce失效掉，這種失效還包括結構或者索引的任何變化。但是cache失效的維護代價較高，會給MySQL帶來較大的壓力。所以，當數據庫不會頻繁更新時，query cache是很有用的，但如果寫入操作非常頻繁並集中在某幾張表上，那麼query cache lock的鎖機制就會造成很頻繁的鎖衝突，對於這一張表的寫和讀會互相等待query cache lock解鎖，從而導致select的查詢效率下降。
現象：數據庫中有大量的連接狀態爲checking query cache for query、Waiting for query cache lock、storing result in query cache。
修改建議：RDS默認是關閉query cache功能的，如果實例打開了query cache，當出現上述情況後可以關閉query cache。
net_write_timeout （可避免汽車數據因超時而導致數據寫入失敗）
默認值：60
修改完後是否需要重啓：否
作用：等待將一個block發送給客戶端的超時時間。
現象：若參數設置過小，可能會導致客戶端出現錯誤the last packet successfully received from the server was milliseconds ago或the last packet sent successfully to the server was milliseconds ago。
修改建議：該參數在RDS中默認設置爲60秒，一般在網絡條件比較差時或者客戶端處理每個block耗時較長時，由於net_write_timeout設置過小導致的連接中斷很容易發生，建議增加該參數的大小。
tmp_table_size（大內存建議開啓，提升查詢性能）
默認值：2097152
修改完後是否需要重啓：否
作用：該參數用於決定內部內存臨時表的最大值，每個線程都要分配，實際起限制作用的是tmp_table_size和max_heap_table_size的最小值。如果內存臨時表超出了限制，MySQL就會自動地把它轉化爲基於磁盤的MyISAM表。優化查詢語句的時候，要避免使用臨時表，如果實在避免不了的話，要保證這些臨時表是存在內存中的。
現象：如果複雜的SQL語句中包含了group by、distinct等不能通過索引進行優化而使用了臨時表，則會導致SQL執行時間加長。
修改建議：如果應用中有很多group by、distinct等語句，同時數據庫有足夠的內存，可以增大tmp_table_size（max_heap_table_size）的值，以此來提升查詢性能。
loose_rds_max_tmp_disk_space
默認值：10737418240
修改完後是否需要重啓：否
作用：用於控制MySQL能夠使用的臨時文件的大小。
現象：如果臨時文件超出loose_rds_max_tmp_disk_space的取值，則會導致應用出現如下錯誤。
The table ‘/home/mysql/dataxxx/tmp/#sql_2db3_1’ is full
修改建議：首先，需要分析一下導致臨時文件增加的SQL語句是否能夠通過索引或者其它方式進行優化。其次，如果確定實例的空間足夠，則可以提升此參數的值，以保證SQL能夠正常執行。
loose_tokudb_buffer_pool_ratio
默認值：0
修改完後是否需要重啓：是
作用：用於控制TokuDB引擎能夠使用的buffer內存大小，比如innodb_buffer_pool_size設置爲1000MB，tokudb_buffer_pool_ratio設置爲50（代表50%），那麼TokuDB引擎的表能夠使用的buffer內存大小則爲500MB。
修改建議：如果RDS中使用TokuDB引擎，建議調大該參數，以此來提升TokuDB引擎表的訪問性能。
loose_max_statement_time
默認值：0
修改完後是否需要重啓：否
作用：用於控制查詢在MySQL的最長執行時間。如果超過該參數設置的時間，查詢將會自動失敗，默認是不限制。
現象：若查詢時間超過了該參數的值，則會出現如下錯誤。
ERROR 3006 (HY000): Query execution was interrupted, max_statement_time exceeded
修改建議：如果想要控制數據庫中SQL的執行時間，則可以開啓該參數，單位是毫秒。
loose_rds_threads_running_high_watermark（高併發場景下有保護作用）
默認值：50000
修改完後是否需要重啓：否
作用：用於控制MySQL併發的查詢數目，比如將rds_threads_running_high_watermark的值設置爲100，則允許MySQL同時進行的併發查詢爲100個，超過限制數量的查詢將會被拒絕掉。該參數與rds_threads_running_ctl_mode配合使用（默認值爲select）。
修改建議：該參數常常在秒殺或者大併發的場景下使用，對數據庫具有較好的保護作用。
參數設置步驟
進入RDS控制檯找到RDS實例—》點擊管理—》點擊參數設置—》設置完成參數—點擊提交參數—》點擊確定
image118
image119
image120
4、Elasticsearch性能測試及調優
Elasticsearch是一個基於Lucene的搜索和數據分析工具，它提供了一個分佈式服務。Elasticsearch是遵從Apache開源條款的一款開源產品，是當前主流的企業級搜索引擎。
阿里雲Elasticsearch提供Elasticsearch 5.5.3版本及商業插件X-pack服務，致力於數據分析、數據搜索等場景服務。在開源Elasticsearch基礎上提供企業級權限管控、安全監控告警、自動報表生成等功能. 今天我們對阿里雲的Elasticsearch的讀寫性能分別做個測試。
寫性能
測試環境
本次測試的Elasticsearch版本爲5.5.3，3個節點，壓測了三種規格的集羣分別爲2核4G 、4核16G、16核64G磁盤規格均爲1T SSD雲盤。
採⽤用 esrally 壓測
rest api
壓測數據集有以下兩種
esrally官⽅方數據 geonames 3.3 GB,單⽂文檔⼤大⼩小 311B
模擬某業務⽇日誌數據 log 80GB 單⽂文檔⼤大⼩小 1432B
測試結果
分⽚片數均爲6
以下cpu 、load、ioutil 均爲近似值
log 指標已針對批量量⽇日誌寫⼊入場景做了了異步translog/Merge策略略調整等優化
_2018_08_31_5_59_32
寫性能指標對比
機器對寫性能的影響
分⽚片數均爲6
副本數均爲0
磁盤容量量均爲1T SSD雲盤
image_jpeg
副本數對性能指標的影響
分⽚片數均爲6
數據樣本均爲log
磁盤容量量均爲1T SSD雲盤
查詢性能
測試環境
本次測試的Elasticsearch版本爲5.5.3，3個節點，壓測了三種規格的集羣分別爲2核4G 、4核16G磁盤規格均爲1T SSD雲盤
採⽤ esrally 壓測
壓測數據爲esrally官方數據 geonames 3.3 GB,單⽂文檔⼤大⼩小 311B
測試結果
分⽚片數均爲6
副本數均爲0
查詢類型爲term和phrase
_2018_08_31_6_00_56
Mechine Qps Cpu Load JVM Memory 90th percentile service time
2 core 12378 89% 3.98 47% 17.6141ms
4 core 23498 93% 4.63 48% 20.3789ms
5、雲數據庫 HBase性能測試及調優
雲數據庫ApsaraDB for HBase是一種穩定可靠、可彈性伸縮的分佈式Nosql數據庫，兼容開源HBase協議。現有以及即將提供的功能包括：安全，公網訪問，HBase on oss, 備份恢復，冷熱分離，可選擇的存儲介質包括，高效雲盤，雲ssd盤，本地磁盤，產品形態包括：單機版HBase以及分佈式版本。
1) ApsaraDB for HBase測試
今天我們基於阿里雲ApsaraDB for HBase進行一個性能測試。
a) 測試環境
所有測試均在華東2（上海）地域的可用區B完成。
實例配置爲8核32G，獨享。
網絡類型爲經典網絡。
壓測用的鏡像爲CentOS 6.8 64位。
單條數據value大小1KB，100線程進行數據壓測
b) 測試工具
測試工具使用開源HBase 自帶的PerformanceEvaluation工具進行測試，因爲該工具提供了較爲豐富的測試場景，包括隨機key讀寫，構造順序key讀寫，自定義的scan操作，且該工具完美兼容ApsaraDB for HBase的訪問API，除此之外，對於測試需要的輸出數據也是能夠比較詳細的展示出來。
安裝方法
不需要安裝，該二進制文件在HBase的安裝包裏面自帶，不需要人工安裝，直接執行命令進行操作即可；
c) 測試方法
準備數據
在進行實際測試的時候，需要在HBase內部灌入一定量數據，以可以達到模擬線上的真實場景，寫入數據的語句是：
sh hbase org.apache.hadoop.hbase.PerformanceEvaluation –nomapred –writeToWAL=
true –table=test –rows=5000 randomWrite 100
上述語句表示啓動100線程，每一個線程往test表裏寫入5000條數據，每次寫入操作需要記錄WAL log。
壓測性能
壓測的操作包括讀，寫，scan操作；
寫入操作：
sh hbase org.apache.hadoop.hbase.PerformanceEvaluation –nomapred –writeToWAL=
true –table=test –rows=5000 randomWrite 100
上述是寫入操作的命令，其中可以通過調整配置文件writerbuffer進行修改每次批量寫入的條數,我們測試寫入1條，2條和100條的數據信息。
讀取操作：
sh hbase org.apache.hadoop.hbase.PerformanceEvaluation –nomapred –table=test –rows=5000 randomRead 100
上述爲讀取操作的命令，對於讀取而言，我們可以分別測試讀取命中內存很高的情況下的數據，以及對於沒有命中內存緩存情況下的數據。對於命中率高的情況，開啓blockcahe，然後多次進行預讀觀測監控頁面的命中率信息即可得到，對於無名中的話，只需要關閉cache即可；
scan數據操作：
sh hbase org.apache.hadoop.hbase.PerformanceEvaluation –nomapred –table=test –rows=5000 –caching=100 scanRange100 100
對於這種scan的話，我們觀測的是命中率較高以及基本沒有內存cache命中率的情況的數據。命中率高低的判斷以及條件達到參考讀取的情況。
d) 測試模型
庫表結構
hbase(main):001:0> describe test’
Table test is ENABLED
test
COLUMN FAMILIES DESCRIPTION
{NAME => ‘info’, BLOOMFILTER => ‘ROW’, VERSIONS => ‘1’, IN_MEMORY =
‘false’, KEEP_DELETED_DATA => ‘FALSE’, DATA_BLOCK_ENCODING => ‘NO
NE’, TTL => ‘FOREVER’, COMPRESSION => ‘NONE’, MIN_VERSIONS => ‘0’,
BLOCKCACHE => ‘true’, BLOCKSIZE => ‘65536’, REPLICATION_SCOPE => ‘0
‘}
數據格式
row: 00000000000000000000000428
column=info:0,
timestamp=1526367336121, value=NNNNNNNNLLLLLLLLCCCCCCCCJJJJJJJJGGGGGGGGZZZZZZZZPPP
PPPPPQQQQQQQQNNNNNNNNEEEEEEEEGGGGGGGGYYYYYYYYBBBBBBBBLLLLLLLLN NNNNNNNGGGGGGGGNNNNNNNNRRRRRRRREEEE EEEEQQQQQQQQXXXXXXXXTTTTTTTTJJJJJJJJYYYYYYYYXXXXXXXXMMMMMMMMJJJJJJJJMMMMMMMMFFFFFFFFHHHHHHHHDDDDD
DDDOOOOOOOOSSSSSSSSYYYYYYYYRRRRRRRRPPPPPPPPBBBBBBBBHHHHHHHHXXXXXXXXVVVVVVVVEEEEEEEEMMMMMMMMEEEEEE
EEMMMMMMMMDDDDDDDDLLLLLLLLKKKKKKKKSSSSSSSSWWWWWWWWVVVVVVVVXXXXXXXXVVVVVVVVJJJJJJJJAAAAAAAANNNNNNN
NDDDDDDDDLLLLLLLLAAAAAAAAOOOOOOOOKKKKKKKKFFFFFFFFHHHHHHHHIIIIIIIIZZZZZZZZQQQQQQQQAAAAAAAAKKKKKKKK
VVVVVVVVTTTTTTTTXXXXXXXXTTTTTTTTNNNNNNNNYYYYYYYYRRRRRRRRPPPPPPPPMMMMMMMMRRRRRRRRHHHHHHHHKKKKKKKKG
GGGGGGGBBBBBBBBMMMMMMMMBBBBBBBBTTTTTTTTFFFFFFFFSSSSSSSSQQQQQQQQCCCCCCCCSSSSSSSSVVVVVVVVBBBBBBBBFF
FFFFFFZZZZZZZZLLLLLLLLAAAAAAAAIIIIIIIIDDDDDDDDCCCCCCCCEEEEEEEESSSSSSSSOOOOOOOOFFFFFFFFKKKKKKKKHHH
HHHHHVVVVVVVVXXXXXXXXKKKKKKKKKKKKKKKKPPPPPPPPCCCCCCCCMMMMMMMMRRRRRRRREEEEEEEEGGGGGGGGGGGGGGGGPPPP
PPPPUUUUUUUUAAAAAAAAKKKKKKKKAAAAAAAAKKKKKKKKXXXXXXXXCCCCCCCCUU
e) 測試指標
RPS
Request Per Second，即數據庫每秒執行的請求（含put，read，scan等）。
單條延時
平均單條請求的時延
f) 測試結果
_2018_08_31_6_02_54
_2018_08_31_6_03_04
2) HBaseclient實例參數調優建議
對於hbase client做Htable封裝，然後請求hbase的時候，Htable可以配置AutoFlush這個參數，默認是true，可以設置爲false，表示當Htable的本地緩存打滿以後才進行flush，開啓false可以提高客戶端感知的寫入速度。
修改完後是否需要重啓client：是
在HBase client做封裝的時候，同樣可以設置scan caching這個參數的個數，表示每次從服務端緩存多少條數據用戶scan。默認的值是1，但是如果單條value很大的話，這個值建議不要設置很大。
Scan Attribute Selection，在做scan的時候，建議加上一些相應的表屬性相關的過濾，如果添加只scan某一個列族的話，那麼返回的時候只會操作該cf下面的數據，反之就會有很多不必要的列族返回，降低不必要的通信量。
WAL標誌，對於非重要的數據，即，如果爲了圖性能，對數據如果是允許不一致以及數據安全性要求不高的話，那麼在進行put操作的時候，可以將是否寫WAL 的標誌置爲false，這樣的話，就是數據在寫入的時候不會先寫WAL，那麼對寫操作會有很好的性能體現。
啓用bloomfilter，對於讀操作的話，如果開啓bloomfilter的話，對讀的性能有一定的提高，因爲這是拿空間換讀操作的時間。
6、HiTSDB性能測試及調優
HiTSDB Edge是一款運行在近客戶端的高性能時序數據庫。
6.1測試模型
測試採用的數據模型來源於隨機生成的metric, tags組成的時間線metric和tagKey,tagValue分別由固定長度（10 bytes字符串） + 索引，不採用具有真實意義的metric和tagKey，tagValue是因爲無法覆蓋各種真實場景，且測試目的是爲了將HiTSDB橫向與其他時序數據庫進行比較，因此在保證測試數據，軟硬件條件一致的情況下，也可取得可信度較高的結果。時間戳(8bytes 長整型)，value（8bytes雙精度整數）。數據樣例如下：
image123
6.2統計結果說明
每次測試進行之前重啓數據庫服務，避免緩存對於之前執行獲得的結果產生影響。
吞吐量（TPS）是單位時間內完成的數據點操作數量。
每次寫入之後，會手動隨機選擇時間線進行數據查詢，粗粒度校驗數據寫入一致性。同時對於HiTSDB寫入，會註冊SDK回調，失敗或成功都能夠感知。
同時爲了避免測試數據產生影響，每次測試之前都會清理數據。
關於時間線數量，每次測試運行時，會通過HiTSDB內部接口/api/tscount校驗時間線數量，每次增長均符合預期。HiTSDB與其他數據庫單節點對比測試
6.3測試環境及步驟說明
所有數據庫的對比測試是在同一臺服務器上進行，基於阿里雲ECS進行測試，該服務器的詳細配置如下：
CPUs: 4
Memory(GiB): 8
Network Performance: High
Disk Capacity(GiB)：60
在測試時，HiTSDB採用客戶端版本號1.4.9。在本次測試中，InfluxDB默認設置。
本測試測試了各個數據庫在不同時間線數量級場景下的寫入和讀取的表現。
6.4寫入性能
數據庫的一個寫入請求可以包含一個或者多個數據點。總的而言，一次請求裏包含的數據點越多，寫入性能就會相應提升。在以下測試中，P/R表示Points/Request（一次請求中的數據點數）。
6.4.1 HiTSDB測試結果
單客戶端500 Points Per Request寫性能
單客戶端100萬時間線寫入TPS概要
image124
客戶端CPU使用情況
image125
從下面表格結果來分析，HiTSDB在時間線增長時，寫入TPS會有一定下降，最終在6xlarge規格指定的100萬時間線時，寫入TPS約爲5萬左右，這與阿里雲官網宣傳的性能60000點每秒，基本上差距不大。
雙客戶端500 Points Per Request寫性能
雙客戶端100萬時間線寫入TPS概要
image126
客戶端CPU使用情況
image127
四客戶端500 Points Per Request寫性能
_2018_08_31_6_09_30
四客戶端100萬時間線寫入TPS概要
image128
客戶端CPU使用情況
image129
根據三組測試的結果分析可知，HiTSDB的寫入TPS隨着時間線的增長呈下降趨勢，同時，1萬和10萬時間線量級下，即使增加客戶端數量，TPS也基本變化不大，100萬時間線數量級，從1臺客戶端增漲到2臺時，TPS有所增漲；而2臺增長到4臺時，沒有增漲。因此可以認爲在6xlarge硬件下100萬時間線HiTSDB的峯值寫入TPS是在15萬這個數量級，注意之所以說峯值，是因爲需要注意的是本次測試的前置條件是清除數據，隨着環境中時間線的增加，寫入TPS會降下來，測試過，差不多是在5-6萬TPS。
6.5 優化建議
1) 寫入優化
一次批量寫多個數據
2) 查詢優化
如果需要一次性查詢很長時間範圍的數據，建議拆分爲多個小時的數據來查詢。