Комментарии 6
Почему веб-приложение тормозит и не держит нагрузку? <...> Ответ на поставленный вопрос кроется на более низком уровне — на уровне операционной системы. Чтобы ваше приложение держало нагрузку, необходимо пересмотреть его архитектурную концепцию таким образом, чтобы эффективно работать именно на этом уровне. Это привело к возникновению асинхронных веб-серверов.

Как-то так получается, что синхронный — дура, а асинхронный — молодец.
Пара (ок, чуть больше) замечаний:


  1. Нагрузка и модель работы веб-сервера — не слишком связанные штуки. Синхронный веб-сервер далеко не обязательно медленнее асинхронного или хуже справляется с нагрузкой. Зависит от задачи.
  2. Не совсем понятно при чем здесь ОС. Точнее совсем непонятно.
  3. Синхронные сервера появились не потому, что "не изобрели" асинхронный. А потому, что асинхронный сервер писать и отлаживать тяжелее. И тяжелее контролировать использование ресурсов.
  4. Те асинхронные сервера, о которых чаще говорим сейчас, начали развиваться для обработки медленных запросов (статика, большие файлы через медленное соединение) и поддержки большого количества открытых соединений (long polling, websockets ...).
  5. Появившийся в процессе инструментарий (например, конструкции async/await) позволяет здорово облегчить реализацию бизнес-логики асинхронного веб-сервиса, но никак не ускорить его работу.
  6. Спектр задач, решаемых асинхронными серверами, шире, чем у синхронных. Этим они сильны, а не могучей "архитектурной концепцией" или тем, что "веб-приложение не тормозит".
Поскольку в Linux'е чтение с жесткого диска является блокирующей операцией, процесс (или поток) зависнет в ожидании ответа, но при этом все равно будет участвовать в распределении процессорного времени.

Разве? Зачем шедулеру предоставлять заблокированному в iowait процессу процессорное время?

ну la же расти будет, в букваре написано, что большой la — плохо


P.S. шутка, если кто не понял.

Во многих статьях про асинхронность рассказывают так, будто это что-то новое и прогрессивное. На самом деле мультиплексирование неблокирующихся сокетов появилось вместе с самими сокетами.

Ну, её и правда пришлось переоткрывать. Вспомните, сколько времени в вебе господствовал тот же Apache.


Кроме того, современная асинхронность — совсем не то же самое, что асинхронность "та самая". Сильно изменилось как низкоуровневое API (epoll и IOCP гораздо моложе сокетов Беркли), так и высокоуровневое (появились сопрограммы).

Ну, её и правда пришлось переоткрывать

Вы понимаете разницу между экземпляром и классом? Если понимаете, возьмите свои слова обратно.
Сильно изменилось как низкоуровневое API (epoll и IOCP гораздо моложе сокетов Беркли), так и высокоуровневое (появились сопрограммы).

Это всё экземпляры.

А вообще, комментарий, на который вы отвечали, выделяет проблему примитивизации мышления, хоть и неявно. Тот же OTUS, для рекламы которого написана статья, потоком льёт весьма примитивные выжимки из википедии и тому подобного. Когда вместо систематического изложения сложного вопроса выдают вот такие краткие выжимки, получаем поколение ЕГЭ и серую массу хомяков.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.