MongoDB Authentication slow my TPS?

前言

  故事发生在上一篇 MongoDB Validator 是否会因性能影响而成为摆设?, 当我把这篇文章给TJ过目后,TJ直接给我建议了下一篇文章的题目“开启权限认证对性能产生的影响”。原因是自从上次MongoDB比特币勒索事件后,很多人一下意识到对数据库加密的必要,但是同时又担心开启鉴权会影响到MongoDB的性能和吞吐。所以借着上次文档校验测试之积累,这里给大家再来做一次鉴权方面的性能测试。

好了,这只是一个插曲,

接着来简单介绍下官方的Security。

官方的Security 是分好几种的,在这里,我们对使用最广泛的 SCRAM-SHA-1 进行验证。

先来看看官方对 SCRAM-SHA-1 算法的赞美吧:
- A tunable work factor (iterationCount),
- Per-user random salts rather than server-wide salts,
- A cryptographically stronger hash function (SHA-1 rather than MD5), and
- Authentication of the server to the client as well as the client to the server.

从3.0后,SCRAM-SHA-1 已成为默认的加密算法。但是如果是从2.6升级到3.0版本的,MongoDB还是支持 MONGODB-CR 算法的,然而官方极力推荐升级算法。具体算法步骤本篇不做过多赘述,可移步官网 https://docs.mongodb.com/manual/release-notes/3.0-scram/

在就着之前发生的暴露在公网的MongoDB未加密而被勒索的事件,安全是必须要做到的。

希望今天这篇文章能够帮助到那些担心有安全问题,但又更担心性能问题的小伙伴们~

调研

为了避免重复造轮子并做好万手准备,先做一番深入的调研,并验证自己对整个过程中可能发生的问题,是一个必须的过程。(再次感谢我的师傅 菠萝同学 教会了我这一点。)

  • 开启无权限认证
    开启无权限认证

  • 添加认证用户
    添加认证用户

  • 重启数据库,并开启权限认证
    开启权限认证

  • 确认ycsb 可以通过带验证的 connection uri 连入mongodb
    确认通过正确的connection uri 连入mongodb

在最后附上了参考API,可供大家了解。

硬件信息

同 《MongoDB Validator 是否会因性能影响而成为摆设?》中的验证过程,这里就简单总结一下:

服务器

  • Product Name: ProLiant DL360 Gen9
  • Storage: RAID10, SSD, 1600GB
  • CPU*2: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, (8/8 cores; 16 threads)*2
  • Memory: 64GB*2

数据库

  • 单节点
  • wiredTigerCacheSizeGB=16
  • auth: enabled
  • 其他全部默认

测试

load

CRUD normal doc auth doc
[INSERT], AverageLatency(us) 2049.89474307 2211.32866389
[INSERT], 95thPercentileLatency(us) 39.0 43.0
[READ], AverageLatency(us) null null
[READ], 95thPercentileLatency(us) null null
[UPDATE], AverageLatency(us) null null
[UPDATE], 95thPercentileLatency(us) null null
[OVERALL], RunTime(ms) 2088593.0 2242816.0
[OVERALL], Throughput(ops/sec) 47879.122452292046 44586.805159228395

r:0.95, i:0.05

CRUD normal doc auth doc
[INSERT], AverageLatency(us) 105.3323497432522 132.487445717047
[INSERT], 95thPercentileLatency(us) 104.0 103.0
[READ], AverageLatency(us) 1338.8095364613405 1362.5082493133966
[READ], 95thPercentileLatency(us) 4751.0 4939.0
[UPDATE], AverageLatency(us) null null
[UPDATE], 95thPercentileLatency(us) null null
[OVERALL], RunTime(ms) 643134.0 655232.0
[OVERALL], Throughput(ops/sec) 77744.29590100974 76308.84938464544

r:0.5, u:0.5

