Spring BOOT 1.5.6的性能问题

Question

Spring BOOT 1.5.6的性能问题

我们使用的是一个基于spring boot java的REST API应用程序，我们有下面的spring MVC async参数。在负载较重的情况下，当测试端点时，端点返回30-50秒的API响应。当我们突然有10分钟的突发时，就会发生这种情况。API响应75%的理想时间是在1- 2秒之间。下面是配置，我们使用6个C5x大型实例，每个实例有4个核心。

spring.mvc.async.properties.web.executor.minPoolSize=50
spring.mvc.async.properties.web.executor.maxPoolSize=100
spring.mvc.async.properties.web.executor.maxQueueSize=50
#Hikari Data source properties.
spring.datasource.hikari.minimumIdle=25
spring.datasource.hikari.maximumPoolSize=90
spring.datasource.hikari.idleTimeout=600000

感谢您的任何可伸缩性建议。

此外，我们还在一些调用中发现dB调用占用时间，我们正在尝试找出是否有任何需要优化的查询，但我认为线程正在等待带有异步线程执行器的dB response.Also，并将策略作为丢弃策略，是否有可能拒绝任何提交的任务？我希望任务排队，而不是在负载下拒绝.we从callerRuns策略转移到丢弃policy.Any对此的想法，或者spring boot端或线程池大小执行端所需的任何其他东西？谢谢

Answer 1

我认为作为第一选择，你应该试着找出这个流程的瓶颈。

实现这一点的关键工具是指标。

我看到您在这里使用Hikari，它自己自动公开指标。也许数据库工作很困难，成为了瓶颈，在这种情况下，从池中获取数据库连接需要相对较长的时间。

另一个可能的问题是，如果服务的实际请求携带了大量内容(可能是一个“大文件上传”操作，我不知道它是否是一个案例，但仍然值得检查)。

因此，我建议使用指标(内置或自定义)。Spring boot与计量系统有很好的集成( spring boot 2的测微器和spring boot 1.x的dropwizard指标)

Answer 2

谢谢马克的回复。这是正确的，我正在用/metrics查看由测微仪显示的指标。此外，我们只将核心池大小指定为100，并删除了上面提到的最小池大小和最大池大小的所有自定义调整，从而查看了它是如何从有界队列到无界队列的。我们现在拥有的数据库连接是90*6个实例。在负载下，它只使用Under 300+连接。服务返回1.8kb到最大2MB之间的有效负载。