尧图网站建设 
Ghost 性能测试与基准压测实战指南用 loadtest 与 Artillery 验证高流量工作流【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost本文是一份面向 Ghost 贡献者与自托管用户的性能测试操作手册聚焦两个社区常用工具——轻量级单端点压测工具loadtest与支持多步骤、分阶段流量建模的artillery并结合本仓库的本地开发环境、前端缓存中间件与缓存配置源码说明如何设计可复现的基准测试、读懂结果并规避干扰因素。读完本文你将能够在本仓库的本地开发环境默认http://localhost:2368中对特定页面或工作流发起受控负载判断某次改动是提升还是劣化了目标流程的性能。为什么 Ghost 需要性能测试Ghost 面向的是高流量或高强度场景媒体发布、会员订阅、邮件列表等其中存在大量“读多写少”的公开页面渲染与会员鉴权链路。对单个改动跑一遍功能测试往往不够——一个看似无害的渲染逻辑变更在 50 并发、持续数十秒的负载下才可能暴露出查询膨胀或内存抖动问题。因此本仓库的贡献文档 docs/contributing/performance-testing.md 明确建议针对高流量或高强度的核心工作流在合入前进行性能验证。文中推荐了两类工具适用场景各不相同工具定位适用场景loadtest简单、单端点、命令行即用快速验证某个 URL如首页/在固定并发或固定速率下的表现artilleryYAML 定义、多步骤流程、分阶段流量模拟“访问首页 → 打开某篇文章 → 触发搜索/订阅”等复合流程或模拟爬升、波峰等真实流量形态两者都可以通过 pnpm 的dlx按需执行无需全局安装与本仓库基于 pnpm 的 monorepo 工作流保持一致。前置准备跑起本地 Ghost性能测试的第一步是有一个确定、干净的测试对象。本仓库默认把 Ghost 服务监听在本机2368端口这一默认值可以直接在 ghost/core/core/shared/config/defaults.json 中看到url: http://localhost:2368, server: { host: 127.0.0.1, port: 2368, shutdownTimeout: 60000 }按 docs/contributing/development-setup.md 的说明仓库推荐的标准开发形态是Ghost Core 及其依赖MySQL、Redis、Mailpit跑在 Docker 中前端构建 watcher 跑在宿主机上并通过 Caddy 网关暴露在http://localhost:2368。启动方式为在仓库根目录执行pnpm dev首次运行会构建开发镜像耗时较长之后即可访问站点http://localhost:2368管理后台http://localhost:2368/ghost/开发邮件Mailpithttp://localhost:8025测试前请注意端口占用问题——开发环境默认绑定80、2368、3306、6379、8025、8026等端口需要先停掉占用这些端口的本机服务。第一次在新数据库上启动时需要通过 Admin 完成 owner 账号初始化压测公开首页前也应先写入一些真实内容与主题资源避免结果被空库下的极端路径扭曲。使用 loadtest 压测单个端点loadtest适合“就一个 URL想知道它能扛住多少”的场景。它最简单也最常用命令行参数直白。指定总请求数与并发数原文档给出的第一条命令是总计发起500个请求并发5路pnpm dlx loadtest -n 500 -c 5 http://localhost:2368/解释-n--requests指定请求总数-c--concurrency指定同时保持的并发连接数。执行完毕后loadtest会在终端汇总报告请求总数、失败数、每秒请求数RPS以及各百分位的延迟分布。你可以通过逐步提高-c如 5 → 25 → 100来观察系统吞吐与延迟拐点。固定速率、持续时长压测如果希望以“恒定的每秒请求数”进行一段固定时长的压测可以用-t时长秒配合--rps每秒请求数pnpm dlx loadtest -t 30 --rps 50 http://localhost:2368/即以每秒 50 个请求的速率连续打 30 秒。这种方式更接近“稳定的真实访问量”便于观察长时间运行下是否出现连接堆积、内存增长或超时抬升。需要提醒的是loadtest的完整命令与参数选项如 keep-alive、自定义 header、超时等以它的官方 README 为准原文档也明确指向其 README 获取“当前”的参数列表——压测工具迭代快务必以执行时安装到的版本所输出的帮助信息为准可运行pnpm dlx loadtest --help查看。使用 Artillery 做多步骤与分阶段压测当被测对象不是一个孤立的 URL而是一条“工作流”——例如访问者依次浏览首页、文章页再触发一次会员操作——单个loadtest命令就无法表达了。此时使用artillery它用 YAML 文件描述测试天然支持分阶段改变流量速率phased rates、在同一流程内串联多个请求、并通过 processor 函数生成可变输入。最小可运行的 Artillery 场景原文档给出了一个最小定义以50请求/秒的到达速率持续15秒反复请求首页config: target: http://localhost:2368 phases: - duration: 15 arrivalRate: 50 scenarios: - name: Home page flow: - get: url: /target被测服务的基准地址phases负载分阶段定义这里只有一个阶段——duration: 15表示持续 15 秒arrivalRate: 50表示每秒新创建 50 个虚拟用户请求scenarios场景与流程定义每个场景可含多个请求步骤这里的Home page场景仅发起一次针对/的get请求。把上述内容保存为load-test.yml即可执行pnpm dlx artillery run load-test.yml从单请求场景扩展出真实工作流Artillery 的价值在“多步流程 可变输入”。把多个请求依次写入同一个scenario.flow即可模拟真实访客的一次会话例如“先取首页、再取一篇文章页”还可加上think步骤模拟阅读停顿config: target: http://localhost:2368 phases: - duration: 60 arrivalRate: 10 rampTo: 40 scenarios: - name: Browse flow flow: - get: url: / - think: 2 - get: url: /welcome/这里也展示了 phased rate 的典型写法从每秒 10 个用户逐步爬升rampTo到 40 个用于观察扩容/爬坡阶段的延迟表现。processor 函数beforeRequest之类的钩子则可以在请求发出前按需生成 URL、Cookie 或请求体实现“每次请求都打不同文章页”的可变输入——这正对应原文档所说的“processor functions for variable input”。如何得到有用的结果压测不难难的是让结果“有意义”。原文档特别强调了一组极易被忽略、却会显著改变结果走向的变量请求参数要匹配被测行为连接复用keep-alive / pooling是否开启 HTTP 连接复用直接影响握手开销被摊薄与否超时与并发客户端超时设置、并发模型决定负载是“排队等待”还是“直接失败”Cookie 与 Header登录态、User-Agent、Accept 等都会影响服务端是走“公开缓存路径”还是“会员私有渲染路径”详见下文源码分析。压测参数的取向必须与被调查的行为一致如果你要验证的是“匿名访客刷首页”就不要带上会引入会员鉴权的 Cookie。明确“缓存命中”还是“未命中”Ghost 会对公开内容做缓存因此在设计测试时必须事先决定本次压测测的是缓存命中路径还是未命中路径二者结论不可混用。从源码可以非常清楚地看到这一点。Ghost 前端有一层专门的缓存头中间件 ghost/core/core/frontend/web/middleware/frontend-caching.js其核心逻辑是带主题预览头X-Ghost-Preview、以/p/开头的预览路径、以及 gift-link 请求一律不发缓存头站点为私有博客、或请求携带会员身份而站点未开启cacheMembersContent时响应被标记为private公开非会员请求默认走public缓存路径其Cache-Control: max-age取自配置caching:frontend:maxAge。缓存时长全部收敛在 ghost/core/core/shared/config/defaults.json 的caching配置块中可见其默认值caching: { 301: { maxAge: 31536000 }, frontend: { maxAge: 0 }, publicAssets: { maxAge: 31536000 }, customRedirects: { maxAge: 31536000 }, favicon: { maxAge: 86400 }, sitemap: { maxAge: 3600 }, ... }要点开发环境下frontend.maxAge默认为 0也就是说本地默认不会在浏览器/CDN 层面缓存页面正文压测打到的是真实渲染路径而静态资源publicAssets、301 跳转等则默认缓存长达一年sitemap 缓存 1 小时。因此压测 URL 前先想清楚你压的是文章页渲染还是静态资源分发两者对应的中间件与配置完全不同。若需在本地模拟“缓存命中”的线上形态可在自定义配置中调大caching:frontend:maxAge该中间件会实时读取该配置。此外若想验证“带 Redis 缓存的架构”可以关注 ghost/core/core/server/adapters/cache/index.jsGhost 通过 adapter-manager 提供缓存适配器默认内存MemoryCache也提供 Redis 实现可按功能域如settings、theme、urls分别配置。用redis适配器替换默认缓存后不同 worker 之间共享缓存压测结论也会随之变化——这属于更接近生产形态的测试前提。本地结果的意义与边界原文档给出了一条务实的原则本地测试从http://localhost:2368起步本地硬件与生产托管环境存在差异但**本地结果仍然足以回答“某次改动是否让目标流程变得更好或更差”**这一相对问题。因此推荐的实践是在改动前后跑完全相同的压测命令与参数同一 URL、同一速率、同一时长记录关键指标错误率、P50/P95/P99、RPS作为基线用相对变化而非绝对值下结论。需要留意的是本地压测与生产差异主要来自硬件、数据库规模与网络层。若压测并发较高建议把压测机与服务分开或使用另一台机器发起请求避免压测客户端自身成为瓶颈。测试的边界与合规提醒最后一点同样重要原文档在结尾明确划出了红线只对你拥有、或被明确授权测试的系统施加负载公共仓库并不提供针对生产环境或托管服务如 Ghost(Pro)的压测流程——不要对公共 Ghost 托管站点发起压测压测工具的命令与场景选项随版本演进务必以执行时工具的官方文档与--help输出为准原文档亦以此方式指向loadtestREADME 与 Artillery 官方文档。遵守这些边界既是工程礼仪也是避免把性能测试变成一次“人为事故”的前提。小结本文从 docs/contributing/performance-testing.md 出发完整覆盖了两类压测工具的用法loadtest的-n/-c定总数并发模式与-t/--rps固定速率时长模式以及artillery基于 YAML 的分阶段、多步骤场景定义。在此基础上结合仓库源码补充了三条支撑性结论Ghost 开发环境默认监听127.0.0.1:2368见 defaults.jsonpnpm dev即可拉起完整 Docker 开发栈见 development-setup.mdGhost 前端公开内容有中间件控制的缓存策略见 frontend-caching.js各路径缓存时长由caching配置统一管理测“命中”还是“未命中”必须预先界定缓存后端经由 adapter-manager 可切换内存与 Redis 实现见 cache/index.js更贴近生产的缓存架构会改变压测结论。对任何一次高流量相关改动建议把上述命令固化为可重复的基准脚本在改动前后各跑一遍并比较分布指标——这就是 Ghost 贡献流程中最轻量、有效的性能回归防线。【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ghost 性能测试与基准压测实战指南：用 loadtest 与 Artillery 验证高流量工作流
Ghost 性能测试与基准压测实战指南用 loadtest 与 Artillery 验证高流量工作流【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost本文是一份面向 Ghost 贡献者与自托管用户的性能测试操作手册聚焦两个社区常用工具——轻量级单端点压测工具loadtest与支持多步骤、分阶段流量建模的artillery并结合本仓库的本地开发环境、前端缓存中间件与缓存配置源码说明如何设计可复现的基准测试、读懂结果并规避干扰因素。读完本文你将能够在本仓库的本地开发环境默认http://localhost:2368中对特定页面或工作流发起受控负载判断某次改动是提升还是劣化了目标流程的性能。为什么 Ghost 需要性能测试Ghost 面向的是高流量或高强度场景媒体发布、会员订阅、邮件列表等其中存在大量“读多写少”的公开页面渲染与会员鉴权链路。对单个改动跑一遍功能测试往往不够——一个看似无害的渲染逻辑变更在 50 并发、持续数十秒的负载下才可能暴露出查询膨胀或内存抖动问题。因此本仓库的贡献文档 docs/contributing/performance-testing.md 明确建议针对高流量或高强度的核心工作流在合入前进行性能验证。文中推荐了两类工具适用场景各不相同工具定位适用场景loadtest简单、单端点、命令行即用快速验证某个 URL如首页/在固定并发或固定速率下的表现artilleryYAML 定义、多步骤流程、分阶段流量模拟“访问首页 → 打开某篇文章 → 触发搜索/订阅”等复合流程或模拟爬升、波峰等真实流量形态两者都可以通过 pnpm 的dlx按需执行无需全局安装与本仓库基于 pnpm 的 monorepo 工作流保持一致。前置准备跑起本地 Ghost性能测试的第一步是有一个确定、干净的测试对象。本仓库默认把 Ghost 服务监听在本机2368端口这一默认值可以直接在 ghost/core/core/shared/config/defaults.json 中看到url: http://localhost:2368, server: { host: 127.0.0.1, port: 2368, shutdownTimeout: 60000 }按 docs/contributing/development-setup.md 的说明仓库推荐的标准开发形态是Ghost Core 及其依赖MySQL、Redis、Mailpit跑在 Docker 中前端构建 watcher 跑在宿主机上并通过 Caddy 网关暴露在http://localhost:2368。启动方式为在仓库根目录执行pnpm dev首次运行会构建开发镜像耗时较长之后即可访问站点http://localhost:2368管理后台http://localhost:2368/ghost/开发邮件Mailpithttp://localhost:8025测试前请注意端口占用问题——开发环境默认绑定80、2368、3306、6379、8025、8026等端口需要先停掉占用这些端口的本机服务。第一次在新数据库上启动时需要通过 Admin 完成 owner 账号初始化压测公开首页前也应先写入一些真实内容与主题资源避免结果被空库下的极端路径扭曲。使用 loadtest 压测单个端点loadtest适合“就一个 URL想知道它能扛住多少”的场景。它最简单也最常用命令行参数直白。指定总请求数与并发数原文档给出的第一条命令是总计发起500个请求并发5路pnpm dlx loadtest -n 500 -c 5 http://localhost:2368/解释-n--requests指定请求总数-c--concurrency指定同时保持的并发连接数。执行完毕后loadtest会在终端汇总报告请求总数、失败数、每秒请求数RPS以及各百分位的延迟分布。你可以通过逐步提高-c如 5 → 25 → 100来观察系统吞吐与延迟拐点。固定速率、持续时长压测如果希望以“恒定的每秒请求数”进行一段固定时长的压测可以用-t时长秒配合--rps每秒请求数pnpm dlx loadtest -t 30 --rps 50 http://localhost:2368/即以每秒 50 个请求的速率连续打 30 秒。这种方式更接近“稳定的真实访问量”便于观察长时间运行下是否出现连接堆积、内存增长或超时抬升。需要提醒的是loadtest的完整命令与参数选项如 keep-alive、自定义 header、超时等以它的官方 README 为准原文档也明确指向其 README 获取“当前”的参数列表——压测工具迭代快务必以执行时安装到的版本所输出的帮助信息为准可运行pnpm dlx loadtest --help查看。使用 Artillery 做多步骤与分阶段压测当被测对象不是一个孤立的 URL而是一条“工作流”——例如访问者依次浏览首页、文章页再触发一次会员操作——单个loadtest命令就无法表达了。此时使用artillery它用 YAML 文件描述测试天然支持分阶段改变流量速率phased rates、在同一流程内串联多个请求、并通过 processor 函数生成可变输入。最小可运行的 Artillery 场景原文档给出了一个最小定义以50请求/秒的到达速率持续15秒反复请求首页config: target: http://localhost:2368 phases: - duration: 15 arrivalRate: 50 scenarios: - name: Home page flow: - get: url: /target被测服务的基准地址phases负载分阶段定义这里只有一个阶段——duration: 15表示持续 15 秒arrivalRate: 50表示每秒新创建 50 个虚拟用户请求scenarios场景与流程定义每个场景可含多个请求步骤这里的Home page场景仅发起一次针对/的get请求。把上述内容保存为load-test.yml即可执行pnpm dlx artillery run load-test.yml从单请求场景扩展出真实工作流Artillery 的价值在“多步流程 可变输入”。把多个请求依次写入同一个scenario.flow即可模拟真实访客的一次会话例如“先取首页、再取一篇文章页”还可加上think步骤模拟阅读停顿config: target: http://localhost:2368 phases: - duration: 60 arrivalRate: 10 rampTo: 40 scenarios: - name: Browse flow flow: - get: url: / - think: 2 - get: url: /welcome/这里也展示了 phased rate 的典型写法从每秒 10 个用户逐步爬升rampTo到 40 个用于观察扩容/爬坡阶段的延迟表现。processor 函数beforeRequest之类的钩子则可以在请求发出前按需生成 URL、Cookie 或请求体实现“每次请求都打不同文章页”的可变输入——这正对应原文档所说的“processor functions for variable input”。如何得到有用的结果压测不难难的是让结果“有意义”。原文档特别强调了一组极易被忽略、却会显著改变结果走向的变量请求参数要匹配被测行为连接复用keep-alive / pooling是否开启 HTTP 连接复用直接影响握手开销被摊薄与否超时与并发客户端超时设置、并发模型决定负载是“排队等待”还是“直接失败”Cookie 与 Header登录态、User-Agent、Accept 等都会影响服务端是走“公开缓存路径”还是“会员私有渲染路径”详见下文源码分析。压测参数的取向必须与被调查的行为一致如果你要验证的是“匿名访客刷首页”就不要带上会引入会员鉴权的 Cookie。明确“缓存命中”还是“未命中”Ghost 会对公开内容做缓存因此在设计测试时必须事先决定本次压测测的是缓存命中路径还是未命中路径二者结论不可混用。从源码可以非常清楚地看到这一点。Ghost 前端有一层专门的缓存头中间件 ghost/core/core/frontend/web/middleware/frontend-caching.js其核心逻辑是带主题预览头X-Ghost-Preview、以/p/开头的预览路径、以及 gift-link 请求一律不发缓存头站点为私有博客、或请求携带会员身份而站点未开启cacheMembersContent时响应被标记为private公开非会员请求默认走public缓存路径其Cache-Control: max-age取自配置caching:frontend:maxAge。缓存时长全部收敛在 ghost/core/core/shared/config/defaults.json 的caching配置块中可见其默认值caching: { 301: { maxAge: 31536000 }, frontend: { maxAge: 0 }, publicAssets: { maxAge: 31536000 }, customRedirects: { maxAge: 31536000 }, favicon: { maxAge: 86400 }, sitemap: { maxAge: 3600 }, ... }要点开发环境下frontend.maxAge默认为 0也就是说本地默认不会在浏览器/CDN 层面缓存页面正文压测打到的是真实渲染路径而静态资源publicAssets、301 跳转等则默认缓存长达一年sitemap 缓存 1 小时。因此压测 URL 前先想清楚你压的是文章页渲染还是静态资源分发两者对应的中间件与配置完全不同。若需在本地模拟“缓存命中”的线上形态可在自定义配置中调大caching:frontend:maxAge该中间件会实时读取该配置。此外若想验证“带 Redis 缓存的架构”可以关注 ghost/core/core/server/adapters/cache/index.jsGhost 通过 adapter-manager 提供缓存适配器默认内存MemoryCache也提供 Redis 实现可按功能域如settings、theme、urls分别配置。用redis适配器替换默认缓存后不同 worker 之间共享缓存压测结论也会随之变化——这属于更接近生产形态的测试前提。本地结果的意义与边界原文档给出了一条务实的原则本地测试从http://localhost:2368起步本地硬件与生产托管环境存在差异但**本地结果仍然足以回答“某次改动是否让目标流程变得更好或更差”**这一相对问题。因此推荐的实践是在改动前后跑完全相同的压测命令与参数同一 URL、同一速率、同一时长记录关键指标错误率、P50/P95/P99、RPS作为基线用相对变化而非绝对值下结论。需要留意的是本地压测与生产差异主要来自硬件、数据库规模与网络层。若压测并发较高建议把压测机与服务分开或使用另一台机器发起请求避免压测客户端自身成为瓶颈。测试的边界与合规提醒最后一点同样重要原文档在结尾明确划出了红线只对你拥有、或被明确授权测试的系统施加负载公共仓库并不提供针对生产环境或托管服务如 Ghost(Pro)的压测流程——不要对公共 Ghost 托管站点发起压测压测工具的命令与场景选项随版本演进务必以执行时工具的官方文档与--help输出为准原文档亦以此方式指向loadtestREADME 与 Artillery 官方文档。遵守这些边界既是工程礼仪也是避免把性能测试变成一次“人为事故”的前提。小结本文从 docs/contributing/performance-testing.md 出发完整覆盖了两类压测工具的用法loadtest的-n/-c定总数并发模式与-t/--rps固定速率时长模式以及artillery基于 YAML 的分阶段、多步骤场景定义。在此基础上结合仓库源码补充了三条支撑性结论Ghost 开发环境默认监听127.0.0.1:2368见 defaults.jsonpnpm dev即可拉起完整 Docker 开发栈见 development-setup.mdGhost 前端公开内容有中间件控制的缓存策略见 frontend-caching.js各路径缓存时长由caching配置统一管理测“命中”还是“未命中”必须预先界定缓存后端经由 adapter-manager 可切换内存与 Redis 实现见 cache/index.js更贴近生产的缓存架构会改变压测结论。对任何一次高流量相关改动建议把上述命令固化为可重复的基准脚本在改动前后各跑一遍并比较分布指标——这就是 Ghost 贡献流程中最轻量、有效的性能回归防线。【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考