CRUD normal doc validation doc
[INSERT], AverageLatency(us) null null
[INSERT], 95thPercentileLatency(us) null null
[READ], AverageLatency(us) 7769.861166389139 7947.372478433602
[READ], 95thPercentileLatency(us) 26927.0 27935.0
[UPDATE], AverageLatency(us) 98.82069331485245 94.62377523853623
[UPDATE], 95thPercentileLatency(us) 70.0 72.0
[OVERALL], RunTime(ms) 1972152.0 2018302.0
[OVERALL], Throughput(ops/sec) 25353.015386237978 24773.299535946553

r:0.7, u:0.2, i:0.1

CRUD normal doc validation doc
[INSERT], AverageLatency(us) 128.0571005518589 127.27489749616417
[INSERT], 95thPercentileLatency(us) 145.0 171.0
[READ], AverageLatency(us) 3336.0277518858206 3485.926126834881
[READ], 95thPercentileLatency(us) 13015.0 13615.0
[UPDATE], AverageLatency(us) 117.50030112373882 105.32122833989561
[UPDATE], 95thPercentileLatency(us) 67.0 69.0
[OVERALL], RunTime(ms) 1194793.0 1244313.0
[OVERALL], Throughput(ops/sec) 41848.25321206268 40182.815738483805

r:0.1, u:0.2, i:0.7

CRUD normal doc validation doc
[INSERT], AverageLatency(us) 84.9555143143808 102.93271012453623
[INSERT], 95thPercentileLatency(us) 82.0 83.0
[READ], AverageLatency(us) 37026.50496982059 39040.24776869989
[READ], 95thPercentileLatency(us) 114303.0 122623.0
[UPDATE], AverageLatency(us) 62.52783986719247 86.839632400919
[UPDATE], 95thPercentileLatency(us) 52.0 54.0
[OVERALL], RunTime(ms) 1900481.0 2009732.0
[OVERALL], Throughput(ops/sec) 26309.129109946378 24878.93908242492

r:0.1, i:0.9

CRUD normal doc validation doc
[INSERT], AverageLatency(us) 42.979859355229316 84.06285323865184
[INSERT], 95thPercentileLatency(us) 51.0 53.0
[READ], AverageLatency(us) 26553.94076526652 26935.384089125255
[READ], 95thPercentileLatency(us) 82623.0 84095.0
[UPDATE], AverageLatency(us) null null
[UPDATE], 95thPercentileLatency(us) null null
[OVERALL], RunTime(ms) 1359904.0 1396059.0
[OVERALL], Throughput(ops/sec) 36767.30122126268 35815.10523552371

所有压测报告,都会上传至github

https://github.com/MiracleYoung/mongodb_stressing_auth

结论

  • 从以上压测报告,可以看出在开启权限认证的情况下,大并发的情况下对读的延迟影响基本可以忽略不计。
  • 然而无论是从 load,还是从 r:0.1, i:0.9 的压测结果确实可以反映出,在大并发的情况下,开启认证对于写性能是有一定得影响的。
  • 之所以 loadr:0.1, i:0.9 的差异,在我翻看了代码后发现,load 是采用batch commit 的方式,而insert 则是 一条一条提交。因此会有对比差异。

就以上得出的个人结论后,我认为,这些性能的牺牲是可以忽略不计的。毕竟没有影响到 10倍乃至百倍的性能消耗。

数据库,始终是以安全为第一参考要素的!

参考

  • https://github.com/brianfrankcooper/YCSB/tree/master/mongodb
  • https://docs.mongodb.com/manual/reference/connection-string/
  • http://api.mongodb.com/java/current/index.html?com/mongodb/MongoClientURI.html

关于上海小胖(MiracleYoung)

DevOps & DBA                           MySQL, MongoDB, Redis, etc.                     CSDN: http://edu.csdn.net/lecturer/course_list           Blog: https://segmentfault.com/u/shanghaixiaopang/articles 

MongoDB Authentication slow my TPS?》有1个想法

  1. Pingback: Milana Travis

发表评论