Blog cộng đồng về Công nghệ thông tin

Cơ chế và phân loại cache

Web thì đầu vào là URL và tham số, đầu ra là HTML. Chương trình chạy trên web server, quan sát dòng chảy dữ liệu từ đầu vào cho đến đầu ra:

Request -(1)-> [Controller/Action -(2)-> [[Model -(3)-> DB -(4)]-> View -(5)]] -> Response

ta thấy ở mỗi bước đều có thể nhảy cóc sang bước cách nó hoặc nhảy thẳng đến đầu ra nếu đã có kết quả lưu sẵn trong cache. Sơ đồ trên cho thấy có thể phân cache làm 5 loại:

• (1) Page: Nguyên cả trang HTML ứng với URL nhất định được lưu vào cache, các truy cập tiếp theo đến cùng URL này nhận được ngay kết quả từ web server. Chương trình không phải tính toán gì, thậm chí không biết là đã có request vì web server không báo.
• (2) Action: Chương trình biết là có request, nhưng trả về ngay kết quả mà không cần động vào Model hay View.
• (5) Fragment: Chỉ một phần HTML của trang được lưu.
• (4) Object: Object nào đó (có thể không phải là chuỗi kí tự HTML) được lưu.
• (3) SQL: Khi cùng câu lệnh SQL được gọi đi gọi lại, thì chỉ lệnh đầu tiên được gửi đến DB server. Tính năng này thường được thực hiện tự động bởi framework, khi viết chương trình không cần quan tâm.

Nói chung, nút cổ chai thường nằm ở kết nối đến DB server, cache làm sao để giảm thiểu truy vấn đến DB server càng nhiều càng tốt.

Yếu tố ảnh hưởng đến chọn loại cache

Có 2 yếu tố:

• Người dùng. Ví dụ người đã đăng nhập nhìn thấy kết quả HTML khác với người chưa đăng nhập. Ví dụ cùng URL nhưng trang web hiện tiếng Việt cho người đến từ Việt Nam, tiếng Mỹ cho người Mỹ.
• Thời gian. Ví dụ bài vừa được đăng sẽ hiện "Động đất ở Trung Quốc - Cập nhật vài phút trước", nhưng cũng bài nay sau vài ngày sẽ hiện "Động đất ở Trung Quốc - Cập nhật vài ngày trước".

Mẹo vặt

• Tiêu chí: Khi DB không có gì thay đổi, thì refresh trang web cũng không làm web server phải truy cập vào DB server.
• Page cache: Chỉ dùng được khi hiện như nhau cho tất cả người dùng, rất hiếm vì 99.9% các trang đều chứa nội dung động. Hệ quả: nên tắt luôn session để tốc độ xử lí nhanh thêm gấp rưỡi đến gấp đôi.
• Hầu như chỉ có thể dùng fragment và object cache (thường các framework đều tự động có sẵn tính năng SQL cache). Object cache dễ dùng hơn vì cùng thông tin nhưng có thể thoải mái hiện theo nhiều kiểu khác nhau.
• Khi viết chương trình, nhìn debug log hiện ở console để biết cần cache chỗ nào, có truy vấn nào đến DB server nữa không để sau khi thêm cache sẽ giảm thiểu được truy vấn đến DB server.
• Cache lưu theo key. Ứng với một cache key, nên chứa càng nhiều dữ liệu càng tốt, thay vì chỉ một record đơn lẻ, như vậy mới có tác dụng tăng tốc nhiều.
• Nên ghi chú (1) tên cache key, (2) những chỗ set và (3) những chỗ expire cache thành tài liệu để tránh sai sót và tiện bảo trì sau này.
• Nếu framework cung cấp sweeper (như Rails) thì quá tiện: (3) thay vì là controller, sẽ là sweeper. Tuy nhiên vì sweeper cũng chỉ là một loại callback, nên nếu framework không có tính năng sweeper, thì có thể để thủ công (3) ở after callback của model.
• (2) có thể để ở after_find/after_materialize của model.
• Cache ở cấp cao nhất có thể. Lần mò từ thấp lên cao (DB object -> fragment -> action -> page), nếu cache được ở cấp cao hơn thì cache ở đó. Nếu các khối HTML lồng nhau, thì cache khối càng ở ngoài càng tốt.
• Đặt tên key kèm tiền tố, ví dụ fragments/xxx/yyy.
• Cache lưu trong memory (memcached thì OK) thích hợp khi chạy trong chế độ development vì tự mất khi tắt web server, nhưng không thích hợp khi chạy trong chế độ production vì thường phải chạy nhiều process, mà các process sẽ chứa cache khác nhau khi một process nào đó expire.
• Object gì cũng lưu được trong memory. Nhưng để lưu được xuống tập tin hay vào DB, nó phải có thể serialize (dump, marshal) được thành chuỗi kí tự. Do đó nếu không cẩn thận thì chương trình chạy được trong chế độ developement nhưng lại lỗi khi chạy trong chế độ production.

Tham khảo

• Ruby on Rails Caching Tutorial part 1 part 2
• Plugin: acts_as_cached, cached_model, cache_fu
• Scaling Rails