网易视频云网易HBase基准性能测试之结果篇.docx

1、网易视频云网易HBase基准性能测试之结果篇网易视频云：网易HBase基准性能测试之结果篇上一篇网易视频云的技术专家给大家分享了网易HBase基准性能测试之准备篇中详细介绍了本次性能测试的基本准备情况，包括测试集群架构、单台机器软硬件配置、测试工具以及测试方法等，在此基础上本篇文章主要介绍HBase在各种测试场景下的性能指标（主要包括单次请求平均延迟和系统吞吐量）以及对应的资源利用情况，并对各种测试结果进行分析。测试结果单条记录插入测试参数总记录数为10亿，分为128个region，均匀分布在4台region server上；插入操作执行2千万次；插入请求分布遵从zipfian分布；测试结果资

2、源使用情况上图为单台RegionServer的带宽使用曲线图（资源使用情况中只列出和本次测试相关的资源曲线图，后面相关资源使用情况类似），本次测试线程为1000的情况下带宽基本维持在100M左右，对于百兆网卡来说基本上已经打满。结果分析1.吞吐量曲线分析：线程数在10500的情况下，随着线程数的增加，系统吞吐量会不断升高；之后线程数再增加，系统吞吐量基本上不再变化。结合图3带宽资源使用曲线图可以看出，当线程数增加到一定程度，系统带宽资源基本耗尽，系统吞吐量就不再会增加。可见，HBase写操作是一个带宽敏感型操作，当带宽资源bound后，写入吞吐量基本就会稳定。2. 写入延迟曲线分析：随着线程数

3、的不断增加，写入延迟也会不断增大。这是因为写入线程过多，导致CPU资源调度频繁，单个线程分配到的CPU资源会不断降低；另一方面由于线程之间可能会存在互斥操作导致线程阻塞；这些因素都会导致写入延迟不断增大。建议根据曲线显示，500线程以内的写入延迟并不大于10ms，而此时吞吐量基本最大，因此如果是单纯写入的话500线程写入会是一个比较合适的选择。单纯查询测试参数总记录数为10亿，分为128个region，均匀分布在4台region server上；查询操作执行2千万次；查询请求分布遵从zipfian分布；测试结果资源使用情况图5为线程数在1000时IO利用率曲线图，图中IO利用率基本保持在100

4、%，说明IO资源已经达到使用上限。图6为线程数在1000时系统负载曲线图，图中load1曲线表示在最近一分钟内的平均负载，load5表示最近五分钟内的平均负载。最近5分钟的负责达到了50左右，对于32核系统来说，表示此时系统负载很高，已经远远超负荷运行。结果分析1. 吞吐量曲线分析：线程数在10500的情况下，随着线程数的增加，系统吞吐量会不断升高；之后线程数再增加，系统吞吐量基本上不再变化。结合图5、图6系统资源使用曲线图可以看出，当线程数增加到一定程度，系统IO资源基本达到上限，系统负载也特别高。IO利用率达到100%是因为大量的读操作都需要从磁盘查找数据，系统负载很高是因为HBase需要

5、对查找的数据进行解压缩操作，解压缩操作需要耗费大量CPU资源。这两个因素结合导致系统吞吐量就不再随着线程数增肌而增加。可见，HBase读操作是一个IO/CPU敏感型操作，当IO或者CPU资源bound后，读取吞吐量基本就会稳定不变。2. 延迟曲线分析：随着线程数的不断增加，读取延迟也会不断增大。这是因为读取线程过多，导致CPU资源调度频繁，单个线程分配到的CPU资源会不断降低；另一方面由于线程之间可能会存在互斥操作导致线程阻塞；这些因素都会导致写入延迟不断增大。和写入延迟相比，读取延迟会更大，是因为读取涉及IO操作，IO本身就是一个耗时操作，导致延迟更高。建议根据曲线显示，500线程以内的读取

6、延迟并不大于20ms，而此时吞吐量基本最大，因此如果是单纯读取的话500线程读取会是一个比较合适的选择。Range扫描查询测试参数总记录数为10亿，分为128个region，均匀分布在4台region server上；scan操作执行一千两百万次，请求分布遵从zipfian分布； scan最大长度为100条记录， scan长度随机分布且遵从uniform分布；测试结果资源使用情况图8为线程数在1000时IO利用率曲线图，图中IO利用率基本保持在100%，说明IO资源已经达到使用上限。图9为线程数在1000时带宽资源使用曲线图，图中带宽资源基本也已经达到上限。结果分析1. 吞吐量曲线分析：线程数

