Nhật ký công việc cho nhiệm vụ "Cấu hình bộ nhớ đệm Varnish"
Đã thiết lập bộ nhớ đệm tài nguyên tĩnh thông qua Varnish
Đối với trang web gorodskie-bani.ru, việc định tuyến proxy các tài nguyên tĩnh thông qua Varnish đã được thiết lập với thời gian sống (TTL) là 7 ngày. Các tệp JS, CSS, phông chữ, hình ảnh, biểu tượng và tài nguyên /styles/ từ tileserver đều đi qua bộ nhớ đệm. Các trang động được chủ động không đưa vào bộ nhớ đệm và tiếp tục được xử lý trực tiếp bởi ứng dụng (return (pass)).
Tại sao điều này là cần thiết
Nhiệm vụ chính của việc lưu vào bộ nhớ đệm là phục vụ các tài nguyên không thay đổi hoặc ít thay đổi trực tiếp từ bộ nhớ/bộ nhớ đệm của Varnish thay vì từ ứng dụng Node.js và tileserver trong mỗi yêu cầu.
Điều này mang lại cho trang web một số lợi ích thiết thực:
- Giảm thời gian phản hồi tĩnh. Sau yêu cầu đầu tiên, tài nguyên được đưa vào bộ nhớ đệm, các yêu cầu tiếp theo được Varnish phục vụ mà không cần gọi đến backend.
- Giảm tải cho ứng dụng và tileserver. Các tệp JS, CSS, hình ảnh, phông chữ và kiểu bản đồ không tạo ra tải lặp lại trên các container backend.
- Tăng độ ổn định dưới tải cao. Khi người dùng truy cập đồng thời, phần lớn các yêu cầu tĩnh được phục vụ ở cấp độ proxy lưu trữ đệm.
- Tăng tốc độ tải trang cho người dùng. Việc phản hồi nhanh chóng các tệp CSS, JS, phông chữ và hình ảnh giúp giảm thời gian chờ đợi các tài nguyên cần thiết để hiển thị trang.
- Tạo ra hiệu ứng kỹ thuật tích cực cho SEO. Tốc độ tải và các chỉ số hiệu suất của người dùng, bao gồm cả những chỉ số liên quan đến Core Web Vitals, là một phần chất lượng kỹ thuật của trang web. Varnish không trực tiếp thay đổi thứ hạng tìm kiếm, nhưng nó giúp giảm độ trễ mạng và tải cho origin, từ đó tạo ra các điều kiện ổn định hơn để tải nhanh và cho phép bot tìm kiếm thu thập dữ liệu trang web.
Cấu hình Varnish
Hai backend đã được cấu hình:
- backend ứng dụng chính —
gorodskie-bani--agent-app-1:3000; - backend tileserver riêng biệt —
gorodskie-bani-ru-tileserver-1:80.
vcl 4.1;
backend default {
.host = "gorodskie-bani--agent-app-1";
.port = "3000";
}
backend tileserver {
.host = "gorodskie-bani-ru-tileserver-1";
.port = "80";
}
Trong vcl_recv, các yêu cầu tới /styles/ được gửi đến tileserver. Đối với các tài nguyên được lưu vào bộ nhớ đệm, Cookie bị xóa để cookie của người dùng không làm phân mảnh bộ nhớ đệm hoặc cản trở việc tái sử dụng một đối tượng duy nhất bởi các yêu cầu khác nhau.
sub vcl_recv {
if (req.url ~ "^/styles/") {
set req.backend_hint = tileserver;
unset req.http.Cookie;
return (hash);
}
if (req.url ~ "\.(js|css|woff2?|ttf|eot|svg|ico|png|jpg|jpeg|gif|webp|avif)(\?.*)?$") {
unset req.http.Cookie;
return (hash);
}
return (pass);
}
Tất cả các yêu cầu khác đi qua pass, nghĩa là các phản hồi HTML và động của ứng dụng không được lưu vào bộ nhớ đệm theo quy tắc này. Điều này làm giảm nguy cơ trả về nội dung cá nhân hóa hoặc nội dung động cũ.
Khóa bộ nhớ đệm được xây dựng dựa trên URL và host:
sub vcl_hash {
hash_data(req.url);
hash_data(req.http.host);
return (lookup);
}
Điều này cho phép lưu trữ riêng biệt các tài nguyên của các URL khác nhau và không trộn lẫn bộ nhớ đệm giữa các host. Chuỗi truy vấn (Query string) vẫn là một phần của req.url, do đó các phiên bản tài sản có tham số chống lưu đệm (cache-busting) nhận được các bản ghi bộ nhớ đệm riêng biệt.
Đối với /styles/ và các tệp tĩnh, TTL được đặt thành 7 ngày, và Set-Cookie bị xóa khỏi phản hồi backend được lưu vào bộ nhớ đệm:
sub vcl_backend_response {
if (bereq.url ~ "^/styles/") {
set beresp.ttl = 7d;
unset beresp.http.Set-Cookie;
}
if (bereq.url ~ "\.(js|css|woff2?|ttf|eot|svg|ico|png|jpg|jpeg|gif|webp|avif)(\?.*)?$") {
set beresp.ttl = 7d;
unset beresp.http.Set-Cookie;
}
}
TTL 7 ngày cho phép phục vụ các yêu cầu lặp lại từ Varnish trong thời gian dài, trong khi phương pháp tiêu chuẩn với tên tệp có phiên bản hoặc tham số truy vấn cho phép nhận phiên bản tài nguyên mới sau khi triển khai mà không cần đợi bộ nhớ đệm cũ hết hạn.
Để chẩn đoán, các tiêu đề dịch vụ X-Cache và X-Cache-TTL đã được thêm vào:
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
} else {
set resp.http.X-Cache = "MISS";
}
set resp.http.X-Cache-TTL = obj.ttl;
}
Dựa vào các tiêu đề này, bạn có thể nhanh chóng kiểm tra hoạt động thực tế của bộ nhớ đệm: yêu cầu đầu tiên thường được trả về là MISS, các yêu cầu tiếp theo là HIT, và X-Cache-TTL hiển thị thời gian sống còn lại của đối tượng.
Định tuyến Traefik
Để đảm bảo các yêu cầu mong muốn thực sự đi vào Varnish, các bộ định tuyến riêng biệt có độ ưu tiên cao đã được thêm vào Traefik.
Tệp tĩnh:
gorodskie-bani.ru-static:
rule: 'Host(`gorodskie-bani.ru`) && PathRegexp(`^.*\.(js|css|woff2?|ttf|eot|svg|ico|png|jpg|jpeg|gif|webp|avif)$`)'
entryPoints:
- websec
service: gorodskie-bani.ru-varnish
tls:
certResolver: letsencrypt
priority: 200
Tài nguyên /styles:
gorodskie-bani.ru-styles:
rule: "Host(`gorodskie-bani.ru`) && PathPrefix(`/styles`)"
entryPoints:
- websec
middlewares: []
service: gorodskie-bani.ru-varnish
tls:
certResolver: letsencrypt
priority: 200
Bằng cách này, Traefik tách biệt các yêu cầu được lưu vào bộ nhớ đệm ở đầu vào và truyền chúng đến dịch vụ Varnish, sau đó Varnish sẽ trả về đối tượng từ bộ nhớ đệm hoặc lấy nó từ backend tương ứng và lưu trữ trong 7 ngày.
Kết quả cho trang web và SEO
Kết quả là phần tĩnh của gorodskie-bani.ru được phục vụ thông qua một lớp bộ nhớ đệm riêng biệt. Điều này làm giảm số lượng yêu cầu gửi đến ứng dụng và tileserver, tăng tốc độ tải lại tài nguyên và làm cho thời gian phản hồi ổn định hơn khi lưu lượng truy cập tăng lên.
Đối với SEO, điều này hữu ích trước hết như một sự tối ưu hóa hiệu suất cơ sở hạ tầng: trình duyệt nhận các tệp CSS/JS/phông chữ/hình ảnh quan trọng nhanh hơn, backend cạnh tranh ít tài nguyên hơn với các yêu cầu tĩnh, và trang web duy trì tốc độ phản hồi bình thường ổn định hơn dưới tải. Nhìn chung, điều này hỗ trợ chất lượng kỹ thuật của trang web và trải nghiệm người dùng, những yếu tố quan trọng đối với khả năng hiển thị trên công cụ tìm kiếm và hiệu quả của lưu lượng truy cập tự nhiên.