并发数，连接数与TPS

“我的MongoDB连接数太高了应该怎么办？”——不知道你们怎么样，这样的问题在我这月月都来。这就是这篇文章的由来。

定义

• 并发数：通常我们指的并发数是从客户端的角度来讲，有多少个正在同时执行的请求。MongoDB服务端来讲，也有并发的概念，那就是read/write ticket。今天讨论的主要是前者；
• 连接数：客户端连接池到数据库的连接数量；
• TPS：transactions per second，即每秒交易数。又分为RTPS/WTPS (Read/Write TPS)或RPS/WPS。但是当我们讨论一个特定场景的时候，一般来讲既有读又有写，所以在测试中我们往往会模拟与实际场景最接近的读写比例，来测得TPS。在进行各种改进的时候读写比例不变，来观察TPS是否有提升，作为评价性能的指标。

关系

实际使用中很多时候并发数与连接数是相等的，因为一个请求中只执行了一个数据库请求，当然也就只需要一个连接。就算是执行了多个请求，如果它们是串行的，也只需要一个连接。但是也有例外，那就是异步编程或多线程。此时可能有n个数据库请求同时执行，意味着连接数可能是并发请求数的n倍。如果没有使用异步编程或多线程，就认为连接数等于并发数就行了。

下面是比较麻烦的部分，很多人把连接数或者并发数当成了衡量性能的指标，这是有问题的。当你说：“我需要10000个并发”的时候，你只指定了10000个请求同时执行，并没有指定多少时间内执行完。假如：

• 每个请求需要执行10秒完成，那么在并发10000的前提下TPS是1000；
• 每个请求需要执行1秒完成，那么在并发10000的前提下TPS是10000；
• 每个请求需要执行0.1秒完成，那么在并发10000的前提下TPS是100000；

同样是10000并发，处理能力谁优谁劣一目了然。

另一个麻烦的点在于，似乎很多人在连接数不够用的情况下第一个想到的就是增加连接数。有没有用我们先来举个栗子：

假设你的工作是客服，有很多客户通过聊天窗口向你咨询问题，那么：

• 当你打开1个窗口，你可以跟1个客户沟通并解决问题；
• 当你打开2个窗口，你可以跟2个客户沟通并解决问题；
• 当你打开n个窗口，你可以跟n个客户沟通并解决问题；

我是不是可以说，你打开了多少个窗口就能跟多少客户沟通并解决问题？显然大家都不是超人。当窗口开到一定数量，大部分人都只能等待，你能处理的只是少数而已。所以你能服务多少客户只跟你的处理能力有关，而不是打开了多少窗口就能服务多少客户。换句话说，数据库能提供多少TPS也只跟数据库的处理能力有关，并不是多打开连接就能多处理数据。如果这么简单还要超级计算机干什么，大家玩命开连接就完了。

当然，说开连接就完全没用吗？也不尽然。当连接数小于处理能力的时候增加连接数才有意义，只是大部分时候我们遇到的情况都不在此列。此时你应该做的是优化查询，创建合适的索引等等以缩短处理时间。只有当每个请求的处理时间短了，单位时间内处理的请求数才能变多。

总结一下，TPS=并发数/平均处理时间，大部分情况下你想关注的是TPS而不是并发数。想要增加TPS，后面两个变量怎么变心里有数了吗？而连接数大部分时候只是一个结果，它不是原因，不是原因，不是原因（重要的事情说三遍）！

作者：张耀星

MongoDB中文社区常委会委员，培训联席主席

MongoDB公司北亚区首席技术咨询服务顾问。在MongoDB的开发、应用和咨询服务方面，拥有多年的丰富实践经验。

作为MongoDB认证专家，曾经为不同行业的各类大型客户提供过培训、性能调优、架构设计等各类技术及咨询服务，颇得广大客户信任。