查看原文
其他

zuul 参数调优

2018-01-24 铁汤 IT轻社区

zuul 参数调优

适用版本:
spring-boot: 1.4.x.RELEASE
spring-cloud:Camden.SR3
Hystrix: 1.5.6

spring-boot-tomcat 优化参数:

主要只有2个,最大和最小worker线程:

1

2

server.tomcat.max-threads=128 # Maximum amount of worker threads.

server.tomcat.min-spare-threads=64 # Minimum amount of worker threads.


spring-boot-undertow 优化参数:

ioThreads

设置IO线程数, 它主要执行非阻塞的任务,它们会负责多个连接,默认取CPU核心数量,最小值为2。
Math.max(Runtime.getRuntime().availableProcessors(), 2);
spring-boot 参数:server.undertow.io-threads=

worker-threads

阻塞任务线程池, 当执行类似servlet请求阻塞操作, undertow会从这个线程池中取得线程,它的值设置取决于系统的负载,默认值为io-threads*8。

spring-boot 参数:server.undertow.worker-threads=

buffer

buffer-size:

每块buffer的空间大小,越小的空间被利用越充分。

buffers-per-region:

每个区分配的buffer数量 , 所以pool的大小是buffer-size * buffers-per-region。

directBuffers

是否分配的直接内存。

获取JVM最大可用内存maxMemory=Runtime.getRuntime().maxMemory();

maxMemory<64M,不开启directBuffers, bufferSize = 512,buffersPerRegion = 10;

64<=maxMemory<128M,开启directBuffers, bufferSize = 1024 bytes,buffersPerRegion = 10;

maxMemory>128M,开启directBuffers, bufferSize = 16*1024 bytes,buffersPerRegion = 20;

spring-boot 参数:

1

2

3

4

5

6

7

8

# 最大可用内存<64M,不开启

server.undertow.buffer-size= # Size of each buffer in bytes.

server.undertow.buffers-per-region= # Number of buffer per region.

server.undertow.direct-buffers= # Allocate buffers outside the Java heap.

//默认值:cpu数量,最小为2

server.undertow.io-threads= # Number of I/O threads to create for the worker.

//默认值:io-threads*8

server.undertow.worker-threads= # Number of worker threads.


zuul 内置参数

zuul.host.maxTotalConnections

适用于ApacheHttpClient,如果是okhttp无效。每个服务的http客户端连接池最大连接,默认是200.

zuul.host.maxPerRouteConnections

适用于ApacheHttpClient,如果是okhttp无效。每个route可用的最大连接数,默认值是20。

zuul.semaphore.max-semaphores

Hystrix最大的并发请求execution.isolation.semaphore.maxConcurrentRequests,这个值并非TPSQPSRPS等都是相对值,指的是1秒时间窗口内的事务/查询/请求,semaphore.maxConcurrentRequests是一个绝对值,无时间窗口,相当于亚毫秒级的。当请求达到或超过该设置值后,其其余就会被拒绝。默认值是100。参考: Hystrix semaphore和thread隔离策略的区别及配置参考

这个参数本来直接可以通过Hystrix的命名规则来设置,但被zuul重新设计了,使得在zuul中semaphores的最大并发请求有4个方法的参数可以设置,如果4个参数都存在优先级(1~4)由高到低:

  • [优先级1]zuul.eureka.api.semaphore.maxSemaphores

  • [优先级2]zuul.semaphore.max-semaphores

  • [优先级3]hystrix.command.api.execution.isolation.semaphore.maxConcurrentRequests

  • [优先级4]hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests

需要注意的是:在Camden.SR3版本的zuul中hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests设置不会起作用,这是因为在org.springframework.cloud.netflix.zuul.filters.ZuulProperties.HystrixSemaphore.maxSemaphores=100设置了默认值100,因此zuul.semaphore.max-semaphores的优先级高于hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests

zuul.eureka.[commandKey].semaphore.maxSemaphores:
其中commandKey为

参考设置参数:

1

2

3

4

5

6

#

zuul.host.maxTotalConnections: 200

zuul.host.maxPerRouteConnections: 10

#zuul.semaphore.max-semaphores: 128

# 建议使用这种方式来设置,可以给每个不同的后端微服务设置不同的信号量

zuul.eureka.[service id].semaphore.maxSemaphores: 128

其他Hystrix参数:

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds用来设置thread和semaphore两种隔离策略的超时时间,默认值是1000。

  • 建议设置这个参数,在Hystrix 1.4.0之前,semaphore-isolated隔离策略是不能超时的,从1.4.0开始semaphore-isolated也支持超时时间了。

  • 建议通过CommandKey设置不同微服务的超时时间,对于zuul而言,CommandKey就是service id:hystrix.command.[CommandKey].execution.isolation.thread.timeoutInMilliseconds

ribbon参数

1

2

3

4

5

6

7

8

9

10

11

12

13

ribbon:

#  # Max number of next servers to retry (excluding the first server)

#  MaxAutoRetries: 1

#  # Whether all operations can be retried for this client

#  MaxAutoRetriesNextServer: 1

#  # Interval to refresh the server list from the source

#  OkToRetryOnAllOperations: true

#  # Interval to refresh the server list from the source

#  ServerListRefreshInterval: 2000

#  # Connect timeout used by Apache HttpClient

ConnectTimeout: 3000

#  # Read timeout used by Apache HttpClient

ReadTimeout: 3000

主要是ConnectTimeoutReadTimeout2个参数,最终会设置到http Client中。

注意这个参数很重要了,会配合execution.isolation.thread.timeoutInMilliseconds一起来用,多少合适要根据微服务实际情况来定:

  • 太小:会导致很多正常业务失败

  • 太大:会导致实际的熔断效果很差,严重会导致雪崩。


一般实际大小为:

  • 要保证该服务的可用性为几个9?99.5 99.9 99.99

  • 要保证的N个9的最大响应时间。


原文出处:

http://tietang.wang/2016/11/17/hystrix/zuu%E5%8F%82%E6%95%B0l%E4%BC%98%E5%8C%96%E5%92%8C%E9%85%8D%E7%BD%AE/?utm_source=tuicool&utm_medium=referral



版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意,谢谢。



MORE | 更多精彩文章

技术人的轻社区

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存