7、在10500的情况下，随着线程数的增加，系统吞吐量会不断升高；之后线程数再增加，系统吞吐量基本上不再变化。结合图8 、图9资源使用曲线图可以看出，当线程数增加到一定程度，系统IO资源基本达到上限，带宽也基本达到上限。IO利用率达到100%是因为大量的读操作都需要从磁盘查找数据，而带宽负载很高是因为每次scan操作最多可以获取50Kbyte数据，TPS太高会导致数据量很大，因而带宽负载很高。两者结合导致系统吞吐量就不再随着线程数增大会增大。可见，scan操作是一个IO/带宽敏感型操作，当IO或者带宽资源bound后，scan吞吐量基本就会稳定不变。2. 延迟曲线分析：随着线程数的不断增加，读取延

8、迟也会不断增大。这是因为读取线程过多，导致CPU资源调度频繁，单个线程分配到的CPU资源会不断降低；另一方面由于线程之间可能会存在互斥操作导致线程阻塞；这些因素都会导致写入延迟不断增大。和写入延迟以及单次随机查找相比，读取延迟会更大，是因为scan操作会涉及多次IO操作，IO本身就是一个耗时操作，因此会导致延迟更高。建议根据图表显示，用户可以根据业务实际情况选择100500之间的线程数来执行scan操作。查询插入平衡测试参数总记录数为10亿，分为128个region，均匀分布在4台region server上；查询插入操作共执行8千万次；查询请求分布遵从zipfian分布；测试结果资源使用情况

9、图11为线程数在1000时系统IO利用率曲线图，图中IO利用率基本保持在100%，说明IO资源已经达到使用上限。图12为线程数在1000时系统负载曲线图，图中显示CPU负载资源达到了40+，对于只有32核的系统来说，已经远远超负荷工作了。结果分析1. 吞吐量曲线分析：线程数在10500的情况下，随着线程数的增加，系统吞吐量会不断升高；之后线程数再增加，系统吞吐量变化就比较缓慢。结合图11、图12系统资源使用曲线图可以看出，当线程数增加到一定程度，系统IO资源基本达到上限，带宽也基本达到上限。IO利用率达到100%是因为大量的读操作都需要从磁盘查找数据，而系统负载很高是因为大量读取操作需要进行解

10、压缩操作，而且线程数很大本身就需要更多CPU资源。因此导致系统吞吐量就不再会增加。可见，查询插入平衡场景下，当IO或者CPU资源bound后，系统吞吐量基本就会稳定不变。2. 延迟曲线分析：随着线程数的不断增加，读取延迟也会不断增大。这是因为读取线程过多，导致CPU资源调度频繁，单个线程分配到的CPU资源会不断降低；另一方面由于线程之间可能会存在互斥操作导致线程阻塞；这些因素都会导致写入延迟不断增大。图中读延迟大于写延迟是因为读取操作涉及到IO操作，比较耗时。建议根据图表显示，在查询插入平衡场景下用户可以根据业务实际情况选择100500之间的线程数。插入为主测试参数总记录数为10亿，分为128

11、个region，均匀分布在4台region server上；查询插入操作共执行4千万次；查询请求分布遵从latest分布；测试结果资源使用情况图15为线程数在1000时系统带宽使用曲线图，图中系统带宽资源基本到达上限，而总体IO利用率还比较低。结果分析1. 曲线分析：线程数在10500的情况下，随着线程数的增加，系统吞吐量会不断升高；之后线程数再增加，系统吞吐量基本上不再变化。结合图14带宽资源使用曲线图可以看出，当线程数增加到一定程度，系统带宽资源基本耗尽，系统吞吐量就不再会增加。基本同单条记录插入场景相同。2. 写入延迟曲线分析： 基本同单条记录插入场景。建议根据图表显示，插入为主的场景下

12、用户可以根据业务实际情况选择500左右的线程数来执行。查询为主测试参数总记录数为10亿，分为128个region，均匀分布在4台region server上；查询插入操作共执行4千万次；查询请求分布遵从zipfian分布；测试结果资源使用情况图17为线程数在1000时IO利用率曲线图，图中IO利用率基本保持在100%，说明IO资源已经达到使用上限。结果分析基本分析见单纯查询一节，原理类似。建议根据图表显示，查询为主的场景下用户可以根据业务实际情况选择100500之间的线程数来执行。Increment自增测试参数1亿条数据，分成16个Region，分布在4台RegionServer上；操作次数为

13、100万次；测试结果结果分析1. 线程数增加，Increment操作的吞吐量会不断增加，线程数到达100个左右时，吞吐量会达到顶峰（23785 ops/sec），之后再增加线程数，吞吐量基本维持不变;2. 随着线程数增加，Increment操作的平均延迟会不断增加。线程数在100以下，平均延时都在4ms以内；建议根据图表显示，查询为主的场景下用户可以根据业务实际情况选择100500之间的线程数来执行。测试结果总结根据以上测试结果和资源利用情况可以得出如下几点：1. 写性能：集群吞吐量最大可以达到70000+ ops/sec，延迟在几个毫秒左右。网络带宽是主要瓶颈，如果将千兆网卡换成万兆网卡，吞

