Optimized SpringBoot built-in tomcat tuning test

  • problem

How to configure springBoot's built-in tomcat to make your service more efficient?

  • Basic configuration

The maximum amount of concurrency that Spring Boot can support mainly depends on its Tomcat settings, which can be changed in the configuration file. We can see that in the default settings, the maximum number of threads for Tomcat is 200, and the maximum number of connections is 10,000. This different SpringBoot version may be slightly different. The test in this article is based on Springboot 2.0.7.RELEASE

  • default allocation
/**
		 * Maximum amount of worker threads.
		 */
		private int maxThreads = 200;

		/**
		 * Minimum amount of worker threads.
		 */
		private int minSpareThreads = 10;

		/**
		 * Maximum size in bytes of the HTTP post content.
		 */
		private int maxHttpPostSize = 2097152;

		/**
		 * Maximum size in bytes of the HTTP message header.
		 */
		private int maxHttpHeaderSize = 0;

		/**
		 * Whether requests to the context root should be redirected by appending a / to
		 * the path.
		 */
		private Boolean redirectContextRoot = true;

		/**
		 * Whether HTTP 1.1 and later location headers generated by a call to sendRedirect
		 * will use relative or absolute redirects.
		 */
		private Boolean useRelativeRedirects;

		/**
		 * Character encoding to use to decode the URI.
		 */
		private Charset uriEncoding = StandardCharsets.UTF_8;

		/**
		 * Maximum number of connections that the server accepts and processes at any
		 * given time. Once the limit has been reached, the operating system may still
		 * accept connections based on the "acceptCount" property.
		 */
		private int maxConnections = 10000;

		/**
		 * Maximum queue length for incoming connection requests when all possible request
		 * processing threads are in use.
		 */
		private int acceptCount = 100;

  • Test steps

By looking at the source code, we know that (org.springframework.boot.autoconfigure.web.ServerProperties) springBoot has a built-in tomcat default configuration. Now, in order to reflect the effect locally, we intentionally adjust the configuration parameters as follows to perform pressure testing, and at the same time The sleep(2000) simulation thread set in the stress test interface is not released.

  tomcat:
     #最小线程数
    min-spare-threads: 5
    #最大线程数
    max-threads: 5
    #最大链接数
    max-connections: 5
    #最大等待队列长度
    accept-count: 1
  • This configuration corresponds to pressure test

Insert picture description here

Through the stress test of 100 concurrency, it was found that the abnormality reached 85%. Because we configured ReadTimeout and ConnectTimeout to configure 100 threads to reach 2 seconds at the same time, the processing maximum thread is only 1, and the queue is also 1. As a result, one is that there is no thread to process the request, which leads to timeout and the other is not queued. Don't refuse. After I configure the cup properly according to the local machine, take a look at the pressure test situation. The optimized configuration is as follows:

  tomcat:
      #最小线程数
    min-spare-threads: 100
    #最大线程数
    max-threads: 600
    #最大链接数
    max-connections: 10000
    #最大等待队列长度
    accept-count: 1000

Insert picture description here

As shown in the above figure, the concurrent exception rate of 100 is also 0, all passed, and the response time is also minus sleep(2000), most of which are within 10 milliseconds. The optimization effect is obvious.

Guess you like

Origin blog.csdn.net/qq_29897369/article/details/112434900