Spring WebClient,将大数量分配给最大连接的缺点是什么?

huangapple go评论131阅读模式
英文:

Spring WebClient, What are the drawbacks of assigning large number to max connections?

问题

I want to create a WebClient for making a request to a third-party API. Today, I received this error message:

"Pending acquire queue has reached its maximum size of 1000."

I did some research and found a solution to fix this problem by configuring the number of pendingAcquireMaxCount and maxConnections like this:

val sslContext = SslContextBuilder
  .forClient()
  .trustManager(InsecureTrustManagerFactory.INSTANCE)
  .build()

val connectionProvider = ConnectionProvider.builder("aws-client")
  .maxConnections(10000)
  .pendingAcquireMaxCount(-1) // no limit
  .build()

val httpConnector = HttpClient.create(connectionProvider).secure { it.sslContext(sslContext) }

return WebClient
  .builder()
  .clientConnector(ReactorClientHttpConnector(httpConnector))
  .build()

But I wonder what are the drawbacks of setting too large a number of pendingAcquireMaxCount and maxConnections. Why is the default pending acquire limit 1000 instead of no limit? Is there something I should be concerned about?

英文:

I want to create a WebClient for making a request to third party API. Today, I receive this error message

Pending acquire queue has reached its maximum size of 1000

I did a few research and found a solution to fix this problem by configuring the number of pendingAcquireMaxCount and maxConnections like this.

val sslContext = SslContextBuilder
  .forClient()
  .trustManager(InsecureTrustManagerFactory.INSTANCE)
  .build()

val connectionProvider = ConnectionProvider.builder("aws-client")
  .maxConnections(10000)
  .pendingAcquireMaxCount(-1) // no limit
  .build()

val httpConnector = HttpClient.create(connectionProvider).secure { it.sslContext(sslContext) }

return WebClient
  .builder()
  .clientConnector(ReactorClientHttpConnector(httpConnector))
  .build()

but I wonder what are the drawbacks of setting too large number of pendingAcquireMaxCount and maxConnections. Why is the default of pending acquire 1000 instead of no limit. Is there a thing that I should concern?

答案1

得分: 1

maxConnections

这定义了客户端创建的通道数量,我认为将其设置为高数值/无限制可能会导致两个问题:

  1. 导致内存消耗增加,可能在最后导致内存溢出(OOM)问题。
  2. 可能会导致某种“浪费”,当可以等待另一个连接完成并被重用时,会创建新的通道 - 这取决于实现方式,正如文档中所提到的这里

pendingAcquireMaxCount

经过确认,无限制的连接可能会导致一些问题,将这个设置为无限制也可能会引发两个问题:

  1. 请求溢出 - 如果请求不断创建得比解决它们的速度更快,这将导致请求的数量不断增加(而不仅仅是拒绝一些带有错误的请求)。即使存在请求的峰值而不是持续较高的速率,这也可能会导致问题延迟到解决它们(而不是立即拒绝请求并返回正常状态,这会延迟直到处理完所有请求)。

  2. 请求的延迟 - 如果这是无限制的,您无法知道需要等待多长时间(1秒?1分钟?),因为它依赖于先前请求的数量,而在有限制的情况下,您知道最多需要等待X次,而不管有多少请求。

英文:

It seems to me that for each of the configurations you mention you have a different answer.

maxConnections

This defines the number of channels that the client creates, and it seems to me that having this set to a high number/no limit would cause 2 problems:

  1. Cause increasing memory consumption, which may lead to OOM at the end of the line.
  2. May cause a certain "waste" that will create new channels when it may instead wait for another connection to finish and be reused - this depends on the implementation, as mentioned in the docs here.

pendingAcquireMaxCount

Having established that unlimited connections may cause some problems, having this set to unlimited may also cause 2 problems:

  1. An overflow of requests - if requests are constantly created faster than they are resolved, this will cause the amount of requests to constantly increase (instead of simply having some of them get rejected with error). Even if there is a spike of requests and not a constant higher rate, this may cause the issue to be delayed until resolve (instead of rejecting the requests straight away and returning to normal, this will instead delay until processing them all).

  2. A delay to requests - if this is unlimited, you do not know how long you may have to wait (1 second? 1 minute?) since it is dependent on the amount of previous requests, where in the limited scenario you know you are waiting for a maximum of X tries, regardless of how many requests are there.

huangapple
  • 本文由 发表于 2023年4月17日 20:53:57
  • 转载请务必保留本文链接:https://go.coder-hub.com/76035383.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定