LINUX.ORG.RU

При каких нагрузках не обойтсь без использования неблокирующих подходов (использовать только потоки и процессы ОС)?

 , ,


0

4

Понятно, что я не говорю о точных цифрах. Меня волнует, если проект имеет солидную нагрузку (возьмем, например, «вконтакте», «одноклассники», «твиттер») может ли он существовать (и возможно сейчас существует), только на таких подходах к многозадачности, как потоки и процессы? Естественно, в счет не берется используемые внутри проекта nginx, redis и т.п. подобные инструменты, использующие неблокирующий код. Речь только о самом приложении. Приложение в основном будет I/O bound (будем считать, что речь о веб-приложении типа социальной сети).

В университете проходим тему построения высоконагруженных систем. Хотел бы узнать у знающих людей, при каких нагрузках становиться необходимым переходить на различные неблокирующие технологии (легкие потоки, event loop-ы) и уже нельзя обходится обычными потоками операционной системы? Или же можно обойтись вообще без технологий «легких потоков» для того, чтобы строить достаточно сильно нагруженные проекты?

Я не могу понять, зачем нужен такой код, который пишется на «легких потоках». Разве это не переизобретение велосипеда, когда уже есть потоки операционной системы? Я знаю, что потоки вызывают переключения контекста, что создает накладные расходы. Но эти накладные расходы не выглядят слишком большими (максимум я видел оценку в 30 микросекунд на переключение), к тому же у переключения «легких потоков» тоже должны быть накладные расходы.

P.S. Я в принципе понимаю разницы, как я думаю, между «легкими потоками», event loop-ами и различными неблокирующими технологиями. Возможно, где-то я выражаюсь не совсем корректно. Прошу меня извинить. Надеюсь все-таки понятно о чем я говорю.

Вопрос также задан тут: https://toster.ru/q/361268

С уважением, Дмитрий

Но эти накладные расходы не выглядят слишком большими (максимум я видел оценку в 30 микросекунд на переключение)

Задержки 30мс не слишком большие? Nuff said.

к тому же у переключения «легких потоков» тоже должны быть накладные расходы.

Очевидно же, что они гораздо меньше.

Deleted
()
Ответ на: комментарий от Deleted

Задержки 30мс не слишком большие? Nuff said.

Ну если на запрос в базу я трачу, допустим 10 миллисекунд, 30 микросекунд на переключение контекста в этом случае не выглядит большой цифрой. Конечно, я не отрицаю, что, если приложение обращается только в memcached 30 микросекунд могут существенно его замедлить (хотя оно все равно будет супер-быстрым), но не в случае обращений в базу. При этом напоминаю, что 30 микросекунд - пессиместичная оценка, взятая для процессов. Для потоков это все наверняка в разы быстрее.

aetolicus
() автор топика
Ответ на: комментарий от aetolicus

Ну если на запрос в базу я трачу, допустим 10 миллисекунд, 30 микросекунд на переключение контекста в этом случае не выглядит большой цифрой. Конечно, я не отрицаю, что, если приложение обращается только в memcached 30 микросекунд могут существенно его замедлить (хотя оно все равно будет супер-быстрым), но не в случае обращений в базу. При этом напоминаю, что 30 микросекунд - пессиместичная оценка, взятая для процессов. Для потоков это все наверняка в разы быстрее.

Процессы и потоки для ОС по сути одинаковые сущности. Легковесные потоки обычно плодятся миллионами и общаются в первую очередь друг с другом с помощью сообщений. Попробуй сделать на потоках простое приложение — каждый поток выбирает себе случайного соседа, посылает ему пинг, ждёт от него понг (и отвечает на пинги других в это время) и так в цикле. И проверь — сколько потоков ты сможешь запустить, сохраняя 99% ответов на пинги в пределах одной миллисекунды, например. А потом сделай ту же задачу на ерланге или голанге.

Если всё, что делает твой поток, это читает данные из сокета, пишет запрос к базе в другой сокет, ждёт ответа, читает его весь, составляет ответ и пишет его в первый сокет, при этом он никак не общается с другими потоками, сервисами, не живёт после завершения этой сессии, то да, простой пул потоков по числу процессоров + X (где X выбирается эмпирически) это вполне себе оптимальный вариант, который сложно будет побить, по крайней мере значительно.

Legioner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.