Varnish so với các proxy ngược khác

Tôi đang làm việc với một tổ chức đã triển khai Varnish như một proxy ngược lưu trữ cho tất cả lưu lượng truy cập web của họ. Lưu lượng truy cập của họ là rất nhiều trang web động do khách hàng tạo ra, với bộ sưu tập tài sản tĩnh thông thường treo bên cạnh.

Trong khi tôi đang cố gắng thích véc ni (về nguyên tắc, tôi nghĩ nó có kiến ​​trúc khá tốt), tôi gặp một số rắc rối khi quản lý và khắc phục sự cố khi chúng phát sinh, vì vậy tôi tự hỏi liệu đây có thực sự là lựa chọn đúng đắn hay không. Trước đây tôi đã sử dụng mực như một proxy ngược, nhưng không phải trong cùng một loại vai trò, vì vậy tôi không có cơ sở rõ ràng để so sánh.

Câu hỏi của tôi nhắm vào những người đã triển khai vecni trong sản xuất hoặc đánh giá nghiêm túc về các lựa chọn thay thế: bạn đã gắn bó với vecni hay cuối cùng bạn đã sử dụng một proxy ngược khác? Điểm quan trọng của bạn để duy trì với nó hoặc chuyển đổi là gì, và nếu bạn đã sử dụng một cái gì đó khác, cuối cùng bạn đã sử dụng cái gì?

Chà, tôi đang chạy Varnish trên máy chủ web của mình, chủ yếu vì lý do hiệu suất, mặc dù các kỳ tích cân bằng tải của nó cũng rất tiện dụng.

Trường hợp sử dụng của tôi là lưu trữ trước các trang web dựa trên Django và thật tuyệt vời cho hiệu suất tải trang. Tôi có thể phục vụ hầu hết các trang trực tiếp từ bộ nhớ cache và xử lý một lượng lớn khách truy cập với ít rắc rối.

Lý do tôi chọn Varnish chủ yếu là hiệu năng / khả năng mở rộng. Những ý chính:

• Varnish hãy để kernel quản lý bộ nhớ ảo, trong đó Squid cố gắng giữ bộ nhớ đệm và bộ nhớ riêng biệt, có thể dẫn đến kernel và Squid cãi nhau một chút về những gì sẽ được phân trang ra đĩa.
• Varnish sử dụng VCL, ngôn ngữ cấu hình dành riêng cho tên miền của nó, sẽ biên dịch thành mã máy thông qua C. Đó là một lợi ích hiệu suất rất thực nếu bạn có nhiều hơn một chút logic trong cấu hình của mình - tước tiêu đề có điều kiện, v.v.

Theo kinh nghiệm của tôi, Varnish hoạt động tốt hơn Squid một chút trong hầu hết các trường hợp và tốt hơn rất nhiều về lưu lượng truy cập. Mặt khác, việc định cấu hình Varnish một cách chính xác sẽ mất một số lần truy cập danh sách gửi thư, vì không có nhiều tài liệu tình huống sử dụng cụ thể sẵn sàng của bạn chảy trên mạng như có cho Squid - chủ yếu là do Varnish là một dự án khá trẻ so với.

Tôi đã mất một thời gian dài để cố gắng để Varnish 1.x ổn định trên phần cứng linux / dell tiêu chuẩn, nó sẽ luôn bị treo theo một cách kỳ lạ và cơ quan giám sát của nó sẽ khởi động lại nó. Điều đó là tốt, ngoại trừ bộ nhớ cache cứng đã không còn tồn tại ở bất cứ nơi nào khác ...

Phải nói rằng, bạn có thực sự sử dụng công cụ phù hợp cho công việc? Nếu bạn muốn một proxy ngược sẽ lưu trữ kết quả của yêu cầu (giả sử bạn đang cung cấp các tiêu đề bộ đệm chất lượng tốt) thì véc ni là một lựa chọn tốt. Hy vọng rằng nó đã ổn định hơn trong phiên bản 2.0

Tuy nhiên, nếu bạn đang chạy một trang web * onRails và bạn muốn cân bằng tải trên nhiều máy chủ phụ trợ thì HAProxy hoặc Nginx có thể là cách tốt nhất. Nếu bạn không cần bất kỳ logic url phức tạp nào (chuyển hướng, kết hợp regex để viết lại các url cũ hơn, v.v.) thì HAProxy sẽ phù hợp với hóa đơn. Nếu bạn cần một cái gì đó có khả năng hơn, thì hãy cho nginx đi.