Làm cách nào để chọn MPM Apache nào sẽ sử dụng?

Đây là một Câu hỏi Canonical về việc chọn đúng MPM Apache httpd.

Tôi hơi bối rối giữa các MPM khác nhau được cung cấp bởi Apache - 'worker', 'event', 'prefork', v.v.

Sự khác biệt chính giữa chúng là gì và làm thế nào tôi có thể quyết định cái nào sẽ tốt nhất cho một triển khai nhất định?

Có một số module MPM (Multi-Processing Modules), nhưng đến nay là sử dụng rộng rãi nhất (ít nhất là trên nền tảng * nix) là ba cái chính: prefork, worker, và event. Về cơ bản, chúng đại diện cho sự phát triển của máy chủ web Apache và các cách khác nhau mà máy chủ đã được xây dựng để xử lý các yêu cầu HTTP trong giới hạn tính toán của thời gian trong lịch sử lâu dài (về mặt phần mềm).

prefork

mpm_preforklà .. tốt .. nó tương thích với mọi thứ. Nó tạo ra một số quy trình con để phục vụ các yêu cầu và các quy trình con chỉ phục vụ một yêu cầu tại một thời điểm. Bởi vì nó đã xử lý máy chủ ở đó, sẵn sàng hành động và không cần phải xử lý việc xử lý luồng, nó thực sự nhanh hơn các MPM luồng hiện đại hơn khi bạn chỉ xử lý một yêu cầu tại một thời điểm - nhưng các yêu cầu đồng thời bị ảnh hưởng, vì chúng được tạo ra để chờ xếp hàng cho đến khi một quy trình máy chủ được miễn phí. Ngoài ra, khi cố gắng tăng quy mô số lượng quy trình con prefork, bạn sẽ dễ dàng giảm một số RAM nghiêm trọng.

Có lẽ không nên sử dụng prefork trừ khi bạn cần một mô-đun không an toàn cho chuỗi.

Sử dụng nếu: Bạn cần các mô-đun phá vỡ khi các chủ đề được sử dụng, như mod_php. Ngay cả sau đó, hãy xem xét sử dụng FastCGI và php-fpm.

Không sử dụng nếu: Mô-đun của bạn sẽ không ngắt trong luồng.

worker

mpm_workersử dụng phân luồng - đó là một trợ giúp lớn cho đồng thời. Công nhân quay vòng một số quy trình con, từ đó quay ra các luồng con; tương tự như prefork, một số luồng dự phòng được giữ sẵn sàng nếu có thể, để phục vụ các kết nối đến. Cách tiếp cận này tốt hơn nhiều về RAM, vì số lượng luồng không có liên quan trực tiếp đến việc sử dụng bộ nhớ giống như số lượng máy chủ thực hiện trong prefork. Nó cũng xử lý đồng thời dễ dàng hơn nhiều, vì các kết nối chỉ cần đợi một luồng miễn phí (thường có sẵn) thay vì một máy chủ dự phòng trong prefork.

Sử dụng nếu: Bạn đang dùng Apache 2.2 hoặc 2.4 và bạn đang chạy SSL chủ yếu.

Đừng sử dụng nếu: Bạn thực sự không thể sai, trừ khi bạn cần prefork để tương thích.

Tuy nhiên, lưu ý rằng các rãnh được gắn vào các kết nối và không yêu cầu - điều đó có nghĩa là kết nối duy trì luôn giữ một luồng cho đến khi nó đóng (có thể là một thời gian dài, tùy thuộc vào cấu hình của bạn). Đó là lý do tại sao chúng ta có ..

event

mpm_eventrất giống với công nhân, có cấu trúc; nó vừa được chuyển từ trạng thái 'thử nghiệm' sang 'ổn định' trong Apache 2.4. Sự khác biệt lớn là nó sử dụng một luồng chuyên dụng để xử lý các kết nối còn tồn tại và chỉ yêu cầu xử lý các luồng con khi yêu cầu thực sự được thực hiện (cho phép các luồng đó tự do sao lưu ngay sau khi yêu cầu được hoàn thành). Điều này rất tốt cho sự tương tranh của các khách hàng không nhất thiết phải hoạt động cùng một lúc, nhưng thực hiện các yêu cầu không thường xuyên và khi khách hàng có thể có thời gian chờ lâu.

Ngoại lệ ở đây là với các kết nối SSL; trong trường hợp đó, nó hoạt động giống hệt với worker (dán một kết nối đã cho vào một luồng nhất định cho đến khi kết nối đóng lại).

Sử dụng nếu: Bạn đang sử dụng Apache 2.4 và thích các luồng, nhưng bạn không muốn có các luồng chờ kết nối nhàn rỗi. Mọi người đều thích chủ đề!

Không sử dụng nếu: Bạn không có trên Apache 2.4 hoặc bạn cần prefork để tương thích.

Trong thế giới ngày nay của Slowloris , AJAX và các trình duyệt muốn ghép 6 kết nối TCP (tất nhiên vẫn còn tồn tại) với máy chủ của bạn, đồng thời là một yếu tố quan trọng giúp quy mô và quy mô máy chủ của bạn hoạt động tốt. Lịch sử của Apache đã ràng buộc nó về vấn đề này và mặc dù nó thực sự vẫn không ngang tầm với nginx hay lighttpd về việc sử dụng tài nguyên hoặc quy mô, rõ ràng nhóm phát triển đang làm việc để xây dựng một máy chủ web vẫn còn phù hợp trong thế giới đồng thời yêu cầu cao.

Đây là một lời giải thích tốt về cách nó hoạt động với gifs:

https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/

Tóm lại: nếu bạn trên 2.4 và bạn cần httpd làm proxy ngược (bộ điều phối) để lựa chọn của bạn là MPM sự kiện

Kể từ tháng 2 năm 2018, tài liệu Apache 2.4 cho MPM sự kiện tuyên bố rằng việc sử dụng Apache làm proxy sẽ giữ cho "xử lý kết nối được cải thiện" kể từ 2.4.24 không hoạt động như thiết kế. Xem phần Hạn chế .

Vấn đề là, như một proxy, công nhân không thể biết được kết thúc của phản hồi ở đâu và sẽ bị buộc phải đợi cho đến khi toàn bộ phản hồi được nhìn thấy trước khi trả lại quyền kiểm soát cho người nghe.

Vì lý do này, có vẻ như việc sử dụng mô hình Công nhân có thể là tốt nhất khi apache được sử dụng làm proxy. Nó không thực sự rõ ràng với tôi nếu có những lợi thế cho mô hình sự kiện trong môi trường proxy, nhưng có lẽ có.

Chủ yếu phụ thuộc vào các mô-đun Apache mà bạn muốn sử dụng. Tôi nghĩ worker nói chung là sự lựa chọn mặc định, nhưng một số mô-đun (cũ hơn) yêu cầu rèn và phụ thuộc vào prefork.

Nếu bạn không có sở thích, tôi khuyên bạn nên đi với sự phụ thuộc ưa thích từ phân phối HĐH của bạn. Ví dụ, Ubuntu sẽ cài đặt mpm-worker theo mặc định khi bạn cài đặt Apache2.