首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >SpringCloud从入门到进阶——单点部署Zuul的压力测试与调优(一)

SpringCloud从入门到进阶——单点部署Zuul的压力测试与调优(一)

作者头像
天涯泪小武
发布2019-09-18 11:34:19
1.4K0
发布2019-09-18 11:34:19
举报
文章被收录于专栏:SpringCloud专栏SpringCloud专栏

原文链接:https://www.cnblogs.com/lonelyJay/p/10076158.html

前言说明:通过zuul访问后端服务时,这个流程是如何的?当你用500线程并发访问zuul和用100线程并发访问zuul,zuul分别会用多少个线程去并发访问后端的服务?后端最多能承受多少个并发线程?zuul默认是Hystrix的信号量隔离,这个值对zuul并发访问后端时有什么影响?

可以通过这一篇来了解一下。

内容

  作为微服务架构系统的入口,毫无疑问,Zuul的并发性能直接决定了整个系统的并发性能。本文结合前几篇文章的内容,在云服务器中部署了包含Eureka Server,Zuul等组件的1.0版本的微服务架构,并进行单点部署Zuul的压力测试,对其并发性能一探究竟。

版本

​   JVM监测工具:JVisualVM

​   压力测试工具:Apache Bench 2.3

​   JDK:1.8.0_171

  SpringBoot:1.5.9.RELEASE

  SpringCloud:Dalston.SR1

环境

image
image

  处理器具体型号为Intel xeon(skylake) platinum 8163,主频2.5GHz。

说明

  转载请说明出处:SpringCloud从入门到进阶(八)——单点部署Zuul的压力测试与调优(一)

步骤

  微服务架构中,所有的请求都需要经过Zuul的转发才能到达具体的微服务。因此Zuul的并发量和可用性将直接影响甚至决定整个系统的并发量和可用性。在本篇文章中,我们使用压力测试工具Apache Bench,在局域网范围内搭建环境对特定接口进行压力测试,因此本示例只是考察CPU和内存对Zuul和微服务并发能力的影响,网络带宽、缓存、数据库、磁盘IO等因素不在本实例的讨论范围内,测试系统的吞吐量、服务端请求平均处理时间、用户请求平均等待时间等参数。

  Apache Bench的安装、使用请参考Linux入门实践笔记(六)——压力测试工具Apache Bench的安装、使用和结果解读。下面,我们再重温下HTTP服务器性能指标:

吞吐量

  吞吐量(Requests per second)是在某个并发度下服务器每秒处理的请求数。它是服务器并发处理能力的量化描述,单位是reqs/s。计算公式为:总请求数/处理请求的总耗时。 吞吐量越大说明服务器的性能越好。

请求平均处理时间

  请求平均处理时间(Time per request,across all concurrent requests)是服务器处理请求的平均时间,计算公式为:处理请求的总耗时/总请求数。它是服务器吞吐量的倒数。也等于,用户请求平均等待时间/并发用户数。

请求平均等待时间

  请求平均等待时间(Time per request)是用户等待请求响应的平均时间,计算公式为:处理请求的总耗时/(总请求数/并发用户数)。

  “请求平均处理时间”和“请求平均等待时间”两个概念非常容易混淆,举一个例子进行说明:比如100个用户同时执行上传文档的操作,那么并发用户数为100,假设服务器可以同时处理这100个请求,并且每个文件上传操作的耗时都是1s。那么请求总耗时时间为1s,吞吐量为100reqs/s。请求平均处理时间为0.01s,请求平均等待时间为1s。也就是说,请求平均处理时间是从服务器的角度出发的,请求平均等待时间是从用户的角度出发的。

测试环境搭建

启动路由Zuul

​  执行下面的指令部署路由Zuul,将jvm的栈空间设置为512MB,并在本地的7199端口开启jmx监控,用来检测jvm的运行情况。由SpringCloud从入门到进阶(五)——路由接入Zuul及其单点部署可知,Zuul的路由规则为:"/routea/..." 匹配到微服务"application-serviceA"。

[user@ServerA7 jars]$ java -Dspring.profiles.active=peer2 
-Dcom.sun.management.jmxremote.port=7199 #供JMX客户端远程连接用的端口号 
-Dcom.sun.management.jmxremote.ssl=false #关闭账号密码认证,不安全,仅在开发阶段使用
-Dcom.sun.management.jmxremote.authenticate=false #关闭SSL
-Djava.rmi.server.hostname=106.117.142.x #指定本机供远程访问的IP地址,此处是本机的公网IP
-Xms512m -Xmx512m -jar zuul-1.0-SNAPSHOT.jar &

