
Haybarn-WASM 1.5.6-rc6은 확장 기능을 미리 내려받고 준비하는 prefetchExtensions()를 추가해, 여섯 확장 기능이 모두 로드될 때까지 걸리는 시간을 멀티스레드 빌드에서 6.8초에서 2.3초로 줄였다. Query.Farm은 AWS Graviton2에서 새 브라우저를 사용해 측정했으며, 이 기능은 현재 Haybarn-WASM에서만 쓸 수 있다.
Haybarn-WASM은 Query.Farm의 DuckDB-WASM 포크로, 브라우저 기반 데이터 질의·탐색 환경인 Cupola에 쓰인다. 개발자 루스티 코노버(Rusty Conover)는 이용자가 질의를 시작하기 전에 엔진과 확장 기능을 기다리는 시간을 줄이기 위해 시작 과정을 손봤다고 설명했다. JavaScript API는 DuckDB-WASM과 같아 패키지를 바꿔 사용할 수 있지만, 확장 기능을 미리 준비하려면 세션 설정 중 prefetchExtensions()를 한 번 호출해야 한다.
측정 결과와 변경 내용
Query.Farm의 측정은 AWS c6g.12xlarge에서 Headless Chromium 156을 16개 코어로 실행하고, 빌드별로 새 브라우저에서 다섯 차례씩 번갈아 진행한 결과다. 표의 시간은 중앙값이며, 실제 CDN에서 확장 기능을 받아 페이지 시작부터 모두 로드될 때까지를 쟀다.
- Haybarn-WASM 1.5.6-rc2에서 여섯 확장 기능을 로드하는 데 멀티스레드 빌드는 6.8초, 단일 스레드 빌드는 5.4초가 걸렸다. rc6에 미리 가져오기 기능을 적용하면 각각 2.3초와 2.0초로 줄었다.
- 다섯 확장 기능을 대상으로 한 비교에서 rc6의 미리 가져오기 적용 시간은 단일 스레드 1.9초, 멀티스레드 2.2초였다. 이 비교의 기준인 DuckDB-WASM 1.33.1-dev57.0에서는 멀티스레드 빌드의 확장 기능이 로드되지 않았다.
개선에는 여러 변경이 함께 반영됐다. 엔진 시작 때 모든 심볼을 훑던 emscripten의 연결 작업을 필요할 때 처리하도록 바꿨고, 확장 기능을 불러올 때 스레드를 반복해서 다시 시작하는 과정과 파일 복사도 줄였다. 여기에 prefetchExtensions()가 다운로드와 해시 계산, 모듈 컴파일을 LOAD 실행 전에 병렬로 진행한다. 서명 검증과 공개키 확인은 엔진에서 그대로 수행하며, 바이트가 검증을 통과한 뒤에만 모듈을 연결한다.
적용 조건과 한계
prefetchExtensions()는 세션을 설정할 때 한 번 호출해야 한다. 미리 가져오는 동안 보낸 요청은 작업이 끝날 때까지 기다리므로 세션 중간에 쓰는 기능은 아니다. 확장 기능의 출처를 정하는 INSTALL … FROM community와 custom_extension_repository 설정을 먼저 해야 하며, iceberg처럼 다른 확장 기능을 불러오는 경우에는 avro와 parquet도 목록에 넣어야 한다. 다운로드가 실패하거나 30초 넘게 걸리면 LOAD가 기존 방식으로 파일을 다시 내려받는다. 이미 로드된 확장 기능은 건너뛰며, 미리 받은 파일 하나는 LOAD 한 번에 쓰인다. Node.js에서는 LOAD가 이미 디스크 캐시를 읽으므로 이 기능이 작동하지 않는다.
이 변경은 현재 Haybarn-WASM에만 적용된다. 코노버는 emscripten과 duckdb-wasm에 관련 수정 사항을 제안했지만, 원문 게시 시점에는 검토 중이라고 밝혔다. prefetchExtensions()는 Haybarn의 확장 기능 서명 검사 방식에 의존한다. 또한 멀티스레드 빌드는 DuckDB-WASM과 마찬가지로 교차 출처 격리 설정이 필요하다. Haybarn-WASM 1.5.6-rc6은 엔진 1.5.6을 사용하고, DuckDB-WASM 1.33.1-dev57.0은 DuckDB 1.5.4를 사용한다. Haybarn-WASM 릴리스는 아직 릴리스 후보 단계다.
측정 조건과 전환 시 참고 사항은 원문에서 확인할 수 있다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요