측정 방법
이 사이트가 측정값으로 제시하는 수치는 운영 서버와 같은 프로세서의 베어메탈에서 측정했습니다. 잠자기, 깨우기, 스냅샷, 그리고 CPU 벤치마크입니다. 각 수치의 머신, 날짜, 측정 방법, 원시 데이터 위치를 아래에 밝힙니다.
- 베어메탈. 다른 사람의 머신 위에 있는 가상 머신이 아니라 물리 머신 한 대 전체이므로, 보이지 않는 무언가와 함께 쓰는 일이 없습니다.
- 중앙값과 분포. 여러 번 실행한 결과의 가운데 값이며, 95번째 백분위수와 실행 횟수를 옆에 함께 적습니다.
- 최선의 경우는 그렇다고 밝힙니다. 대부분 머신에서 다른 작업이 없는 상태로 실행했으며, 그런 경우 페이지에 밝힙니다.
- 원시 데이터 보존. 각 수치마다 읽어 온 파일을 밝히며, 그 파일은 수치를 만든 코드와 함께 저장소에 있습니다.
잠자기, 깨우기, 스냅샷
- 머신
- Cherry Servers, 싱가포르: AMD Ryzen 9 9950X(Zen 5, 16코어), 128 GB, Ubuntu 26.04.1, 커널 7.0.0-34
- 날짜
- 2026년 10월 3일
- 샌드박스
- 4 vCPU / 8 GiB 샌드박스, node:24-bookworm
- 노드
- 그날 기본 설정의 sandboxd: 패치한 Firecracker, 2계층 메모리, 잠든 샌드박스마다 대기시켜 둔 프로세스, PCI 장치
- 호출자
- 같은 머신에서 계속 열어 둔 연결 하나로 호출하므로, 수치는 핸드셰이크가 아닌 요청 자체의 시간입니다
| 항목 | 측정 방식 | 중앙값 | p95 | 횟수 | 출처 |
|---|---|---|---|---|---|
| 재우기 | 호출자가 측정한 POST …/sleep | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| 스스로 잠든 뒤 깨우기 | 다음 호출에서 노드가 직접 잰 복원 시간(Server-Timing 헤더) | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| 그 호출의 응답 | 깨운 요청 전체, 전송부터 응답까지 | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| 잠든 직후 깨우기 | 다음 깨우기를 위해 대기시켜 둔 프로세스가 아직 시작 중이라 기다립니다 | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| 실행 중인 샌드박스의 스냅샷 | API로, 실행 중에 메모리, 프로세스, 디스크를 | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| 풀에서 생성 | 이미 실행 중인 템플릿의 사본 | 1.3 ms | — | 100 | tti-sequential.txt create median |
| 생성부터 첫 명령의 응답까지 | 하나씩 차례로 100회 | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30개 동시에: 모두 잠들 때까지 | 샌드박스 30개를 동시에 재워 마지막 하나가 잠들 때까지 | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30개 동시에: 모두 깨어날 때까지 | 같은 30개를 동시에 깨워 마지막 하나가 깨어날 때까지 | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
파일은 sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/에 있고, 보고서는 sandboxd/bench/results/README.md의 2회차, 二절입니다. 사이트의 다른 페이지도 잠자기와 깨우기 수치(깨어나기 3.5 ms, 잠들기 2.3 ms)를 이 표와 같은 파일에서 읽으므로 모두 이번 회차의 수치입니다. 스냅샷은 Firecracker가 직접 기록한 전체 메모리와 페이지 단위로 대조했으며, 2,097,152개 페이지 중 한 페이지에서 3바이트가 달랐습니다.
직접 운영하는 샌드박스에서도 같은 수치를 확인할 수 있습니다. 샌드박스를 깨워야 했던 API 호출은 모두 Server-Timing: wake;dur=… 헤더에 걸린 시간을 밀리초 단위로 알려 줍니다.
CPU: StarSling의 공개 벤치마크
StarSling은 샌드박스 제공업체를 비교하는 공개 벤치마크를 발표합니다(github.com/starslingdev/hpc-sandbox-benchmarks). CPU 점수는 4 vCPU, 8 GiB 샌드박스에서 실행한 Node.js 웹 툴링 벤치마크의 초당 실행 횟수입니다. 저희는 이 테스트 모음을 Glac 샌드박스에서 실행하고, 저희가 보관한 데이터 사본에 있는 가장 최근 공개 실행의 제공업체들과 결과를 비교했습니다.
- Glac, 초당 실행 횟수
- 29.0
- 제공업체 13곳의 중앙값
- 17.26
- 그 중앙값보다 빠름
- 68%
저희 측정
- 영국 코번트리에 있는 첫 운영 서버(AMD Ryzen 9 9950X, 128 GB)에서 2026년 10월 10일 인수 테스트 중, 다른 샌드박스가 돌지 않는 상태로 측정했습니다.
- StarSling 자체의 테스트 모음과 이미지(
sandbox-benchmarks-toolchain:v8)를 4 vCPU, 8 GiB 샌드박스에서 제품이 실행하는 방식 그대로 실행했습니다. - 테스트 모음을 세 번 실행했고, 각 회차는 시도 세 번의 중앙값입니다: 28.97, 29.27, 29.00. 수치는 그 중앙값인 29.00입니다.
비교 대상
- StarSling의 실행 36498291449: 저희가 데이터 사본을 받은 2026년 10월 2일에 리더보드에 표시되던 실행이며, 그 사본에 있는 실행 아홉 번 중 가장 최근 것입니다(2026년 9월 23일~29일).
- 제공업체의 값은 샌드박스마다 구한 시도 중앙값을 다시 그 제공업체의 샌드박스 전체에 걸쳐 구한 중앙값으로, 리더보드 자체의 규칙입니다.
- 저희 사본은 각 값을 같은 실행에 있는 한 제공업체 값에 대한 비율로 소수점 셋째 자리까지 보관하므로, 아래 각 값은 StarSling의 원래 값과 약 0.02 이내로 일치합니다.
저희 값과 13개 값, 초당 실행 횟수, 높은 순
29.0 ÷ 17.26 = 1.68이므로 중앙값보다 68% 빠릅니다. 제공업체 이름은 StarSling이 공개한 데이터에 있으며, 여기 값은 빌드 시점에 reports/providers/sources/performance-bar/starsling-metrics.tsv에서 읽습니다. 이 파일은 옆에 있는 analyse.py가 그 데이터로 만든 것입니다.
이 결과가 말하지 않는 것
- 저희 측정은 머신에서 다른 작업이 없는 상태로 실행했고, 비교 대상은 그날 호스트에 걸린 부하 그대로 실행됐습니다. 바쁜 머신은 점수를 떨어뜨립니다. 코어마다 다른 바쁜 vCPU가 1.25개씩 있는 9950X에서는 같은 테스트 모음이 저희 샌드박스에서 10.4를 기록했습니다(2026년 10월 8일). 그때 이웃들은 같은 테스트를 반복 실행했는데, 캐시를 가장 많이 쓰는 부하로 실제 운영 환경보다 무겁습니다.
- 한 종류의 작업, 즉 Node.js로 JavaScript 도구를 실행하는 작업을 재는 벤치마크 하나이며, 코어 속도를 따라갑니다. 디스크나 네트워크에 대해서는 아무것도 알려 주지 않습니다.
파일
sandboxd/bench/results/2026-10-10-cvt-01-accept/: 인수 테스트와 그 원시 출력,results.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: 사본을 만들고 읽은 방법sandboxd/bench/results/README.md: 40절과 42절
원시 데이터 위치
이 페이지의 모든 경로는 측정에 쓴 코드와 함께 Glac 자체 저장소에 있는 파일입니다. 저장소는 공개되어 있지 않지만, 경로를 보면 각 수치가 어느 실행에서 나왔는지 알 수 있고, 각 회차의 보고서에는 무엇을 어떤 머신에서 실행했고 무엇이 잘못됐는지 적혀 있습니다.