​   如果按照上述参数配置,仍然无法远程访问JVM,可以参考Linux入门实践笔记(七)——云服务器中配置Java项目的JMX连接失败问题解决记录

启动微服务实例

​  此处在SpringCloud从入门到进阶(六)——使用SpringBoot搭建微服务的基础之上,在DemoController中增加测试接口"/timeconsume/{length}",使用sayHello方法和timeConsuming方法分别模拟简单操作和耗时操作(由代码可知,接口处理与网络带宽、缓存、数据库、磁盘IO无关)。

@PostMapping("/hello/{name}")
public String sayHello(@PathVariable(value = "name") String name,
                       @RequestParam(value = "from") String user){
    String content="Hello "+name+",this is DemoTest.From "+user+"@:"+instanceID+".";
    logger.log(Level.INFO,content);
    return content;
}
​
@GetMapping("/timeconsume/{length}")
public String timeConsuming(@PathVariable(value = "length") int length){
    try {
        Thread.sleep(length);
   }catch (Exception e){
        e.printStackTrace();
   }
    String content="Successfully sleep "+length+" ms.";
    logger.log(Level.INFO,content);
    return content;
}

  参照下面指令启动ServiceA的实例,同样在本地的7199端口开启jmx监控,将jvm的栈空间设置为起始512MB,最大1024MB。

[user@ServerA2 jars]$ java -Dspring.profiles.active=peer1 --Dcom.sun.management.jmxremote.port=7199 #供JMX客户端远程连接用的端口号 
-Dcom.sun.management.jmxremote.ssl=false #关闭账号密码认证,不安全,仅在开发阶段使用
-Dcom.sun.management.jmxremote.authenticate=false #关闭SSL
-Djava.rmi.server.hostname=106.117.142.x #指定本机供远程访问的IP地址,此处是本机的公网IP
-Xms512m -Xmx1024m -jar service-1.0-SNAPSHOT.jar &

开始测试

  在测试路径下创建ab的post测试所需要的参数文件params,内容为:

[user@ServerA6 ab]$ cat params from=lee

测试一:50个并发用户,执行50000次请求

1.1.1直接调用sayHello接口

​  直接调用sayHello接口,是为了记录该接口的处理速度,用于与通过Zuul调用做比较,以评估Zuul转发对请求延迟的影响。系统吞吐量在5600(请求/秒)左右,请求平均处理时间为0.177ms,请求平均等待时间为8.869ms,50000次请求都执行成功。

  注:多测试几次,吞吐量会随着虚拟机指令的优化逐步稳定在5600左右。

[user@ServerA6 ab]$ ab -n 50000 -c 50 -p params -T application/x-www-form-urlencoded
 http://172.26.125.115:8881/test/hello/leo
