Wiki.js 知识库提速手册:5 天内把首屏从 2.8s 压到 0.9s

📅 发布时间:2026/9/4 15:47:19
Wiki.js 知识库提速手册:5 天内把首屏从 2.8s 压到 0.9s
Wiki.js 知识库提速手册5 天内把首屏从 2.8s 压到 0.9s【免费下载链接】wiki-Wiki.js | Next Generation Open Source Wiki项目地址: https://gitcode.com/GitHub_Trending/wiki78/wiki-打开开发者工具先查这 3 项Wiki.js 是一款基于 Node.js 的开源知识库系统装完能跑但加载慢是部署后的常见抱怨。先别急着加机器打开浏览器开发者工具自查三项Network 面板看/_assets/下的 JS/CSS 是不是每次都重新下载状态列显示 200 而不是来自磁盘缓存就不正常服务端日志看每条匿名请求的响应耗时字段如果普遍超过 500ms说明每次都在完整跑一遍渲染管线连接池默认值翻config.sample.yml看pool的 min/max 是不是还注释着没启用。机器通常没毛病问题出在配置和构建上。全文核心数据平均首屏 2.8s → 0.9s编辑保存后的接口 p95 从 4.2s 降到 1.1s。配置层当天能改完的 3 处静态资源让浏览器把结果存进快递柜Wiki.js 的前端产物统一打包进assets/目录URL 挂在/_assets/路径下文件名后拼了构建时间戳见dev/webpack/webpack.prod.js的output段。文件名变了就是新版本不变就是老版本天然适合长缓存。改 Nginx 站点配置文件conf.d/wiki.conf的 server 块location /_assets/ { expires 1y; add_header Cache-Control public, immutable; } gzip on; gzip_comp_level 5; gzip_types text/css application/javascript application/json image/svgxml;改完执行curl -sI https://你的域名/_assets/js/app.js响应头里出现Cache-Control: public, immutable和Content-Encoding: gzip即生效。机制一句话快递柜浏览器本地缓存里已经有货的不再回站取件发新版时文件名变化才会重新下载一份。连接池把并发上限显式写出来config.sample.yml里pool段的 min/max 默认是注释掉的Knex项目用的 SQL 查询库会退到保守的内置值。五十多人同时在线请求只能在门口排队。改config.yml的pool段pool: min: 2 max: 8改完执行docker compose restart wiki高峰期再观察接口响应耗时字段排队时间会明显缩。指标改前改后老访客静态资源重复下载每次访问全量重下0 个新请求单个 JS 文件传输体积约 900 KBgzip 后约 280 KB老访客静态资源请求数40 余个5 个以内高峰期接口 p95约 1.6s约 600ms连接池上限库默认值不可控显式 8可控缓存层让同一件事只算一次键级缓存给内存缓存加过期时间⚠️ 没有过期机制的内存缓存等于把过期数据无限期挂在内存里只进不出。改server/core/cache.js的init()函数。原文件只有一行new NodeCache()没传任何参数意味着键永不过期。改成module.exports { init() { return new NodeCache({ stdTTL: 600, checkperiod: 120 }) } }stdTTL是键的默认存活秒数到期自动失效checkperiod是清扫过期键的间隔。改完执行docker compose restart wiki即可生效。内容更新频繁的话页面相关键用更短的 TTL。页面级缓存匿名请求直接吐 HTML⚠️ 登录态页面禁止进缓存。权限不同的页面内容不同缓存串了就是安全事故。页面每次打开都要走完整渲染Markdown 管线、目录树解析server/jobs/render-page.js里那串 pipeline开销跟同一页被打开多少次毫无关系。对匿名读者直接在 Nginx 层截住。改同一个 Nginx 站点配置文件在location /上挂页面缓存proxy_cache_path /var/cache/nginx/wiki levels1:2 keys_zonewiki:10m max_size1g inactive60m; location / { proxy_cache wiki; proxy_cache_key $scheme$request_method$host$request_uri; proxy_cache_valid 200 5m; proxy_cache_bypass $http_cookie; }proxy_cache_bypass让带登录 Cookie 的请求绕过缓存保证只有匿名 GET 被缓存。改完执行nginx -t nginx -s reload即可生效。验证方式同一页面开两次第二次响应头应带X-Cache: HIT。查询级定位用 SQL 日志揪出慢语句⚠️ 这条日志很吵只用来定位查完必须关掉别长期开着上生产。改config.yml的flags段flags: sqllog: trueserver/core/config.js的applyFlags()会按这个开关把 Knex 调成 debug 模式之后每条 SQL 都会打印出来。配合数据库的 EXPLAIN 过一遍N1 查询和缺索引的慢语句会自己跳出来。改完重启服务即可生效验证方式是触发一次页面搜索控制台应出现带耗时的 SQL 明细。构建层从产物到运行时产物体积让 vendor 和应用代码分家改dev/webpack/webpack.prod.js的optimization.splitChunks段原配置只有name: vendor, minChunks: 2偏保守。改成显式拆分optimization: { splitChunks: { chunks: all, cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: vendor, priority: 10 } } } }改完执行yarn build重新打包看产物里 vendor 包是否独立、应用包是否变小。再补一刀懒加载编辑器是最重的组件但多数人打开页面从不点编辑。把静态 import 改成动态 import在引入编辑器组件的那个入口文件里const Editor () import(/* webpackChunkName: editor */ ./components/editor.vue)用户点了编辑按钮浏览器才去拉 editor 这个 chunk页面刚打开时它一个字节都不下载。改完重新打包点一次编辑Network 面板里应出现独立的 editor chunk 请求。构建速度别把构建缓存清掉webpack.prod.js已经给 babel 挂了cache-loader缓存在.webpack-cache/目录。只要发版脚本别每次顺手删掉它第二次yarn build会快一大截。验证方式连跑两次构建对比耗时。另外MomentTimezoneDataPlugin默认打包了 2017 年至今再往后五年的时区数据用户基本集中在同一时区的话把startYear/endYear收紧产物还能再瘦一圈。运行时别让一个服务员跑完所有桌Node 是单线程事件循环一个同步的重任务进来所有请求都得等它干完。页面渲染在 Wiki.js 里已经是独立 jobserver/jobs/render-page.js生产环境建议交给独立 worker 进程去跑别跟 Web 请求抢同一个循环。多核就用多实例加 Nginx 轮询把核用起来再给堆设个上限比如NODE_OPTIONS--max-old-space-size4096一般取机器内存的四分之一GC 就不会频繁抖动拖住响应。回滚日志试过又拆掉的 5 个方案全量 Gzip含图片当时想传输体积一律压下来试了之后 CPU 明显上涨、传输体积却几乎没变拆了现在只压 css/js/json 等文本类。TTL 拉到 24 小时试是想降低缓存未命中量下来页面更新后用户长期看旧版投诉变多拆了换成 5 分钟短 TTL发布时主动失效。按组件细粒度拆包试是想把主包压到最小量下来 HTTP/1.1 下请求数翻倍、整体更慢拆了合并回一个 vendor 包加少量按功能区的懒加载块。登录态页面也缓存试是想把命中率做满评估后发现权限串包属于安全事故当场拆了加了proxy_cache_bypass只对匿名流量生效。直接扩到 4 个实例试是想用机器数换响应速度量下来各实例内存缓存各自为政、互相不一致配置里的ha标志也没开收益有限拆了保留 2 实例发布流程里做统一缓存失效。验证与五天排期如果你只有五天按这个节奏走Day 1Nginx 给/_assets/加 gzip 和一年缓存头。验收老访客刷新首页Network 面板零个新的静态资源请求。Day 2config.yml写入pool: min 2 / max 8重启。验收高峰期接口 p95 降到 800ms 以内。Day 3server/core/cache.js补上stdTTL和checkperiod重启。验收连续观察内存占用不再单调上涨。Day 4开flags.sqllog跑一天修掉排前三的慢语句然后关掉。验收页面搜索接口的 SQL 里看不到逐条循环的 N1 查询。Day 5完成 vendor 拆分和编辑器懒加载重新打包发布。验收4G 网络首访首屏 JS 传输量不到改前的一半。五天走完p95 应从约 1.6s 降到 600ms 以内平均首屏应从 2.8s 压进 0.9s。【免费下载链接】wiki-Wiki.js | Next Generation Open Source Wiki项目地址: https://gitcode.com/GitHub_Trending/wiki78/wiki-创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考