Comments 6
Почему веб-приложение тормозит и не держит нагрузку? <...> Ответ на поставленный вопрос кроется на более низком уровне — на уровне операционной системы. Чтобы ваше приложение держало нагрузку, необходимо пересмотреть его архитектурную концепцию таким образом, чтобы эффективно работать именно на этом уровне. Это привело к возникновению асинхронных веб-серверов.
Как-то так получается, что синхронный — дура, а асинхронный — молодец.
Пара (ок, чуть больше) замечаний:
- Нагрузка и модель работы веб-сервера — не слишком связанные штуки. Синхронный веб-сервер далеко не обязательно медленнее асинхронного или хуже справляется с нагрузкой. Зависит от задачи.
- Не совсем понятно при чем здесь ОС. Точнее совсем непонятно.
- Синхронные сервера появились не потому, что "не изобрели" асинхронный. А потому, что асинхронный сервер писать и отлаживать тяжелее. И тяжелее контролировать использование ресурсов.
- Те асинхронные сервера, о которых чаще говорим сейчас, начали развиваться для обработки медленных запросов (статика, большие файлы через медленное соединение) и поддержки большого количества открытых соединений (long polling, websockets ...).
- Появившийся в процессе инструментарий (например, конструкции async/await) позволяет здорово облегчить реализацию бизнес-логики асинхронного веб-сервиса, но никак не ускорить его работу.
- Спектр задач, решаемых асинхронными серверами, шире, чем у синхронных. Этим они сильны, а не могучей "архитектурной концепцией" или тем, что "веб-приложение не тормозит".
+3
Поскольку в Linux'е чтение с жесткого диска является блокирующей операцией, процесс (или поток) зависнет в ожидании ответа, но при этом все равно будет участвовать в распределении процессорного времени.
Разве? Зачем шедулеру предоставлять заблокированному в iowait процессу процессорное время?
+2
Во многих статьях про асинхронность рассказывают так, будто это что-то новое и прогрессивное. На самом деле мультиплексирование неблокирующихся сокетов появилось вместе с самими сокетами.
0
Ну, её и правда пришлось переоткрывать. Вспомните, сколько времени в вебе господствовал тот же Apache.
Кроме того, современная асинхронность — совсем не то же самое, что асинхронность "та самая". Сильно изменилось как низкоуровневое API (epoll и IOCP гораздо моложе сокетов Беркли), так и высокоуровневое (появились сопрограммы).
0
Ну, её и правда пришлось переоткрывать
Вы понимаете разницу между экземпляром и классом? Если понимаете, возьмите свои слова обратно.
Сильно изменилось как низкоуровневое API (epoll и IOCP гораздо моложе сокетов Беркли), так и высокоуровневое (появились сопрограммы).
Это всё экземпляры.
А вообще, комментарий, на который вы отвечали, выделяет проблему примитивизации мышления, хоть и неявно. Тот же OTUS, для рекламы которого написана статья, потоком льёт весьма примитивные выжимки из википедии и тому подобного. Когда вместо систематического изложения сложного вопроса выдают вот такие краткие выжимки, получаем поколение ЕГЭ и серую массу хомяков.
-1
Sign up to leave a comment.
Почему появились асинхронные веб-сервера?