Cách xử lý cookie trong ngăn xếp Varnish

Question

Do hiệu suất chậm của trang web, tôi bắt đầu tìm kiếm thông tin Varnish làm giải pháp lưu vào bộ nhớ cache và có một số câu hỏi về Google Analytics.

Khi có 5K người dùng hoạt động trên trang web (theo báo cáo lưu lượng truy cập trực tiếp của GA), máy chủ tải trên máy chủ phụ tăng vọt lên 30-40 +, hàng đợi của hành khách bắt đầu xếp chồng và trang web gần như không sử dụng được. Tôi biết về các truy vấn chậm và công việc cơ sở dữ liệu đòi hỏi phải có hiệu suất tốt hơn, nhưng tại thời điểm này tôi không có tài nguyên để tối ưu hóa các truy vấn và lược đồ db, chỉ mục, v.v.

Tôi tạo ra một sơ đồ để hiển thị tốt hơn chồng, đây là cách ngăn xếp hiện tại trông giống như: (trang web hiện lưu trữ hình ảnh/css/js trong CDN - Akamai)

Tôi muốn muốn thêm hai trường hợp véc ni ở phía trước của máy chủ phụ trợ để điều bộ nhớ cache và ngăn xếp sẽ trông như thế này:

trang web này là một trang web tin tức, và tôi đang tìm kiếm một lời khuyên, làm thế nào để chống đỡ erly xử lý các tập tin cookie và bộ nhớ đệm. Đối với giai đoạn 1, tôi muốn loại trừ hoàn toàn người dùng được xác thực hoàn toàn và phân phối nội dung động vì không có nhiều người dùng được xác thực đồng thời.

Sự nhầm lẫn là với cookie của Google Analytic. Sự hiểu biết của tôi là Google đặt cookie trên ứng dụng khách bằng javascript và ứng dụng khách giao tiếp trực tiếp với Google, vì vậy chương trình phụ trợ không cần cookie GA mà khách hàng gửi và an toàn để bỏ đặt chúng trong chương trình con vcl_recv.

sub vcl_recv { 

// Remove has_js and Google Analytics __* cookies. 
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", ""); 
// Remove a ";" prefix, if present. 
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); 
} 

Câu hỏi

• Đây có phải là một cách tiếp cận an toàn không?
• Google sẽ vẫn theo dõi đúng cách, bao gồm cả khách truy cập lặp lại?
• Có điều gì khác mà tôi cần xem trong chính sách của mình cho giai đoạn 1 không?

Vì véc ni theo mặc định sẽ KHÔNG cache bất kỳ thứ gì có bộ cookie, có an toàn để triển khai ngăn xếp được mô tả ở trên không bằng cách thêm chính sách xóa cookie GA? Tôi hiểu rằng nếu không tinh chỉnh chính sách VCL, tôi sẽ không đạt được tỷ lệ truy cập cao, tuy nhiên trong các thử nghiệm của tôi, có vẻ như ngay cả với véc-ni mặc định ở phía trước máy chủ phụ trợ, có tỷ lệ lần truy cập 30% và sau khi phân tích, tôi thấy hầu hết là tệp js/css và tệp hình ảnh, vì vậy rõ ràng một số tệp tĩnh không được Akamai hoặc thậm chí Apache phân phát, thay vào đó chúng được chuyển tới Hành khách/Đường ray để phân phát tệp tĩnh. Điều này chắc chắn cần phải được sửa chữa.

• Varnish sẽ cải thiện hiệu suất chỉ mặc định?

Tôi mới dùng véc ni để mọi chi tiết/tư vấn bổ sung về véc ni hoặc ngăn xếp mà tôi đề xuất được đánh giá cao.

Đối với giai đoạn 2 +

Kể từ khi nội dung được cập nhật, tôi đang lập kế hoạch để thực hiện các cuộc thanh trừng trên cả hai máy chủ véc ni, kích hoạt bởi các máy chủ backend khi một sự thay đổi áp dụng, chẳng hạn như một lời nhận xét của người dùng, lần xem trang, vv .

Có rất nhiều bài viết được lưu trữ không được cập nhật, có an toàn để lưu chúng vĩnh viễn không?

Vì tôi dự định sử dụng RAM để lưu trữ véc ni, nên tôi có thêm véc ni (thứ ba) và sử dụng đĩa để lưu trữ, cho các trang được lưu trữ một cách rõ ràng. Có lẽ thêm nginx stack ở phía trước của máy chủ véc ni để hướng lưu lượng truy cập đến một trường hợp véc ni cụ thể cho nội dung được lưu trữ? Cân bằng tải -> Cặp proxy ngược Nginx> Cặp Varnish -> (véc ni LB đến 8 máy chủ phụ trợ)

