[sisyphus] Re: Как ускорить работу с потоками?

[Serge Pavlovsky]

On Сбт, 2004-09-11 at 01:32 +0400, Денис Смирнов wrote:
> On Fri, Sep 10, 2004 at 08:21:34PM +0300, Serge Pavlovsky wrote:
> >> epoll, например :)
> >> select/poll на худой конец.
>  SP> когда вы в последний раз измеряли производительность epoll/select/poll
>  SP> на 100к сокетов ?
>  SP> конечно, epoll быстрее, чем select, но недостаточно
> 
> Я не мерял на 100k сокетов. Поделитель тестовым кодом, если вы меряли?

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

> И думается мне, что на 100k сокетов будет эффективнее всего работать
> смешаная модель (epoll + нити).

спящие нити при правильном ( О(1) ) шедулере никому не мешают. а epoll -
мешает

> >> Самое разумное -- выносить в отдельные нити _обработку_, а как раз ждать и
> >> данными кидаться в небольшом количестве нитей (в несколько раз больше чем
> >> количество процессорв, для большей равномерности).
>  SP> многие весьма неглупые на вид люди тоже так наивно полагают. на самом
>  SP> деле это получится один в один доморощенная реализация user-level
>  SP> threads - там тоже один большой select. только вот сложность получается
>  SP> O(n^2) - чем больше потоков, тем чаще им надо читать * на тем больше
>  SP> накладных расходов на каждый select. спрашивается, зачем делать самому
>  SP> userlevel threads и зачем вообще это делать если оно очень быстро
>  SP> начинает дико тормозить ?
> 
> Причём тут userlevel threads? Видимо вы меня неправильно поняли. Я не
> предлагаю городить диспетчер, который бы распихивал по потокам пришедшие
> события, боже упаси. Я предлагаю гораздо более тупую (т.е. простую) и
> эффектвиную схему: в момент создания соединения сокет привязывается
> статически к одной из нитей, и обрабатывается уже только ей. Нити
> используем для более эффективного использования нескольких процессоров (да
> и одного тоже несколько нитей будут эффективнее использовать) а epoll для
> формирования очереди сообщений на обработку.

это вы меня не правильно поняли ;)
нету никакой обработки - вся работа с сокетами. прочесть - записать. все
время уходит на poll. зачем же еще тратить время на очередь сообщений ?

userlevel threads, если от них отрезать переключение контекста, как раз
представляют собой генерацию одного большого select на каждый чих вроде
read() или write(). и тормозит как раз это, а не переключение контекста.

> Ну и на 100k нитей что-то мне не верится что Linux на этом не будет
> загибаться.

ну, на нашем ядре/libc - будет. но мы ведь дождемся светлого будущего ;)