问性能命中从MongoDB Java驱动程序迁移到反应性流驱动程序

EN

我们正在尝试从基于RxJava的旧RxJava驱动程序mongodb-驱动程序-rx (v1.5.0)升级到更新的mongodb-驱动程序-响应 (v1.13.1) --这并不是因为依赖关系，而是因为依赖关系，但肯定是更新了很多。旧的RxJava之一已经用了好几年了.对于新的驱动程序，一切都是正确的，但是在高负载下，性能受到了太大的打击，我们无法解释原因。

我们的应用程序的一些背景信息：

我们的(Java)应用程序运行在AWS EC2上(高峰时间大约为30个m5.x大型实例)，并且基于Vertx和RxJava堆栈。我们正在运行一个Mongo集群(m5.12xlarge)，其中包含一个主服务器和两个秒。在高峰时期，与蒙古人同时连接的典型数量是几千。我们有一个基于gatling的负载测试，它通常运行1小时，包括60个AWS EC2实例、1个主Mongo和2个秒(如在生产中)，以及100 k同时使用的用户。

几个观察：

• 对一段简单的集成测试代码(执行一些常见的db操作)进行微基准测试表明，旧驱动程序和新驱动程序之间没有明显的性能差异。
• 与旧的驱动程序，我们看到良好的整体性能在负载测试，avg 20 in的响应时间和200 in的响应时间在99%的百分位数。
• 有了新的驱动程序，运行相同的负载测试，事情就会爆炸(超过2000 60的平均响应时间，最终超过60%的请求失败，因为等待队列越来越满)。
• 如果我们只使用一个EC2实例和1.6k同时用户运行负载测试(这是每个实例相同的负载)，那么新旧驱动程序之间没有明显的性能差异，而且运行也相对顺利。

MongoDB驱动程序设置：

clusterSettings = "{hosts=[localhost:27017], mode=MULTIPLE, requiredClusterType=UNKNOWN, requiredReplicaSetName='null', serverSelector='LatencyMinimizingServerSelector{acceptableLatencyDifference=15 ms}', clusterListeners='[]', serverSelectionTimeout='30000 ms', localThreshold='30000 ms', maxWaitQueueSize=500, description='null'}"
connectionPoolSettings = "ConnectionPoolSettings{maxSize=100, minSize=0, maxWaitQueueSize=50000, maxWaitTimeMS=5000, maxConnectionLifeTimeMS=0, maxConnectionIdleTimeMS=300000, maintenanceInitialDelayMS=0, maintenanceFrequencyMS=60000, connectionPoolListeners=[]}"
heartbeatSocketSettings = "SocketSettings{connectTimeoutMS=10000, readTimeoutMS=10000, keepAlive=true, receiveBufferSize=0, sendBufferSize=0}"
readPreference = "primary"
serverSettings = "ServerSettings{heartbeatFrequencyMS=10000, minHeartbeatFrequencyMS=500, serverListeners='[]', serverMonitorListeners='[]'}"
socketSettings = "SocketSettings{connectTimeoutMS=10000, readTimeoutMS=0, keepAlive=true, receiveBufferSize=0, sendBufferSize=0}"
sslSettings = "SslSettings{enabled=false, invalidHostNameAllowed=true, context=null}"
writeConcern = "WriteConcern{w=null, wTimeout=null ms, fsync=null, journal=null"

我们尝试过的：(全部都没有用)

• 切换Mongo版本(我们目前仍在3.6上，但我们也尝试了4.0 )；
• 在每个db操作周围添加一个基于Vertx的RxJava调度程序(我们已经尝试过Schedulers.io()和RxHelper.scheduler(vertx))
• 使用AsynchronousSocketChannelStreamFactoryFactory配置Mongo设置，其中包含大小为100的固定线程池的AsynchronousChannelGroup；
• 使用包含NettyStreamFactoryFactory的NioEventLoopGroup配置Mongo设置；
• 在每个实例中使用最大的Mongo连接池(从100到500不等)；

目前无法帮助我们的事情：(我们知道这些，其中一些在我们的路线图上，但它们现在太费时了)

• 更好的索引管理(我们已经对此进行了优化，没有使用效率低下的排序规则的查询)
• 将应用程序拆分为较小的服务
• 通过使用内存中的JVM缓存(Guava)或远程缓存(Redis)来减轻Mongo的负载我们已经在某种程度上这样做了。
• 抛弃Vertx，比如支持Spring

它似乎是某种池或线程问题，但我们不能准确地确定问题，而剖析这类问题也是非常困难的。

对于什么可能导致这个问题，以及如何解决它，有什么想法吗？