14、吐量还可以继续增加，甚至达到目前吞吐量的两倍。2. 读性能：很多人对HBase的印象可能都是写性能很好、读性能很差，但实际上HBase的读性能远远超过大家的预期。集群吞吐量最大可以达到26000+，单台吞吐量可以达到8000+左右，延迟在几毫秒20毫秒左右。IO和CPU是主要瓶颈。3. Range 扫描性能：集群吞吐量最大可以达到14000左右，系统平均延迟在几毫秒60毫秒之间（线程数越多，延迟越大）；其中IO和网络带宽是主要瓶颈。测试注意事项1. 需要关注是否是全内存测试，全内存测试和非全内存测试结果相差会比较大。参考线上实际数据情况，本次测试采用非全内存读测试。是否是全内存读取决于总数据量

15、大小、集群Jvm内存大小、Block Cache占比、访问分布是否是热点访问这四者，在JVM内存大小以及Block Cache占比不变的情况下，可以增大总数据量大小或者修改访问分布；2. 测试客户端是否存在瓶颈。HBase测试某些场景特别耗费带宽资源，如果单个客户端进行测试很可能会因为客户端带宽被耗尽导致无法测出实际服务器集群性能。本次测试使用6个客户端并发进行测试。3. 单条记录大小对测试的影响。单条记录设置太大，会导致并发插入操作占用大量带宽资源进而性能产生瓶颈。而设置太小，测试出来的TPS峰值会比较大，和线上实际数据不符。本次测试单条数据大小设置为50M，基本和实际情况相符。网易视频云是

16、网易推出是PAAS级视频云服务，致力于为客户提供真正易用的视频云服务，目前已经广泛应用于在线教育、秀场直播、游戏直播、远程医疗等领域，在网易内部，也有广泛运用视频云的产品，比如网易新闻直播、网易BOBO、网易青果等。 出师表两汉：诸葛亮先帝创业未半而中道崩殂，今天下三分，益州疲弊，此诚危急存亡之秋也。然侍卫之臣不懈于内，忠志之士忘身于外者，盖追先帝之殊遇，欲报之于陛下也。诚宜开张圣听，以光先帝遗德，恢弘志士之气，不宜妄自菲薄，引喻失义，以塞忠谏之路也。宫中府中，俱为一体；陟罚臧否，不宜异同。若有作奸犯科及为忠善者，宜付有司论其刑赏，以昭陛下平明之理；不宜偏私，使内外异法也。侍中、侍郎郭攸之、费

17、祎、董允等，此皆良实，志虑忠纯，是以先帝简拔以遗陛下：愚以为宫中之事，事无大小，悉以咨之，然后施行，必能裨补阙漏，有所广益。将军向宠，性行淑均，晓畅军事，试用于昔日，先帝称之曰“能”，是以众议举宠为督：愚以为营中之事，悉以咨之，必能使行阵和睦，优劣得所。 亲贤臣，远小人，此先汉所以兴隆也；亲小人，远贤臣，此后汉所以倾颓也。先帝在时，每与臣论此事，未尝不叹息痛恨于桓、灵也。侍中、尚书、长史、参军，此悉贞良死节之臣，愿陛下亲之、信之，则汉室之隆，可计日而待也。臣本布衣，躬耕于南阳，苟全性命于乱世，不求闻达于诸侯。先帝不以臣卑鄙，猥自枉屈，三顾臣于草庐之中，咨臣以当世之事，由是感激，遂许先帝以驱驰。后值倾覆，受任于败军之际，奉命于危难之间，尔来二十有一年矣。先帝知臣谨慎，故临崩寄臣以大事也。受命以来，夙夜忧叹，恐托付不效，以伤先帝之明；故五月渡泸，深入不毛。今南方已定，兵甲已足，当奖率三军，北定中原，庶竭驽钝，攘除奸凶，兴复汉室，还于旧都。此臣所以报先帝而忠陛下之职分也。至于斟酌损益，进尽忠言，则攸之、祎、允之任也。愿陛下托臣以讨贼兴复之效，不效，则治臣之罪，以告先帝之灵。若无兴德之言，则责攸之、祎、允等之慢，以彰其咎；陛下亦宜自谋，以咨诹善道，察纳雅言，深追先帝遗诏。臣不胜受恩感激。今当远离，临表涕零，不知所言。