Срібної кулі немає
На практиці це залежить ...
tl; dr - просте рішення, використовуйте nginx ...
Блокування:
Наприклад, Apache за замовчуванням використовує схему блокування, де процес розщеплений для кожного з'єднання. Це означає, що кожне з'єднання потребує власного простору пам’яті, і велика кількість накладних режимів перемикання контексту збільшується все більше, оскільки кількість з'єднань збільшується. Але користь полягає в тому, що коли з'єднання закрите, контекст може бути розміщений і будь-яку / всю пам'ять можна легко отримати.
Багатопотоковий підхід був би аналогічним тим, що накладні витрати на комутацію контексту збільшуються зі збільшенням кількості підключень, але можуть бути більш ефективними в пам'яті у спільному контексті. Проблема такого підходу полягає в тому, що важко керувати спільною пам'яттю безпечним чином. Підходи до подолання проблем синхронізації пам'яті часто включають власні накладні витрати, наприклад, блокування може заморозити основний потік на завантажених процесором завантаженнях, а використання незмінних типів додає багато непотрібного копіювання даних.
AFAIK, використання багатопроцесорного підходу на блокуванні HTTP-сервера, як правило, є кращим, оскільки безпечніше / простіше керувати / відновлювати пам'ять безпечним чином. Збір сміття стає проблемою, коли відновлення пам'яті настільки ж просто, як і зупинка процесу. Для тривалих процесів (тобто демон) ця характеристика особливо важлива.
Хоча контекстна комутація накладних витрат може здатися незначною при невеликій кількості працівників, недоліки стають більш актуальними, оскільки масштаб навантаження до сотень до тисяч одночасних з'єднань. У кращому випадку масштаб переключення контексту O (n) на кількість присутніх працівників, але на практиці це, швидше за все, гірше.
Якщо сервери, які використовують блокування, не можуть бути ідеальним вибором для великих навантажень вводу-виводу, вони ідеально підходять для роботи з процесором і передача повідомлень залишається мінімальною.
Неблокуючий:
Неблокування буде чимось на зразок Node.js або nginx. Вони особливо відомі тим, що масштабують значно більшу кількість з'єднань на вузол під навантаженням, що інтенсивно застосовується. В основному, як тільки люди потрапили на верхню межу того, з якими серверами на основі потоків / процесів можуть працювати, вони почали вивчати альтернативні варіанти. Це інакше відома як проблема C10K (тобто можливість обробляти 10000 одночасних з'єднань).
Неблокуючі сервери асинхроніки, як правило, мають багато характеристик із підходом із багатопотоковим блокуванням, тому що ви повинні бути обережними, щоб уникнути завантаження процесором, оскільки ви не хочете перевантажувати основний потік. Перевага полягає в тому, що накладні витрати, що виникають при переключенні контексту, по суті усуваються, і лише передача одного контекстного повідомлення стає проблемою.
Хоча це може не працювати для багатьох протоколів мереж, природа HTTPs без громадянства працює особливо добре для неблокуючих архітектур. Використовуючи комбінацію зворотного проксі-сервера та декількох неблокуючих HTTP-серверів, можна ідентифікувати та прокладати навколо вузлів, що зазнають великого навантаження.
Навіть на сервері, на якому є лише один вузол, в програмі дуже часто входити один сервер на ядро процесора для максимальної пропускної здатності.
Обидва:
"Ідеальним" випадком використання було б поєднання обох. Зворотний проксі спереду, присвячений маршрутизації запитів у верхній частині, потім поєднання серверів, що блокують та не блокують. Не блокуючи такі завдання вводу-виводу, як розміщення статичного вмісту, вмісту кешу, вмісту html. Блокування важких для процесора завдань, таких як кодування зображень / відео, потокове передавання вмісту, стискання чисел, запис у базу даних тощо.
У вашому випадку:
Якщо ви просто перевіряєте заголовки, але насправді не обробляєте запити, те, що ви, по суті, описуєте, є зворотним проксі. У такому випадку я б точно підходив до асинхронного підходу.
Я б запропонував переглянути документацію для вбудованого зворотного проксі-сервера nginx .
Убік:
Я читав списання з наданого вами посилання, і має сенс, що асинхрон був поганим вибором для їх конкретної реалізації. Питання можна підсумувати в одній заяві.
Виявив, що при перемиканні між клієнтами код для збереження та відновлення значень / стану був важким
Вони будували державну платформу. У такому випадку асинхронний підхід означатиме, що вам доведеться постійно зберігати / завантажувати стан щоразу, коли контекст перемикається (тобто, коли подія запускається). Крім того, на стороні SMTP вони роблять багато роботи, що вимагає процесора.
Здається, вони мали досить слабке розуміння асинхронності, і, як наслідок, зробили багато поганих припущень.