1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
# 040 — 한 문서 앱의 다중 객체·동시 요청 용량 확인
2026-09-24. 작은 코어와 한 문서 예제만으로 서비스 규모의 메모리 특성을
판단할 수 없다. 기존 `editor.pure`를 그대로 사용하고, 소스 정의 HTTP 호스트와
빌드 시 준비한 고정 정의 HTTP 호스트에 동일한 앱 작업을 실행했다. 새 런타임
타입이나 전용 저장 형식을 추가하지 않았다.
[재현 검사](../../prototypes/connections/check_service_scale.py)는 각 호스트에
**8개 클라이언트**를 연결해 **1,024개 키**를 분담한다. 키마다 8,192 B 문서를
생성하고, 읽고, 마지막 1 B를 조건부 수정하고, 새 버전을 다시 읽는다.
각 응답의 상태·버전·본문을 검증하고, 두 호스트가 만든 모든 최종 문서의
해시를 비교한다. 호스트 종료 후에는 별도 CLI 프로세스로 네 문서를 읽어
저장된 내용과 버전을 확인한다. 한 호스트당 **4,096 HTTP 작업**과 2,048개 저장 효과,
2,048개 읽기 효과다. 키별 작업은 순차적이며, 서로 다른 키 사이에 동시성이
있다. 이전 검사에서 같은 키의 충돌과 느린 수신자는 별도로 검증했다.
[현재 호스트의 실행 결과](../../prototypes/connections/results/2026-09-24-posix-idle/service-scale.json):
| 한 호스트 기준 | 고정 정의 | 소스 정의 |
|---|---:|---:|
| 최종 저장 객체 | 1,024 | 1,024 |
| 저장 파일 총량 | 8,413,184 B | 8,413,184 B |
| 서버 유휴 RSS | 1,504 KiB | 1,552 KiB |
| 이 작업의 피크 RSS | **1,680 KiB** | **1,712 KiB** |
| 최대 동시 연결 | 8 | 8 |
| 최대 보유 payload | 49,185 B | 49,168 B |
| 종료 시 보유 payload | 0 B | 0 B |
| 거절·기한 만료 | 0 | 0 |
두 호스트의 최종 문서 해시는 같다. 1 MiB 서버 payload 예산과 4 MiB
프로세스 피크 RSS 회귀 상한을 통과했다. 응답으로 빌려 보낸 논리적 본문은
호스트당 25,166,848 B였고, 요청 헤더와 같은 첫 수신에 실린 본문을 입력
버퍼로 옮긴 바이트는 이 실행에서 고정 정의 326,623 B, 소스 정의
366,236 B였다. [앞선 동일 작업](../../prototypes/connections/results/2026-09-24-signal-safe-idle/service-scale-restored.json)에서는
각각 696,751 B와 410,074 B였다.
TCP 분할·스케줄링에 따라 달라지는 값이므로 두 호스트의 우열을 뜻하지
않지만, 복사 제거가 아직 완전하지 않다는 근거다. 빌린 출력 바이트는 실제
네트워크·커널 복사량이나 고유 물리 메모리량을 뜻하지 않는다.
이 검사는 **실제 문서 앱의 다중 객체·8연결 정확성 및 자원 상한**을 보여준다.
Python 클라이언트가 만든 요청의 실행 시간을 서버 처리량으로 취급하지
않는다. 저장 파일과 페이지 캐시, 파일 디스크립터, OS 네트워크 버퍼,
클라이언트 메모리는 서버 RSS에 포함되지 않는다. 1,024개 파일을 쓰는
운영·복구 비용, 다수의 1 MiB 동시 응답, 장시간 부하, 여러 Pure 프로세스,
실서비스 동등 비교와 macOS는 아직 검증하지 않았다. 한 바이트 수정에도
기본 저장소가 문서 전체를 다시 쓰는 비용 역시 남아 있다.
재현 명령은 `make -C prototypes/connections check-service-scale`이다.
|