Tôi đánh giá cao bất kỳ lời khuyên nào về kiến ​​trúc. Nếu bạn cần thêm chi tiết để cung cấp lời khuyên tốt hơn, vui lòng cho tôi biết và tôi sẽ sẵn lòng cung cấp cho bạn thêm chi tiết.

Answer 1

Đó là rất nhiều câu hỏi! :-)

Q. Is this a safe approach? 

Trên bề mặt, tôi sẽ nói như vậy.

Nói chung, hãy thiết lập vécni trên trang web tin tức nơi lưu lượng truy cập nhanh và nội dung thay đổi nhanh có thể là một thách thức. Một cách thực sự tốt để kiểm tra là để xây dựng một hộp véc ni duy nhất và cung cấp cho nó truy cập trực tiếp đến cụm của bạn (không thông qua cân bằng tải), và cung cấp cho nó một địa chỉ IP công cộng tạm thời. Điều đó sẽ cho bạn cơ hội để kiểm tra các thay đổi của VCL. Bạn sẽ có thể kiểm tra bình luận, đăng nhập (nếu bạn có nó), và bất cứ điều gì khác để đảm bảo không có bất ngờ.

Q. Will Google still track properly, including repeat visitors? 

Có. Các cookie chỉ được sử dụng ở phía máy khách.

Một điều bạn nên xem là khi chương trình phụ trợ gửi cookie, Varnish cũng sẽ không lưu nội dung. Bạn sẽ cần xóa bất kỳ cookie nào không được yêu cầu trên vcl_fetch. Điều này có thể là một vấn đề nếu cookie được sử dụng để theo dõi trạng thái người dùng.

Q. Is there anything else that I need to watch for in my policies for phase1? 

Bạn sẽ cần tắt bộ nhớ cache trong Rails và đặt tiêu đề của riêng mình. Hãy lưu ý rằng bạn nên loại bỏ véc ni, Rails sẽ chạy không có bộ nhớ đệm và có thể sẽ sụp đổ!

Đây là những gì tôi có trong production.rb tôi:

# We do not use Rack::Cache but rely on Varnish instead 
    config.middleware.delete Rack::Cache 
    # varnish does not support etags or conditional gets 
    # to the backend (which is this app) so remove them too 
    config.middleware.delete Rack::ETag 
    config.middleware.delete Rack::ConditionalGet 

Và trong application_controller của tôi, tôi có phương pháp riêng tư này:

def set_public_cache_control(duration) 
    if current_user 
    response.headers["Cache-Control"] = "max-age=0, private, must-revalidate" 
    else 
    expires_in duration, :public => true 
    response.headers["Expires"] = CGI.rfc1123_date(Time.now + duration) 
    end 
end 

đó được gọi là trong các bộ điều khiển khác của tôi để tôi có kiểm soát rất chi tiết về mức độ chacheing được áp dụng cho các phần khác nhau của trang web. Tôi sử dụng một phương pháp thiết lập trong mỗi bộ điều khiển được chạy như một before_filter:

def setup 
    set_public_cache_control 10.minutes 
end 

(Các application_controller có bộ lọc và một phương pháp thiết lập trống, vì vậy nó có thể được tùy chọn trong các bộ điều khiển khác)

Nếu bạn có một phần của trang web không yêu cầu cookie, bạn có thể loại bỏ chúng dựa trên URL trong VCL và áp dụng tiêu đề.

Bạn có thể thiết lập thời gian bộ nhớ cache cho tài sản tĩnh của bạn trong cấu hình apache của bạn như thế này (giả sử bạn đang sử dụng con đường tài sản mặc định):

<LocationMatch "^/assets/.*$"> 
    Header unset ETag 
    FileETag None 
    # RFC says only cache for 1 year 
    ExpiresActive On 
    ExpiresDefault "access plus 1 year" 
    Header append Cache-Control "public" 
</LocationMatch> 

<LocationMatch "^/favicon\.(ico|png)$"> 
    Header unset ETag 
    FileETag None 
    ExpiresActive On 
    ExpiresDefault "access plus 1 day" 
    Header append Cache-Control "public" 
</LocationMatch> 

<LocationMatch "^/robots.txt$"> 
    Header unset ETag 
    FileETag None 
    ExpiresActive On 
    ExpiresDefault "access plus 1 hour" 
    Header append Cache-Control "public" 
