Tôi có một hệ thống đang chạy nginx / php-fpm / var Vec / wordpress và amazon s3.

Bây giờ tôi đã xem xét rất nhiều tệp cấu hình trong khi thiết lập hệ thống, và trong tất cả chúng tôi đã tìm thấy một cái gì đó như thế này:

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

Tôi không hiểu tại sao điều này được thực hiện. Hầu hết các ví dụ cũng chạy NginX như một máy chủ web. Bây giờ câu hỏi là, tại sao bạn sẽ sử dụng bộ đệm vecni để lưu trữ các tệp tĩnh này.

Nó có ý nghĩa hơn đối với tôi khi chỉ lưu trữ các tệp động để php-fpm / mysql không bị ảnh hưởng nhiều.

Tôi đúng hay tôi thiếu một cái gì đó ở đây?

CẬP NHẬT

Tôi muốn thêm một số thông tin cho câu hỏi dựa trên câu trả lời được đưa ra.

Nếu bạn có một trang web động, nơi nội dung thực sự thay đổi nhiều, việc chaching không có ý nghĩa gì. Nhưng nếu bạn sử dụng WordPress cho một trang web tĩnh chẳng hạn, điều này có thể được lưu trong bộ nhớ cache trong thời gian dài.

Điều đó nói rằng, quan trọng hơn với tôi là conent tĩnh . Tôi đã tìm thấy một liên kết với một số thử nghiệm và điểm chuẩn trên các ứng dụng bộ đệm và ứng dụng máy chủ web khác nhau.

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

NginX thực sự nhanh hơn trong việc nhận nội dung tĩnh của bạn, vì vậy sẽ có ý nghĩa hơn khi chỉ để nó đi qua. NginX hoạt động tuyệt vời với các tệp tĩnh.

-

Ngoài ra, phần lớn thời gian nội dung tĩnh thậm chí không nằm trong chính máy chủ web. Hầu hết thời gian nội dung này được lưu trữ trên CDN ở đâu đó, có thể là AWS S3, đại loại như thế. Tôi nghĩ rằng bộ đệm vecni là nơi cuối cùng mà bạn muốn lưu trữ nội dung tĩnh.

Có một vài lợi thế cho Varnish. Điều đầu tiên bạn lưu ý là giảm tải trên máy chủ phụ trợ. Thông thường bằng cách lưu trữ nội dung được tạo động nhưng hiếm khi thay đổi (so với tần suất truy cập). Lấy ví dụ về Wordpress của bạn, hầu hết các trang có lẽ không thay đổi thường xuyên và có một số plugin tồn tại để vô hiệu hóa bộ đệm vecni khi trang thay đổi (ví dụ: bài đăng mới, chỉnh sửa, nhận xét, v.v.). Do đó, bạn lưu trữ bộ nhớ cache vô thời hạn và không hợp lệ khi thay đổi - dẫn đến tải tối thiểu cho máy chủ phụ trợ của bạn.

Bài viết được liên kết không chịu được, hầu hết mọi người sẽ đề xuất rằng Varnish hoạt động tốt hơn Nginx nếu được thiết lập đúng - mặc dù, (và tôi thực sự ghét phải thừa nhận) - các thử nghiệm của riêng tôi dường như đồng ý rằng nginx có thể phục vụ tệp tĩnh nhanh hơn véc ni ( may mắn thay, tôi không sử dụng vecni cho mục đích đó). Tôi nghĩ rằng vấn đề là nếu bạn kết thúc sử dụng Varnish, bạn đã thêm một lớp bổ sung vào thiết lập của mình. Chuyển qua lớp bổ sung đó đến máy chủ phụ trợ sẽ luôn chậm hơn so với việc chỉ phục vụ trực tiếp từ phụ trợ - và đây là lý do tại sao cho phép Varnish lưu vào bộ đệm có thể nhanh hơn - bạn lưu một bước. Ưu điểm khác là ở mặt trước đĩa-io. Nếu bạn thiết lập véc ni để sử dụng malloc, bạn hoàn toàn không nhấn vào đĩa, điều này khiến nó có sẵn cho các quy trình khác (và thường sẽ tăng tốc mọi thứ).

Tôi nghĩ rằng người ta sẽ cần một điểm chuẩn tốt hơn để thực sự đánh giá hiệu suất. Liên tục yêu cầu cùng một tệp, kích hoạt bộ đệm hệ thống tệp bắt đầu chuyển trọng tâm ra khỏi máy chủ web. Một điểm chuẩn tốt hơn sẽ sử dụng bao vây với một vài nghìn tệp tĩnh ngẫu nhiên (thậm chí có thể từ nhật ký máy chủ của bạn) để mô phỏng lưu lượng thực tế. Mặc dù có thể cho rằng, như bạn đã đề cập, việc giảm tải nội dung tĩnh sang CDN ngày càng trở nên phổ biến, điều đó có nghĩa là Varnish có thể sẽ không phục vụ nó để bắt đầu (bạn đề cập đến S3).

Trong kịch bản trong thế giới thực, bạn có thể sẽ ưu tiên sử dụng bộ nhớ của mình - trước tiên là nội dung động, vì nó đắt nhất để tạo ra; sau đó là nội dung tĩnh nhỏ (ví dụ js / css) và hình ảnh cuối cùng - bạn có thể sẽ không lưu trữ phương tiện khác trong bộ nhớ, trừ khi bạn có lý do thực sự tốt để làm như vậy. Trong trường hợp này, với việc tải các tệp Varnish từ bộ nhớ và nginx tải chúng từ đĩa, Varnish có thể sẽ thực hiện nginx (lưu ý rằng bộ nhớ cache của nginx chỉ dành cho proxy và fastCGI, và theo mặc định là dựa trên đĩa - có thể sử dụng nginx với memcached).

