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 페이지는 Cloudflare 엣지에서 중앙값 28 ms에 도착하고, 캐시되지 않은 페이지도 참조를 해결하고 모든 접근 규칙을 적용한 채 262 ms에 만들어집니다.

Supabase와 비교

Supabase의 행 수준 보안 가이드는 가장 단순하게 작성한 정책이 10만 행 테이블을 읽는 데 데이터베이스에서 171 ms를 쓰고, 직접 다시 작성하고 인덱스를 추가해야 빨라지는 예를 보여 줍니다. Fóir에서는 정책이 이미 작성되어 있으며, 로그인한 고객의 전체 요청이 데이터 센터 밖에서 111 ms에 끝납니다.

Firebase와 비교

Firebase의 보안 규칙은 누군가가 문서 하나를 읽을 수 있는지 판단하기 위해 다른 문서를 최대 10개까지만 조회할 수 있습니다. Fóir의 접근 규칙은 데이터베이스 안에서 실행되므로, 조회 횟수 제한 없이 한 사람을 조직과 권한 부여까지 따라갈 수 있습니다.