nuxt 框架是不是性能很差?怎么优化呢
发布于 1 个月前 作者 hanzichi 2537 次浏览 来自 问答

项目使用了 nuxt 框架,但是 QA 反馈性能很差(通过压力测试)

我本地分别用了 next 和 nuxt 跑了压力测试,采用 helloworld 级别的最小仓库,next 的压测结果吞吐量是 nuxt 的五倍左右

我想问下在用 nuxt 的兄弟,nuxt 性能怎么样?怎么优化呢?

38 回复

是这样的,一般用 nuxt ssr 只是给搜索引擎用。 用户通过DNS 解析到 CDN 节点,nuxt SPA。 爬虫通过DNS解析到渲染服务器,nuxt SSR

@i5ting 谢谢狼叔回复,目前的疑问是,nuxt 是否真的如我测试的性能这么差?还是我测试有误?如果确定后,再转其他方案

@zuohuadong 谢谢回复,所以 nuxt 真的如我测试的性能这么差吗?那如果这样,纯的 nuxt 应用是否很难应用于并发量高的场景,都需要做两套方案吗(爬虫 ssr,普通用户 spa)?

@hanzichi

1)比例问题,控制好首屏模块个数,其实还好。 2)对api做cache。对返回的结果进行精简,最小化,保证吐出到浏览器的内容足够小。

其他能优化的不多了。

@hanzichi

2018年见过vue ssr,很少突破50 qps的。今年没关注。

@i5ting 目前测试的是 nuxt 的 helloworld 代码,本地测试结果吞吐量比 next 差好多倍,是否能说明 vue ssr 确实不太行?

@hanzichi ssr 渲染也比较局限。某些组件不支持。 nuxt 减少了首屏页面的大小,通过 云存储和 CDN 实际算下来要比 ssr 快不少。

@zuohuadong >通过 云存储和 CDN 实际算下来要比 ssr 快不少 说的是 spa 实际比 ssr 快不少的意思吗?

我觉得可以参考一下,总的来说react的生态圈总是比vue繁荣一些,虽然我用的是vue… https://segmentfault.com/a/1190000019067086?utm_source=tuicool&utm_medium=referral

去年用过 nuxt 现在已经基本弃坑了,性能太差

@hanzichi 没看过nuxt源码,不过之前试了一下直接用vue提供的api来做ssr性能还可以,建议你可以自己用最简单方式直接用vue的api来做ssr压测一下。官方的benchmark的数据vuessr的性能是比react好一丢丢的

@hanzichi 不是~ SPA 首屏渲染还是要比 SSR 的慢。 只是综合下来,网络、缓存。

用pm2起过多个端口给nuxt,并发高的时候有端口直接被kill

即使用了组件缓存,优化效果也并不理想

目前正在用nuxt,4c4g 单机 200TPS,跟原来的 java web 持平,没跟 next 对比过 ~ 生态确实不理想,加上会报一些迷之bug

@mosaic101 tps是每秒事务个数吧?

发一下监控截图看看。如果是200qps还是很不错的。

@i5ting 200qps 就算不错了嘛?我加了页面缓存,然后qps勉强 300 多。。。正常嘛?

@i5ting 只有一个 request,压得一个首屏页面(SEO+首屏数据)~ 截图没了,下次再压一次看看

@hanzichi 建议你跑一个 nuxt-hackernews 试试,这个是官方极致优化过的,看看能快点不 另外注意下是跑在dev模式下还是production模式下?要用 npm run build && npm run start 来测试而不是 npm run dev

我在本机用两个框架跑helloworld实测数据给你参考下: nuxt:

Server Software:
Server Hostname:        127.0.0.1
Server Port:            3000

Document Path:          /
Document Length:        1395 bytes

