Code caching for JavaScript developers

V8 (Google) · 2019 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài lời khuyên cho người viết website, nhưng mô tả rõ thiết kế cache hai tầng của Chrome/V8. Wiki giữ phần thiết kế và các cách cache bị vô hiệu.

Bối cảnh

Parse + compile JavaScript chiếm phần đáng kể thời gian khởi động trang. Code cache lưu kết quả (bytecode) để lần sau bỏ qua bước đó.

Hai tầng cache:
- Isolate cache trong bộ nhớ của V8: hashtable khoá theo nội dung mã nguồn, chỉ trong một process (gần như "cùng site, cùng tab"). Rẻ, "best effort", theo V8 đạt khoảng 80% hit ngoài thực tế.
- Cache trên đĩa do Chrome (Blink) quản lý, gắn vào HTTP resource cache sẵn có, khoá theo URL script: lần tải đầu (cold) chỉ lưu file; lần hai (warm) compile rồi đính bytecode làm metadata của file trong cache; lần ba (hot) deserialize, bỏ qua compile.
Code cache chỉ serialize sau khi script chạy xong, để gồm cả hàm compile lười trong lúc chạy.
Hệ quả cho người viết web (theo V8): mỗi lần deploy code mới là cache nguội (200 thay vì 304); đổi URL, kể cả query string, là một entry mới; nhánh A/B ngẫu nhiên lúc chạy làm cache chỉ chứa một nhánh; cache theo cả script nên thư viện ổn định nằm chung file với logic hay đổi thì bị vô hiệu theo. Lời khuyên ngược nhau tuỳ trường hợp: tách thư viện ổn định ra file riêng, hoặc gộp thư viện với code dùng nó để cache "thấy" các hàm lười. Hàm trong IIFE bị compile sớm nên được cache.
V8 nhấn mạnh các heuristic này là chi tiết cài đặt và sẽ đổi (có thể chuyển sang khoá theo nội dung).

Gắn vào HTTP cache có sẵn giúp không phải tự lo hết hạn/xoá; cái giá là cache bị vô hiệu theo đúng những gì làm HTTP cache vô hiệu (URL, nội dung).

Khoá cache quyết định cái gì làm mất cache: khoá theo URL rẻ để tra nhưng mất khi đổi URL; khoá theo nội dung bền hơn nhưng phải đọc nội dung.
Đơn vị cache thô (cả script) làm thay đổi nhỏ vô hiệu phần lớn; tách phần ổn định khỏi phần hay đổi.
Tần suất deploy là một tham số của hit rate.