(Nhanh chóng của tôi - rất thô sơ, không được tin cậy - thử nghiệm cho thấy nginx (trực tiếp) là nhanh nhất - hãy gọi nó là 100%, vecni (với malloc) chậm hơn một chút (khoảng 150%) và nginx sau vecni ( với pass) là chậm nhất (khoảng 250%). Điều đó nói lên điều đó - tất cả hoặc không có gì - thêm thời gian (và xử lý) để giao tiếp với phụ trợ, chỉ cần gợi ý rằng nếu bạn đang sử dụng Varnish và có RAM dự phòng , bạn cũng có thể chỉ lưu trữ mọi thứ bạn có thể và phục vụ nó từ Varnish thay vì quay lại nginx.)

Tôi nghĩ rằng bạn có thể đang thiếu một cái gì đó.

Theo định nghĩa, các tệp động thay đổi. Thông thường, họ thay đổi bằng cách thực hiện một số loại truy vấn cơ sở dữ liệu ảnh hưởng đến nội dung của trang được phục vụ cho người dùng. Do đó, bạn không muốn lưu trữ nội dung động. Nếu bạn làm như vậy, nó chỉ đơn giản trở thành nội dung tĩnh và rất có thể là nội dung tĩnh với nội dung không chính xác.

Ví dụ đơn giản, giả sử bạn có một trang với tên người dùng đã đăng nhập ở đầu trang. Mỗi khi trang đó được tải, một truy vấn cơ sở dữ liệu sẽ được chạy để xác định tên người dùng nào thuộc về người dùng đã đăng nhập yêu cầu trang đảm bảo rằng tên thích hợp được hiển thị. Nếu bạn đã lưu trữ trang này, thì truy vấn cơ sở dữ liệu sẽ không xảy ra và tất cả người dùng sẽ thấy cùng tên người dùng ở đầu trang và có thể đó sẽ không phải là tên người dùng của họ. Bạn cần truy vấn đó xảy ra trên mỗi lần tải trang để đảm bảo tên người dùng phù hợp được hiển thị cho mỗi người dùng. Do đó, nó không được lưu trữ.

Mở rộng logic đó sang một cái gì đó có vấn đề hơn một chút như quyền của người dùng và bạn có thể thấy tại sao nội dung động không nên được lưu trữ. Nếu cơ sở dữ liệu không được đánh cho nội dung động, CMS không có cách nào để xác định xem người dùng yêu cầu trang có quyền xem trang đó hay không.

Theo định nghĩa, nội dung tĩnh là giống nhau cho tất cả người dùng. Do đó, không có truy vấn cơ sở dữ liệu nào cần phải diễn ra để tùy chỉnh trang đó cho mỗi người dùng, do đó, có ý nghĩa với bộ đệm để loại bỏ các truy vấn cơ sở dữ liệu không cần thiết. Hình ảnh là một ví dụ thực sự tuyệt vời về nội dung tĩnh - bạn muốn tất cả người dùng nhìn thấy cùng một hình ảnh tiêu đề, cùng các nút đăng nhập, v.v., vì vậy họ là những ứng cử viên tuyệt vời cho bộ nhớ đệm.

Trong đoạn mã của bạn ở trên, bạn đang thấy một đoạn mã VCL Varnish rất điển hình buộc các hình ảnh, css và javascript được lưu vào bộ nhớ cache. Theo mặc định, Varnish sẽ không lưu trữ bất kỳ yêu cầu nào với cookie trong đó. Logic là nếu có một cookie trong yêu cầu, thì phải có một số lý do máy chủ cần cookie đó vì vậy nó được yêu cầu ở mặt sau và phải được chuyển qua bộ đệm. Trong thực tế, nhiều CMS (Drupal, Wordpress, v.v.) đính kèm cookie vào hầu hết mọi thứ dù có cần thiết hay không, vì vậy người ta thường viết VCL để loại bỏ cookie khỏi nội dung được biết là tĩnh, từ đó khiến Varnish lưu vào bộ đệm nó

Có lý?

Đối với nội dung động , một số loại như báo giá chứng khoán thực sự thay đổi thường xuyên (được cập nhật mỗi giây SaaS servertừ một backend server) nhưng có thể được truy vấn thậm chí thường xuyên hơn (bởi hàng chục ngàn subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

Trong trường hợp này, bộ nhớ đệm trên SaaS serverbản cập nhật mỗi giây từ backend serversđó có thể đáp ứng các truy vấn của hàng chục ngàn subscription users.

Không có bộ đệm trên máy chủ SaaS thì mô hình này sẽ không hoạt động.

Lưu các tệp tĩnh với Varnish sẽ có lợi về mặt giảm tải Nginx. Tất nhiên, nếu bạn có nhiều tệp tĩnh để lưu vào bộ đệm, nó sẽ lãng phí RAM. Tuy nhiên, Varnish có một tính năng hay - nó hỗ trợ nhiều phụ trợ lưu trữ cho bộ đệm của nó.

Đối với các tệp tĩnh: bộ nhớ cache vào ổ cứng Đối với mọi thứ khác: bộ nhớ cache vào RAM.

Điều này sẽ cung cấp cho bạn cái nhìn sâu sắc hơn về cách triển khai kịch bản này: http://www.getpagespeed.com/server-setup/varnish-static-files-cache