Concurrency Level:      200
Time taken for tests:   7.438 seconds
Complete requests:      3000
Failed requests:        0
Total transferred:      4851000 bytes
HTML transferred:       4185000 bytes
Requests per second:    403.32 [#/sec] (mean)
Time per request:       495.885 [ms] (mean)
Time per request:       2.479 [ms] (mean, across all concurrent requests)
Transfer rate:          636.88 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       1
Processing:    94  477  70.1    470     697
Waiting:       43  442  66.9    441     609
Total:         94  477  70.1    470     697

nuxt-hackernews:

Server Software:
Server Hostname:        127.0.0.1
Server Port:            3000

Document Path:          /
Document Length:        0 bytes

Concurrency Level:      200
Time taken for tests:   3.679 seconds
Complete requests:      3000
Failed requests:        0
Non-2xx responses:      3000
Total transferred:      285000 bytes
HTML transferred:       0 bytes
Requests per second:    815.40 [#/sec] (mean)
Time per request:       245.280 [ms] (mean)
Time per request:       1.226 [ms] (mean, across all concurrent requests)
Transfer rate:          75.65 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       1
Processing:   105  233  37.3    235     324
Waiting:       35  210  35.8    213     294
Total:        105  233  37.3    235     324

Percentage of the requests served within a certain time (ms)
  50%    235
  66%    248
  75%    257
  80%    262
  90%    282
  95%    290
  98%    304
  99%    311
 100%    324 (longest request)

next:

Server Software:
Server Hostname:        127.0.0.1
Server Port:            3000

Document Path:          /
Document Length:        1383 bytes

Concurrency Level:      200
Time taken for tests:   4.105 seconds
Complete requests:      3000
Failed requests:        0
Total transferred:      4947000 bytes
HTML transferred:       4149000 bytes
Requests per second:    730.73 [#/sec] (mean)
Time per request:       273.699 [ms] (mean)
Time per request:       1.368 [ms] (mean, across all concurrent requests)
Transfer rate:          1176.73 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       1
Processing:    65  266  32.2    264     385
Waiting:        7  249  31.8    245     373
Total:         66  266  32.2    265     385

Percentage of the requests served within a certain time (ms)
  50%    265
  66%    271
  75%    277
  80%    288
  90%    310
  95%    322
  98%    343
  99%    363
 100%    385 (longest request)

@andyhu

谢谢,确实我本地没有用 production 但是我有个应用,开了 production,吞吐量 50,再开 cache 也才 300,会是什么原因呢? 我看哪个 nuxt-hackernews 好像并没有使用缓存,它的核心优化点是什么呢?

@hanzichi 有很多优化,比如 component cache,这个是一个很有优势的缓存,另外还有 pwa,以及还有一些优化是图片懒加载,还有链接预读取。这些都是优化的地方。但是我其实也不是特别懂。我主要是没遇到过严重的性能问题,Nuxt 肯定是要比 Next 慢一点,严重情况下可能会慢一倍,但也不至于特别离谱。Vue 3 出来以后应该会有所改观

@zuohuadong 老哥,这样的操作有什么相关资料吗?

@andyhu 谢谢你的回复给我打开了新的思路,感谢

不过图片懒加载应该不会影响吞吐量数据吧,另外 nuxt-hackernews 也没用 component cache,得好好研究下它优化了啥提升了性能,兄弟有什么思路吗

@andyhu 另外还有 pwa,以及还有一些优化是图片懒加载,还有链接预读取 这些如果不是用浏览器来测试,而是用工具测对结果应该没什么影响吧

@andyhu 我测试了下 nuxt-hackernews,你测的应该是首页,它会重定向到 /news,我猜测可能就是个重定向,页面源码只是个 redirect,所以比较快?我 curl / 拿不到任何数据

我试了其他页面,比如直接压 /news,Requests per second 这项都不会超过 100

@AcerFeng 组件缓存,为啥不直接上页面缓存呢?

@i5ting 对于狼叔提的两个优化点,想再跟进请教下

控制好首屏模块个数,对返回的结果进行精简,保证吐出到浏览器的内容足够小,这意思是不是首屏内容做 ssr 服务端渲染,非首屏内容走浏览器请求客户端渲染?如果是这样的话,对于 seo 的需求如何满足呢?

@hanzichi 核心内容是啥,比如视频,核心肯定是视频信息,如果必要把播放相关的信息聚合进来。保证rt在20到50ms以内。那么你的首屏是足够满足seo和性能的。如果不能可能你ui设计有问题,核心内容不在首屏

@hanzichi 页面有些数据是动态获取要更新的

@i5ting 弱弱问下rt是啥意思?

@AcerFeng 是指这些数据需要实时的吗,每秒看到的都要不一样?还是说缓存几秒钟几分钟没啥意义?

@hanzichi 类似资讯平台门户网站的数据

回到顶部