Як вибрати, який Apache MPM використовувати?


261

Це канонічне запитання щодо вибору потрібного Apache httpd MPM.

Я трохи заплутався між різними МРМ, запропонованими Apache - "робітник", "подія", "префорк" тощо.

Які основні відмінності між ними, і як я можу вирішити, який з них буде найкращим для даного розгортання?


4
Якщо ви підтримуєте mod_php, ви робите префорк.
Зоредаче

6
@Zoredache:? вона ніколи не згадувала PHP, і навіть якби вона була, mod_php виключила б лише подію. Або ви все ще чіпляєтесь за зауваженням, зробленим RL 8 років тому? Останнє повідомлення про помилку в PHP, пов’язане з потоком apache, було в 2005 році.
symcbean

2
Вибачте - мені потрібно проголосувати, щоб закрити це - тут занадто широке питання, щоб відповісти тут.
symcbean

1
@symcbean Re: PHP і теми - Основа PHP є безпечною ниткою в ці дні, але багато інших речей, які ви знайдете людей, що збираються, не є. Мене покусали зовсім недавно, як минулого року, так що це дуже "тест (широко), перш ніж покладатися на нього у виробництві" ситуація все ще ...
voretaq7

Залежно від ОС, яку ви використовуєте, можливо, навіть не всі ці параметри доступні при стандартній установці.
Джон Гарденєр

Відповіді:


415

Є цілий ряд модулів MPM (Мульти-Модулі обробки), але на сьогоднішній день найбільш широко використовується (принаймні , на * NIX платформах) є трьома основними з них: prefork, worker, і event. По суті, вони представляють еволюцію веб-сервера Apache і різні способи створення сервера для обробки запитів HTTP у межах обчислювальних обмежень за довгу (в програмному відношенні) історію.


prefork

mpm_preforkє .. ну .. це сумісно з усім. Він відкручує ряд дочірніх процесів для обслуговування запитів, і дочірні процеси обслуговують лише один запит за один раз. Оскільки серверний процес сидить там, готовий до дії, і не потрібно мати справу з розбиттям потоків, це насправді швидше, ніж більш сучасні потокові MPM, коли ви одночасно займаєтесь лише одним запитом - але паралельні запити страждають, оскільки вони змушені чекати в черзі, поки серверний процес не буде вільним. Крім того, намагаючись збільшити кількість процесів дочірньої підготовки, ви легко відсмоктуєте серйозну оперативну пам'ять.

Можливо, не рекомендується використовувати префорк, якщо вам не потрібен модуль, який не є безпечним для потоків.

Використовуйте, якщо: Вам потрібні модулі, які ламаються, коли використовуються нитки, наприклад mod_php. Вже тоді подумайте про використання FastCGI і php-fpm.

Не використовуйте, якщо: Ваші модулі не розбиваються на різьблення.

worker

mpm_workerвикористовує нитку - це велика допомога для одночасності. Працівник відкручує деякі дочірні процеси, які в свою чергу відкручують дочірні нитки; подібно до префорка, деякі запасні нитки готуються, якщо можливо, для обслуговування вхідних з'єднань. Цей підхід значно приємніший для оперативної пам'яті, оскільки кількість потоків не має прямого відношення до використання пам'яті, як це робить кількість серверів у префорках. Він також обробляє паралельність набагато простіше, оскільки для з'єднання просто потрібно дочекатися вільної нитки (яка зазвичай доступна) замість запасного сервера в префорку.

Використовуйте, якщо: Ви перебуваєте на Apache 2.2 або 2.4 та працюєте в основному з SSL.

Не використовуйте, якщо: Ви дійсно не можете помилитися, якщо вам не потрібен префорк для сумісності.

Однак зауважте, що протектори прикріплені до з'єднань, а не до запитів - це означає, що з'єднання в режимі "живого" завжди тримає потік, доки воно не закриється (що може тривати довгий час, залежно від конфігурації). Тому ми маємо ..

event

mpm_eventдуже схожий на працівника, структурно; він просто перейшов з "експериментального" в "стабільний" статус в Apache 2.4. Велика різниця полягає в тому, що він використовує виділений потік для обробки збережених живих з'єднань і передає руки до дочірніх потоків лише тоді, коли запит був фактично зроблений (дозволяючи цим потокам звільнити резервну копію відразу після завершення запиту). Це відмінно підходить для одночасності клієнтів, які необов’язково є активними одночасно, але часто запитують, і коли клієнти можуть мати тривалий час очікування.

