Vue SSR压测

服务器端和浏览器端的同构是所有接入Node层前端的共同梦想。但是受限于性能原因,服务器端的渲染模式长久以来一直使用字符串拼接的方式,这就导致了服务器端和浏览器端实质上使用了两种渲染机制,代码的同构也就寸步难行。但是,似乎并没有人真正给出线上实测的性能差距数据。如果真正放在线上环境,压测一下看看每秒请求处理数,这个差距会是多少呢?

这篇文章就致力能给这个问题以答案,为大家的技术选型提供一个简单的参考。

Vue SSR和传统字符串拼接对比

压测方式

  1. 从测试机A 10.100.64.225往预发布机器B 10.100.68.239 (双核)上发送请求

注意事项:关闭掉B机器上的TSW过载保护

  1. 目的URL列表:
    • 页面A:http://h5.weiyun.com/disk 页面是Vue SSR来做的直出渲染。页面较为复杂。
    • 页面B:http://h5.weiyun.com/capacity_purchase 页面是传统jsc打包,字符串拼接方式直出渲染的。页面简单,只有两个webapp请求,拼接也相对简单。
  2. __存在不严谨的地方:__对比两种方式的时候,页面的复杂度略有不同,但是大致可以认为相等。区别的地方:
    • 页面A:两个数据请求串行,且第二个请求较重
    • 页面B:两个数据请求并行,且第二个请求较轻

这个需要等有时间再来做一个复杂度相同的版本,再来压测一下。

初步结论

  • 以一台TSW服务器的每秒处理请求数的维度来评价__Vue SSR的方式比传统字符串拼接性能差40左右%__,因为两个页面复杂度并非完全相同,初步估计可能会有上下10%的浮动。
  • 根据之前jialun的纯性能评价,这字符串拼接和Vdom方法之间的性能差距应该是20倍,但在PRS(Request per second)的角度来看,这个差距被无限的缩小。__在服务器层面上来看,直出渲染方法的性能并非是线性影响RPS的。__

CPU压满的情况

指标 传统字符串拼接 Vue SSR
Request per second(每秒处理请求数) ~90 ~50

CPU 50%的情况

指标 传统字符串拼接 Vue SSR
Request per second(每秒处理请求数) ~40 ~26

压测数据

CPU 96%

页面A

压测命令

ab -n 1000 -r -c 50 -k -C "uin=o0522856232;skey=@b3jWrGE9M" -X 10.100.68.239:80 http://h5.weiyun.com/disk

关键指标

  • Request number(总共发出请求):1k
  • Concurrency number(并发数):50
  • Request per second(每秒处理请求数):47.48
  • Time per request(每条请求时长):1053.178ms
  • Fail request percent(请求失败率): 0.3%
  • CPU used(CPU使用率):双核基本都拉满96%

页面B

压测命令

ab -n 2000 -r -c 100 -k -C "uin=o0522856232;skey=@b3jWrGE9M" -X 10.100.68.239:80 http://h5.weiyun.com/capacity_purchase

关键指标

  • Request number(总共发出请求):2k
  • Concurrency number(并发数):100
  • Request per second(每秒处理请求数):91.24
  • Time per request(每条请求时长):1095.962ms
  • Fail request percent(请求失败率): 0%
  • CPU used(CPU使用率):双核基本都拉满96%

这里为什么页面A是并发50,页面B并发100,会不会对比不准?这些值是刚好将CPU压满的值,如果过大,会导致一些意外情况,错误率上升等等,使测试不准,所以将并发控制在RPS左右是合理的。

CPU 50%

页面A

压测命令

ab -n 20000 -r -c 10 -k -C "uin=o0522856232;skey=@b3jWrGE9M" -X 10.100.68.239:80 http://h5.weiyun.com/disk

关键指标

  • Request number(总共发出请求):20k
  • Concurrency number(并发数):10
  • Request per second(每秒处理请求数):26.29
  • Time per request(每条请求时长):380.308ms
  • Fail request percent(请求失败率): 0.01%
  • CPU used(CPU使用率):双核约为50%

下图是对应的每分钟http返回码为2xx的

页面B

压测命令

ab -n 20000 -r -c 10 -k -C "uin=o0522856232;skey=@b3jWrGE9M" -X 10.100.68.239:80 http://h5.weiyun.com/capacity_purchase

关键指标

  • Request number(总共发出请求):20k
  • Concurrency number(并发数):10
  • Request per second(每秒处理请求数):40.38
  • Time per request(每条请求时长):247.668ms
  • Fail request percent(请求失败率): 0%
  • CPU used(CPU使用率):双核约为50%

下图是对应的每分钟http返回码为2xx的

这个绝对值有点低,测试下异步请求的RPS

命令

ab -n 2000 -c 100 -k -C "uin=o0522856232;skey=@b3jWrGE9M" -X 10.100.68.239:80 -T "application/json" -p post.txt http://www.weiyun.com/webapp/json/weiyunOdOfflineDownloadClient/OdGetTaskList?refer=firefox_mac&g_tk=2051530748&r=0.09955808193495552
// post.txt
{"req_header":"{\"seq\":15265481788007084,\"type\":1,\"cmd\":28220,\"appid\":30013,\"version\":3,\"major_version\":3,\"minor_version\":3,\"fix_version\":3,\"wx_openid\":\"\",\"user_flag\":0}","req_body":"{\"ReqMsg_body\":{\"ext_req_head\":{\"token_info\":{\"token_type\":0,\"login_key_type\":1,\"login_key_value\":\"@b3jWrGE9M\"}},\".weiyun.OdGetTaskListMsgReq_body\":{}}}"}

关键指标

  • Request number(总共发出请求):20k
  • Concurrency number(并发数):100
  • Request per second(每秒处理请求数):175.93
  • Time per request(每条请求时长):568.404ms
  • Fail request percent(请求失败率): 0%
  • CPU used(CPU使用率):双核约为100%

压测过程中遇到的一些坑

预发布机器上的log level是debug

debug会拉取文件行数,这个非常消耗性能
把这个改成info,更改之后增加了__13RPS__

TSW的防过载逻辑

要关掉过载保护,设置cpuLimit=100

apr_socket_recv: Connection reset by peer (104)

apr_socket_recv这个是操作系统内核的一个参数,在高并发的情况下,内核会认为系统受到了SYN flood攻击,会发送cookies(possible SYN flooding on port 80. Sending cookies),这样会减慢影响请求的速度,所以在应用服务武器上设置下这个参数为0禁用系统保护就可以进行大并发测试了
被测试机上设置

# vim /etc/sysctl.conf 
net.ipv4.tcp_syncookies = 0
# sysctl -p

__如果还是不行的话,需要在ab上面加-r参数,表示遇到错误继续压。而不是异常退出。__

被压测机器性能信息

CPU:双核2593.746MHz;内存:3917, 604 kB

Comments
Write a Comment