LINUX.ORG.RU

Оверхед на переключение контекста при использовании неблокирующих сокетов

 ,


0

2

Возьмем nginx vs apache в качестве прокси.

Nginx:

Вызываем select (epoll_wait/kevent/whatever) — контекст переключается. Получаем дескриптор(ы). Дальше вызываем read — контекст переключается. Вызываем write — контекст переключается. Т.е. имеем переключение контекста на каждый read/write + на select.

Apache:

Имеем кучу потоков, каждый из которых спит ожидая записи/чтения из/в сокета. Приходят данные — контекст переключается. Какие то дополнительные переключения между вызовами блокирующих функций крайне маловероятны.

Т.е при прочих равных, по _количеству_ переключений треды даже немного лучше, т.к. нет дополнительного вызова select.

Тысячи тредов спящих в ожидании завершения операции ввода/вывода для операционки мало чем отличиются от тысяч сокетов в мультиплексоре делающих то же самое. Нет?

Получается у апача более дорогой только прием нового соединения, а все остальное не более чем миф?

★★★★

Проблема не в переключениях контекста, а в шедулинге тысяч тредов.

anonymous
()

Вызываем select (epoll_wait/kevent/whatever) — контекст переключается. Получаем дескриптор(ы). Дальше вызываем read — контекст переключается.

нет, не переключается.

Вызываем write — контекст переключается.

нет, не переключается.

Т.е. имеем переключение контекста на каждый read/write + на select.

нет не имеем.

треды даже немного лучше

треды то же самое, только на каждый поток надо стек и структура процесса в ядре. иди лучше уроки учи.

anonymous
()

Вызываем select (epoll_wait/kevent/whatever)

select юзермодный, никуда он не переключает ничего.

Имеем кучу потоков, каждый из которых спит ожидая записи/чтения из/в сокета.

На еполе он висит. Только он там глубоко спрятан.

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

select юзермодный, никуда он не переключает ничего.

Лол.

Ладно. Есть версия, что возвращаясь из системного вызова, в тот же процесс/тред который работал последним, мы не настраиваем все заново. Получается что эта оптимизация и делает погоду при большом трафике.

redixin ★★★★
() автор топика

ТС хуйню написал. Нормально поработать процессу с over 9000 обычных тредов.

anonymous
()

Тысячи тредов спящих в ожидании завершения операции ввода/вывода для операционки мало чем отличиются от тысяч сокетов в мультиплексоре делающих то же самое. Нет?

Несколько разные вещи - ждать событий на 10k дескрипторах при сотне потоков или управлять исполнением 10k потоков, каждый из которых ждёт на одном дескрипторе и в любой момент может захотеть исполняться.

Sorcerer ★★★★★
()
Последнее исправление: Sorcerer (всего исправлений: 1)

Ты считаешь метрику «число переключений контекста». Возможно по ней ты верно считаешь. Правда ты всё равно не показал, на сколько выше число переключений контекста при использовании select, я думаю, на считанные проценты, потому что в нагруженной системе каждому select-у будет соответствовать множество операций чтения/записи.

Но эта метрика сама по себе смысла не имеет. Надо считать нагрузку процессора. А она в случае потоков также несёт в себе нагрузку на управление потоками. И по этой полной нагрузке при большом числе потоков скорее всего второй вариант будет сильно проигрывать первому.

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

Legioner ★★★★★
()
Ответ на: комментарий от redixin

пол вернёт дескриптор, из которого можно читать без блокировки. нет блокировки - нет переключения. что не ясно, школьник?

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

похоже ты путаешь переключение контекста с шедулингом процессов, хотя и в этом случае, если много равноправных процессов на одном ядре, тоже будет решедулинг по таймеру

так что давай дуй уроки делать

anonymous
()

У потоков (которые в современных никсах реализованы через процессы) существенно больше связанных данных, чем у сокетов. Ну и кванты времени для них рассчитывать не нужно, т.е. шедулинг намного примитивнее

annulen ★★★★★
()
Ответ на: комментарий от anonymous

А системный вызов read у тебя будет в юзерспейсе что-ли отрабатывать?

zloy_starper ★★★
()
Ответ на: комментарий от anonymous

таки иди учи уроки:

$ man 3 select
No manual entry for select
anonymous
()
Ответ на: комментарий от anonymous

дескриптор, из которого можно читать без блокировки

ты позоришь анонимуса. брысь

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

4.2

У потоков (которые в современных никсах реализованы через процессы)

ты с линупсами попутал

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

Кстати, хотя select в них не входит, но некоторые сисвызовы реализованы через vdso, дабы уменьшить оверхед.

anonymous
()
Ответ на: 4.2 от anonymous

Во всех никсах с моделью 1:1 нет принципиальной разницы между процессом и потоком, разница максимум в запускающем сисколле и в особенностях доставки сигналов

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

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

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

Сискол один и тот же - clone. Там различие уже на уровней флагов.

kirk_johnson ★☆
()

Переключение контекста уже давно выполняется одной инструкцией процессора. Так что вряд-ли ты получишь огромный выигрыш от кучи тредов без poll/select.

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