Виняток тут - із з'єднаннями SSL; у такому випадку він поводиться однаково з робочим (склеюючи задане з'єднання даною ниткою, поки з'єднання не закриється).

Використовуйте, якщо: Ви перебуваєте на Apache 2.4 і вам подобаються потоки, але вам не подобається, щоб потоки очікували на простої з'єднання. Всім подобаються нитки!

Не використовуйте, якщо: Ви не на Apache 2.4, або вам потрібен префорк для сумісності.


У сучасному світі slowloris , AJAX та веб-переглядачів, які люблять мультиплексувати 6 TCP-з'єднань (звичайно, із збереженням живих) до вашого сервера, одночасність є важливим фактором для того, щоб ваш сервер добре масштабував і масштабував. Історія Apache зв'язала це з цього приводу, і хоча це дійсно досі не врівень з подібними nginx або lighttpd за рівнем використання ресурсів або масштабів, зрозуміло, що команда розробників працює над створенням веб-сервера, який все ще актуальний в сучасному світі з високим рівнем запиту та одночасності.


3
-1: IME, працівник лише зменшує розмір сліду httpd у районі 15% (IIRC Linux повідомляє COW в RSS, що робить попередню вилку таким чином, ніби вона використовує набагато більше пам'яті, ніж вона). Існує мізерна різниця між слідом ядра для процесу та потоком NPTL. Це довгий шлях від руйнування землі. Я не розумію, чому ви вважаєте, що очікування та розподілення потоку є більш ефективним у плановому плані, ніж очікування / планування (заздалегідь розробленого) процесу. Ні те, що ти думаєш, що SSL має в цілому вона.
symcbean

9
@symcbean Отже, ви говорите, що 15% використання оперативної пам’яті не суттєво? Це добре, але моя думка була б інакше. Претензії щодо конкурентоспроможності - це не моя власна. Дивіться тут . А різниця в SSL чітко прописана в документації до події MPM:The improved connection handling does not yet work for certain connection filters, in particular SSL. For SSL connections, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection.
Шейн Мадден

3
@ShaneMadden `і хоча це насправді все ще не врівень з подібними nginx або lighttpd з точки зору використання ресурсів або масштабу," у мене були апаші для обох цих систем.
Келлі Елтон

@ShaneMadden щодо проблеми з SSL та події MPM: Чи знаєте ви, чи nginx справляється з цим значно краще, ніж апаш?
DASKAjA

Здається, що якщо ви компілюєте apache 2.4, не знаючи про модулі mpm, він постачається з модулем з ім'ям модуль mpm, і він працює з mod_php7 (зараз я досліджую mpm, оскільки apache2.4 перевищує ліміт з'єднання mysql, тоді як apache 2.2 з тим же сервером mysql є немає)
BioHazard

8

Ось хороше пояснення, як це працює з GIF:

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

Коротко: якщо вам на 2.4 і вам потрібен httpd як зворотний проксі (диспетчер), то ваш вибір - MPM події


Навіть якщо ми використовуємо SSL? Я використовую apache в якості проксі-сервера та SSL-засобу на веб-сайті, що не є SSL.
bokan

@bokan виглядає так, це найкраще, але все-таки доступ для SSL обмежений
Юра

Вау ~ ~ Повідомлення в блозі набагато краще, ніж прийнята відповідь, і gif чудові! Дякую. Ти врятував мені день.
Рік

6

Станом на лютий 2018 року в документації Apache 2.4 для Event MPM зазначено, що використання Apache як проксі-сервера дозволить утримати "покращену обробку з'єднання" з 2.4.24 від роботи, як було задумано. Дивіться розділ Обмеження .

Проблема полягає в тому, що, як проксі, працівник не може сказати, де закінчується відповідь, і змушений буде почекати, поки не буде показана вся відповідь, перш ніж повернути контроль слухачеві.

З цієї причини, здається, що використання моделі Worker може бути найкращим, коли apache використовується як проксі. Мені не зовсім зрозуміло, чи є переваги моделі подій у проксі-середовищі, але, можливо, вони є.


5

В основному залежить від того, які модулі Apache ви хочете використовувати. Я думаю, що працівник, як правило, є вибором за замовчуванням, але деякі (більш старі) модулі вимагають розщеплення і залежать від префорка.

Якщо у вас немає переваг, я рекомендую вам перейти з бажаною залежністю від вашого дистрибутива на ОС. Наприклад, Ubuntu за замовчуванням встановить mpm-worker при установці Apache2.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.