Fóir 的响应速度

网站与内容

已发布的内容由共享缓存提供，因此大多数访客根本不会访问数据库。在每秒 1,200 个请求的负载下，缓存页面的响应中位数为 7 ms，每 100 个请求中有 95 个在 46 ms 内返回。

尚未缓存的页面构建时间中位数为 262 ms，并对读取的每条记录应用每一条访问规则。

发布时，在新版本构建期间读者仍会收到之前的版本，因此发布从不会让访客等待。

通过共享读取通道的读取还会保存在靠近访客的 Cloudflare 边缘节点上，完整页面从那里返回的中位数为 28 ms。

应用

当 Fóir 作为您应用的后端时，大多数请求来自已登录的用户。这些请求绕过共享缓存，直接进入数据库，并对该用户应用您的访问规则。

已登录的客户读取自己的一条记录，响应中位数为 111 ms，每 100 个请求中有 95 个在 189 ms 内返回。保存一次修改需要 188 ms，紧随其后的读取在 112 ms 内即可看到修改。这些时间是从数据中心外部测得的，因此包含往返时间。

这些时间包含了对每一行的行级安全检查，而自建后端还需要在自己的数字上再加上这一部分。您声明谁能看到什么，我们的开源授权引擎 Demesne 会编写相应的策略。

与 EmDash 相比

在 ytyng 的测量中，EmDash 默认安装下一个纯文本页面返回首字节需要 0.39 到 0.94 秒。Fóir 的页面从 Cloudflare 边缘返回的中位数为 28 ms，未缓存的页面也能在 262 ms 内构建完成，同时解析引用并应用每一条访问规则。

与 Supabase 相比

Supabase 的行级安全指南展示了一条按最直接方式编写的策略：读取一张 10 万行的表要在数据库中花费 171 ms，直到手动重写并加上索引为止。在 Fóir 上，策略已经为您写好，已登录客户的完整请求从数据中心外部只需 111 ms。

与 Firebase 相比

Firebase 的安全规则为判断某人能否读取一个文档，最多只能查找另外 10 个文档。Fóir 的访问规则在数据库内部运行，因此一条规则可以沿着一个人的组织和授权一路查找，不受查找次数预算的限制。