</LocationMatch> 

Những tiêu đề sẽ được gửi đến CDN của bạn mà sẽ bộ nhớ cache tài sản lâu hơn nữa. Xem véc ni bạn vẫn sẽ thấy các yêu cầu đến với tốc độ giảm.

Tôi cũng sẽ đặt bộ nhớ đệm rất ngắn trên tất cả nội dung mà các trang không cần cookie nhưng thay đổi thường xuyên. Trong trường hợp của tôi, tôi đặt thời gian cache là 10 giây cho trang chủ. Điều này có nghĩa là Varnish là một yêu cầu người dùng sẽ đi đến phần phụ trợ sau mỗi 10 giây.

Bạn cũng nên xem xét đặt véc ni để sử dụng chế độ ưu tiên. Điều này cho phép nó phục vụ nội dung hơi cũ từ bộ nhớ cache trong tùy chọn để cho khách truy cập phản hồi chậm từ chương trình phụ trợ cho các mục vừa hết hạn.

Q. There are plenty of archived articles that don't get updated, is it safe to cache them forever? 

Để thực hiện việc này, bạn cần phải thay đổi ứng dụng để gửi các tiêu đề khác nhau cho những bài viết được lưu trữ. Điều này giả định rằng họ sẽ không có cookie. Dựa trên những gì tôi làm trên trang web của tôi, tôi sẽ làm điều đó theo cách này: -

Trong thiết lập ở trên thêm một điều kiện để thay đổi thời gian cache:

def setup 
    # check if it is old. This code could be anything 
    if news.last_updated_at < 1.months.ago 
    set_public_cache_control 1.year 
    else 
    set_public_cache_control 10.minutes 
    end 
end 

này thiết lập một tiêu đề công cộng, vì vậy Varnish sẽ cache nó (nếu không có cookie), và như vậy sẽ có bất kỳ cache từ xa nào (tại ISP hoặc gateway của công ty).

Vấn đề với điều này là nếu bạn muốn xóa câu chuyện hoặc cập nhật câu chuyện (vì lý do pháp lý).

Trong trường hợp đó, bạn nên gửi Varnish tiêu đề riêng tư để thay đổi TTL cho một URL đó, nhưng gửi tiêu đề công khai ngắn hơn cho mọi người khác.

Điều đó sẽ cho phép bạn đặt Varnish để phân phối nội dung trong (nói) 1 năm, trong khi nó gửi đi tiêu đề để yêu cầu khách hàng quay lại sau mỗi 10 phút.

Bạn sẽ cần thêm chế độ để lọc véc ni trong những trường hợp đó.

ĐẾN giúp bạn bắt đầu Tôi có một phương pháp thứ hai trong application_controller tôi:

def set_private_cache_control(duration=5.seconds) 
    # logged in users never have cached content so no TTL allowed 
    if ! current_user 
    # This header MUST be a string or the app will crash 
    if duration 
     response.headers["X-Varnish-TTL"] = duration.to_s 
    end 
    end 
end 

Và trong vcl_fetch của tôi, tôi có điều này:

call set_varnish_ttl_from_header; 

và chức năng vcl là thế này:

sub set_varnish_ttl_from_header { 
    if (beresp.http.X-Varnish-TTL) { 
    C{ 
     char *x_end = 0; 
     const char *x_hdr_val = VRT_GetHdr(sp, HDR_BERESP, "\016X-Varnish-TTL:"); /* "\016" is length of header plus colon in octal */ 
     if (x_hdr_val) { 
     long x_cache_ttl = strtol(x_hdr_val, &x_end, 0); 
     if (ERANGE != errno && x_end != x_hdr_val && x_cache_ttl >= 0 && x_cache_ttl < INT_MAX) { 
      VRT_l_beresp_ttl(sp, (x_cache_ttl * 1)); 
     } 
     } 
    }C 
    remove beresp.http.X-Varnish-TTL; 
    } 
} 

Đó là vì vậy tiêu đề KHÔNG được truyền qua (mà s-max-age không) cho bất kỳ bộ nhớ cache thượng lưu nào.

Phương pháp thiết lập sẽ trông như thế này:

def setup 
    # check if it is old. This code could be anything 
    if news.last_updated_at < 1.months.ago 
    set_public_cache_control 10.minutes 
    set_private_cache_control 1.year 
    else 
    set_public_cache_control 10.minutes 
    end 
end 

Hãy hỏi bất kỳ câu hỏi bổ sung, và tôi sẽ cập nhật câu trả lời này!