Fóirの応答速度

ウェブサイトとコンテンツ

公開されたコンテンツは共有キャッシュから配信されるため、ほとんどの訪問者はデータベースに到達しません。キャッシュ済みのページは中央値7 msで返り、毎秒1,200リクエストが届く中でも、100件中95件は46 ms以内に返ります。

まだキャッシュされていないページは中央値262 msで構築され、読み込むすべてのレコードにすべてのアクセスルールが適用されます。

公開すると、新しいバージョンが構築される間も読者には以前のバージョンが届くため、公開によって訪問者を待たせることはありません。

共有読み取りレーン経由の読み取りは、訪問者に近いCloudflareのエッジにも保持され、そこからページ全体が中央値28 msで返ります。

アプリケーション

Fóirをアプリのバックエンドにすると、リクエストのほとんどはサインインしたユーザーから届きます。それらは共有キャッシュを通らずにデータベースへ向かい、その人に対してアクセスルールが適用されます。

サインインした顧客が自分のレコードを読むと、中央値111 msで応答があり、100件中95件は189 ms以内です。変更の保存は188 ms、その直後の読み取りは112 msで変更を反映します。これらの時間はデータセンターの外から計測しているため、往復の通信時間を含みます。

これらの時間には、すべての行に対する行レベルセキュリティのチェックが含まれています。自前で構築したバックエンドなら、自らの数値にこれを上乗せする必要があります。誰が何を見られるかを宣言すれば、オープンソースの認可エンジンDemesneがポリシーを書きます。

EmDashとの比較

EmDashの標準インストールでは、テキストのみのページが最初のバイトを返すまでに0.39〜0.94秒かかりました（ytyngの計測）。Fóirのページは中央値28 msでCloudflareのエッジから届き、キャッシュされていないページも、参照を解決しすべてのアクセスルールを適用した上で262 msで構築されます。

Supabaseとの比較

Supabaseの行レベルセキュリティのガイドでは、素直に書いたポリシーが10万行のテーブルを読むのにデータベース内で171 msかかり、手作業で書き直してインデックスを張るまでそのままである例が示されています。Fóirではポリシーがあらかじめ書かれており、サインインした顧客のリクエスト全体がデータセンターの外から111 msで完了します。

Firebaseとの比較

Firebaseのセキュリティルールは、誰かが1つのドキュメントを読めるかを判断するために、他のドキュメントを最大10件までしか参照できません。Fóirのアクセスルールはデータベースの中で動くため、参照回数の上限を気にせず、ルールが人を組織や権限付与までたどれます。