​
Time taken for tests:   8.869 seconds
#50000次请求都执行成功
Complete requests:      50000
Failed requests:        0
#系统吞吐量在5600(请求/秒)左右
Requests per second:    5637.54 [#/sec] (mean)
#请求平均等待时间为8.869ms
Time per request:       8.869 [ms] (mean)
#请求平均处理时间为0.177ms
Time per request:       0.177 [ms] (mean, across all concurrent requests)

​  Service资源使用情况:

​  压测过程中,CPU使用率在80%,堆内存的使用最大为220MB(堆空间为512MB),实时线程从44增加到85。此时CPU成了系统吞吐量进一步提升的瓶颈,此时的系统吞吐量可以视为单台2核服务器能承受的最大吞吐量,即5600左右(结论一)

1543906800483
1543906800483

1.1.2通过路由Zuul调用sayHello接口(不做负载均衡)

  系统吞吐量在4000(请求/秒)左右,请求平均处理时间为0.246ms,请求平均等待时间为12.297ms,50000次请求都执行成功。跟1.1.1的测试比较,可知,Zuul转发后,平均每个请求的等待时间增加了3.428ms

[user@ServerA6 ab]$ ab -n 50000 -c 50 -p params -T 
application/x-www-form-urlencoded http://172.26.125.117:7082/v1/routea/test/hello/leo
​
Time taken for tests:   12.297 seconds
Complete requests:      50000
Failed requests:        0
Requests per second:    4066.11 [#/sec] (mean)
Time per request:       12.297 [ms] (mean)
Time per request:       0.246 [ms] (mean, across all concurrent requests)

  Zuul资源使用情况:

  压测过程中,Zuul服务器的CPU使用率为100%,堆内存的使用最大为470MB(堆空间为512MB),实时线程从80增加到120。可见CPU为系统的瓶颈。

1542880295196
1542880295196

  Service资源使用情况

  压测过程中,Service服务器的CPU使用率为50%,堆内存的使用最大为270MB(堆空间为512MB),实时线程从48增加到75。可见由于Zuul请求转发的不及时,Service端的CPU和内存都有富余,Zuul成为微服务架构的瓶颈(结论二)。通过线程数量的变化可知,Zuul端虽然有50个线程转发用户请求,但是在Service端,只有大概40个线程处理请求Zuul端转发请求的线程数与Service端处理请求的线程数之间是什么关系呢?(问题一)这里先暂且保留这个问题,在后续的文章中再具体解释。

1542880319708
1542880319708

1.2.1直接调用timeConsuming(200ms)接口

  系统吞吐量在250(请求/秒)左右,请求平均处理时间为4.032ms,请求平均等待时间为201.622ms,50000次请求都执行成功。

[user@ServerA6 ab]$ ab -n 50000 -c 50 http://172.26.125.115:8881/test/timeconsume/200
​
Time taken for tests:   201.622 seconds
Complete requests:      50000
Failed requests:        0
Requests per second:    247.99 [#/sec] (mean)
Time per request:       201.622 [ms] (mean)
Time per request:       4.032 [ms] (mean, across all concurrent requests)

  Service资源使用情况

  压测过程中,Service服务器的CPU使用率起初为60%,随着响应的处理,逐步稳定到10%以内,堆内存的使用最大为270MB,实时线程从48增加到90。可见Service端的CPU和内存都有富余。

1542880366318
1542880366318

1.2.2通过Zuul调用timeConsuming接口

  系统吞吐量在250(请求/秒)左右,请求平均处理时间为4.064ms,请求平均等待时间为203.210ms,50000次请求都执行成功。跟1.2.1的测试比较,可知,Zuul转发后,平均每个请求的等待时间增加了1.588ms。跟1.1.2的测试比较可知,Zuul在CPU资源从紧张到富余时,转发后请求的等待时间延迟从3.428ms降到了1.588ms。可见当Zuul的CPU高负荷运转时,其转发请求所带来的延迟就越高(结论三)

[user@ServerA6 ab]$ ab -n 50000 -c 50 http://172.26.125.117:7082/v1/routea/test/timeconsume/200
​
Time taken for tests:   203.210 seconds
Complete requests:      50000
Failed requests:        0
Requests per second:    246.05 [#/sec] (mean)
Time per request:       203.210 [ms] (mean)
Time per request:       4.064 [ms] (mean, across all concurrent requests)

  Zuul资源使用情况

  压测过程中,Zuul服务器的CPU使用率在10%左右,堆内存的使用最大为470MB(堆空间为512MB),实时线程从79增加到120。此时Zuul端的CPU有富余。

1542880411652
1542880411652

  Service资源使用情况

  压测过程中,Service服务器的CPU使用率在7%左右,堆内存的使用最大为270MB(堆空间为512MB),实时线程从48增加到89。可见Service端的CPU和内存都有富余,可以承受更大的并发量。

1542880441823
1542880441823

测试二:200个并发用户,执行50000次请求

  总请求次数不变,将并发用户数增大到200,来探究并发用户数增加与系统吞吐量的关系。

2.1.1直接调用sayHello接口

  系统吞吐量在5500(请求/秒)左右,请求平均处理时间为0.183ms,请求平均等待时间为36.592ms,50000次请求都执行成功。跟1.1.1的测试比较,由于受CPU瓶颈影响,在并发用户数增大4倍之后,系统的吞吐量并没有增大,反而由于并发线程增多,堆内存的开销变大,系统吞吐量有略微的减少,并且用户等待时间从8.869增大到36.592ms,增大了4倍多(结论四)

[user@ServerA6 ab]$ ab -n 50000 -c 200 -p params -T application/x-www-form-urlencoded
 http://172.26.125.115:8881/test/hello/leo
​
Time taken for tests:   9.148 seconds
Complete requests:      50000
Failed requests:        0
Requests per second:    5465.68 [#/sec] (mean)
Time per request:       36.592 [ms] (mean)
Time per request:       0.183 [ms] (mean, across all concurrent requests)

  Service资源使用情况

  压测过程中,CPU使用率达到90%,堆内存的使用最大为410MB(堆空间为512MB),实时线程从48增加到238。

1542880934420
1542880934420

2.1.2通过Zuul调用sayHello接口

  系统吞吐量在4200(请求/秒)左右,请求平均处理时间为0.237ms,请求平均等待时间为47.428ms,50000次请求中有24次请求失败。跟1.1.2的测试比较,在并发用户数增大4倍之后,由于受CPU瓶颈影响,系统的吞吐量并没有增大,反而有略微的减少,并且用户等待时间从12.297ms增大到47.428ms,增大了4倍(结论四)。

[user@ServerA6 ab]$ ab -n 50000  -c 200 -p params -T application/x-www-form-urlencoded
 http://172.26.125.117:7082/v1/routea/test/hello/leo
​
Time taken for tests:   11.857 seconds
Complete requests:      50000
Failed requests:        24
   (Connect: 0, Receive: 0, Length: 24, Exceptions: 0)
Requests per second:    4216.93 [#/sec] (mean)
Time per request:       47.428 [ms] (mean)
Time per request:       0.237 [ms] (mean, across all concurrent requests)

  测试中存在请求失败的情况,查询日志可以看到服务熔断的信息。那么,Zuul为什么会在Serivce正常的情况下出现服务熔断呢?这个记为问题二,同样在后续文章中进行解读。

1542897074736
1542897074736

​  Zuul资源使用情况:

  压测过程中,Zuul服务器的CPU使用率为100%,堆内存的使用最大为500MB(堆空间为512MB)并且伴有频繁的GC,实时线程从79增加到269。

1542881465597
1542881465597

  Service资源使用情况

  压测过程中,Service服务器的CPU使用率为55%,堆内存的使用最大为390MB(堆空间为580MB),实时线程从49增加到80。可见Zuul请求转发的不及时,微服务端的CPU和内存都有富余(结论二)。通过线程数量的变化可知,Zuul端即使有200个线程转发用户请求,但是在Service端,仍然只有大概40个线程处理请求(问题一)

1542881503282
1542881503282

2.2.1直接调用timeConsuming方法

  系统吞吐量在 1000(请求/秒)左右,请求平均处理时间为1.017ms,请求平均等待时间为203.467ms,50000次请求都执行成功。跟1.2.1的测试比较,由于CPU和内存资源仍存在富余,在并发用户数增大4倍之后,系统的吞吐量增大了4倍(247.99提升到982.96),请求平均处理时间降低为四分之一(4.032ms缩减到1.017ms),请求平均等待时间基本没有变化(结论五)。

[user@ServerA6 ab]$ ab -n 50000 -c 200 http://172.26.125.115:8881/test/timeconsume/200
​
Time taken for tests:   50.867 seconds
Complete requests:      50000
Failed requests:        0
Requests per second:    982.96 [#/sec] (mean)
Time per request:       203.467 [ms] (mean)
Time per request:       1.017 [ms] (mean, across all concurrent requests)

  Service资源使用情况

  压测过程中,Service服务器的CPU使用率稳定在30%以内,堆内存的使用最大为370MB(堆空间扩充到640MB),实时线程从49增加到239。并且此时CPU和内存仍然有富余,系统的吞吐量可以随着并发线程的增加,同步增大。

1542898756192
1542898756192

2.2.2通过Zuul调用timeConsuming方法

  系统吞吐量在2600(请求/秒)左右,请求平均处理时间为0.386ms,请求平均等待时间为77.109ms,50000次请求中有49196次请求出错,发生熔断(与2.1.2都发生服务熔断,只不过熔断的比例大幅度增加,问题二)。跟1.2.2的测试比较,在并发用户数增大4倍之后,由于发生熔断,Zuul服务器的CPU资源耗尽,系统的吞吐量虽然增加,但是请求出错,会造成不好的用户体验。但是Service端的CPU和内存的负荷会大幅度降低(结论六)

[user@ServerA6 ab]$ ab -n 5000 -c 200 -p params -T application/x-www-form-urlencoded http://172.26.125.117:7082/v1/routea/test/timeconsume/200
​
Time taken for tests:   19.277 seconds
Complete requests:      50000
Failed requests:        49196
   (Connect: 0, Receive: 0, Length: 49196, Exceptions: 0)
Requests per second:    2593.73 [#/sec] (mean)
Time per request:       77.109 [ms] (mean)
Time per request:       0.386 [ms] (mean, across all concurrent requests)

  Zuul资源使用情况

​  压测过程中,Zuul服务器的CPU使用率接近100%,堆内存的使用最大为300MB(堆空间为512MB),实时线程从76增加到266。由于出现频繁的服务熔断,Zuul的CPU资源已经耗尽(结论六)。

1542898001558
1542898001558

  Service资源使用情况

  压测过程中,Service服务器的CPU使用率稳定在5%以内,堆内存的使用最大为280MB(堆空间为512MB),实时线程从48增加到88。可见发生服务熔断后,Service端的CPU和内存资源都有很大的释放(结论六)。

1542897983129
1542897983129

测试三:500个并发用户,执行50000次请求

3.1.1直接调用sayHello接口

  系统吞吐量在5000(请求/秒)左右,请求平均处理时间为0.201ms,请求平均等待时间为100.580ms,50000次请求都执行成功。跟2.1.1的测试比较,在并发用户数增大2.5倍之后,由于CPU出现瓶颈,并且更多的并发用户带来额外的开销,系统的吞吐量开始下降,系统吞吐量从5465.68降到4971.14,并且用户等待时间从36.592ms增大到100.580ms。

[user@ServerA6 ab]$ ab -n 50000 -c 500 -p params -T application/x-www-form-urlencoded
 http://172.26.125.115:8881/test/hello/leo
​
Time taken for tests:   10.058 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Requests per second:    4971.14 [#/sec] (mean)
Time per request:       100.580 [ms] (mean)
Time per request:       0.201 [ms] (mean, across all concurrent requests)

  Service资源使用情况:

  CPU使用率达到80%,堆内存的使用最大为450MB(堆空间扩充到710MB),实时线程从48增加到238。对比2.1.1的测试,为什么Service的线程没有随并发用户数的进一步增多而增大呢?(问题三),这个问题仍在后续文章中进行解释。

1542900078221
1542900078221

3.1.2通过路由Zuul调用sayHello接口(不做负载均衡)

  系统吞吐量在4100(请求/秒)左右,请求平均处理时间为0.241ms,请求平均等待时间为120.743ms,50000次请求有92次熔断(问题二)。

[user@ServerA6 ab]$ ab -n 50000  -c 500 -p params -T application/x-www-form-urlencoded 
http://172.26.125.117:7082/v1/routea/test/hello/leo
​
Time taken for tests:   12.074 seconds
Complete requests:      50000
Failed requests:        92
   (Connect: 0, Receive: 0, Length: 92, Exceptions: 0)
Requests per second:    4141.04 [#/sec] (mean)
Time per request:       120.743 [ms] (mean)
Time per request:       0.241 [ms] (mean, across all concurrent requests)

  Zuul资源使用情况:

  压测过程中,Zuul服务器的CPU使用率为100%,堆内存的使用最大为330MB(堆空间为512MB)并且伴有频繁的GC,实时线程从77增加到268。这里和3.1.1一样,Zuul在请求的并发用户数达到500时,其并发处理线程仍保持在200了(问题三)。

1542900779533
1542900779533

  Service资源使用情况

  压测过程中,Service服务器的CPU使用率在50%以内,堆内存的使用最大为330MB(堆空间为580MB),实时线程从48增加到69。Zuul请求熔断,微服务端的CPU和内存都有富余。Service端,只有大概30个线程处理请求。

1542900820855
1542900820855

3.2.1直接调用timeConsuming方法

  系统吞吐量在 1000(请求/秒)左右,请求平均处理时间为1.011ms,请求平均等待时间为505.538ms,50000次请求都执行成功。跟2.2.1的测试比较,在并发用户数增大2.5倍之后,系统的吞吐量增和请求平均处理时间基本没有变化,但是请求平均等待时间从203.467ms增大到530.300ms(结论四)。

[user@ServerA6 ab]$ ab -n 50000 -c 500 http://172.26.125.115:8881/test/timeconsume/200
​
Time taken for tests:   50.554 seconds
Complete requests:      50000
Failed requests:        0
Requests per second:    989.05 [#/sec] (mean)
Time per request:       505.538 [ms] (mean)
Time per request:       1.011 [ms] (mean, across all concurrent requests)

  Service资源使用情况

  压测过程中,Service服务器的CPU使用率稳定在30%以内,堆内存的使用最大为370MB(堆空间扩充到640MB),实时线程从49增加到239(问题三)。并且此时CPU和内存仍然有富余,系统的吞吐量可以随着并发线程的增加,同步增大。

1542901393535
1542901393535

3.2.2通过Zuul调用timeConsuming方法

  系统吞吐量在2600(请求/秒)左右,请求平均处理时间为0.383ms,请求平均等待时间为191.269ms,50000次请求中有49196次请求出错,发生熔断(问题二)。与2.2.2的测试比较,在并发用户数增大2.5倍之后,系统的吞吐量增和请求平均处理时间基本没有变化,但是请求平均等待时间从77.109ms增大到191.269ms(结论四)。

[user@ServerA6 ab]$ ab -n 50000 -c 500 http://172.26.125.117:7082/v1/routea/test/timeconsume/200
​
Time taken for tests:   19.127 seconds
Complete requests:      50000
Failed requests:        49196
   (Connect: 0, Receive: 0, Length: 49196, Exceptions: 0)
Requests per second:    2614.12 [#/sec] (mean)
Time per request:       191.269 [ms] (mean)
Time per request:       0.383 [ms] (mean, across all concurrent requests)

  Zuul资源使用情况

  压测过程中,Zuul服务器的CPU使用率接近100%,堆内存的使用最大为370MB(堆空间为512MB),实时线程从76增加到266(问题三)。由于出现频繁的服务熔断,Zuul的CPU资源已经耗尽。

1542902075144
1542902075144

  Service资源使用情况

  压测过程中,Service服务器的CPU使用率稳定在5%以内,堆内存的使用最大为340MB(堆空间为590MB),实时线程从48增加到88(问题一)。可见发生服务熔断后,Service端的CPU和内存资源都有很大的释放(结论六)。

1542902097523
1542902097523

本文总结

六个结论

  在本文的三种压力测试过程中,我们得到了六个结论:

  结论一:单台2核服务器能承受的最大吞吐量在5600左右。

​  结论二:在Zuul成为微服务架构的瓶颈时,由于请求转发的不及时,Service端的工作不饱和。因此要选择好Zuul的配置,避免出现性能瓶颈。

  结论三:当Zuul的CPU高负荷运转时,其转发请求所带来的延迟就越高。因此要选择好Zuul的配置,尽可能降低Zuul转发带来的延迟。

  结论四:在CPU成为瓶颈时,即使增大并发线程的数量,系统吞吐量也不会增大,反而会由于堆内存的开销变大,造成系统吞吐量的减少,并且用户等待时间会与并发线程数等比例增大。

  结论五:在CPU和内存资源都充裕的情况下,增大并发线程的数量,系统的吞吐量会等比例增大,请求平均处理时间会随之降低,但请求平均等待时间不会改变,也就是用户体验并不会改变。

  结论六:在高并发情况下如果Zuul发生服务熔断,Zuul服务器的CPU负荷会增大,甚至会耗尽;系统的吞吐量虽然增加,但是请求出错,会造成不好的用户体验。同时Service端的请求梳理会大幅度减少,其CPU和内存的负荷会大幅度降低。

三个问题

  同样,我们也遇到了三个问题:

  问题一:Zuul端转发请求的线程数与Service端处理请求的线程数之间是什么关系呢?

  问题二:Zuul为什么会在Serivce正常的情况下出现服务熔断呢?

  问题三:为什么Service的并发线程数量达到200后没有随并发用户数的进一步增大而增大呢?

  下文,我们将针对这三个问题进行剖析,并通过参数调优解决高并发的处理问题。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019年09月12日,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 吞吐量
  • 测试环境搭建
    • 六个结论
      • 三个问题
      相关产品与服务
      云服务器
      云服务器(Cloud Virtual Machine,CVM)提供安全可靠的弹性计算服务。 您可以实时扩展或缩减计算资源,适应变化的业务需求,并只需按实际使用的资源计费。使用 CVM 可以极大降低您的软硬件采购成本,简化 IT 运维工作。
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档