From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Organization: ISP Farlep (Odessa) Subject: Re: [sisyphus] Re: =?koi8-r?Q?=EB=C1=CB?= =?koi8-r?Q?_=D5=D3=CB=CF=D2=C9=D4=D8?= =?koi8-r?Q?_=D2=C1=C2=CF=D4=D5?= =?koi8-r?Q?_=D3?= =?koi8-r?Q?_=D0=CF=D4=CF=CB=C1=CD=C9=3F?= From: Serge Pavlovsky To: ALT Linux Sisyphus discussion list In-Reply-To: <20040910213253.GK3462@workstation> References: <413DC4C9.9060406@users.sourceforge.net> <000201c494f0$9e116ae0$4d0010ac@aprcity.com> <20040907173650.GB20569@workstation> <1094710157.2790.10.camel@underdark.interexc.com> <20040909190728.GF8157@workstation> <1094773860.2763.14.camel@underdark.interexc.com> <20040910025455.GF16262@workstation> <1094836894.2790.52.camel@underdark.interexc.com> <20040910213253.GK3462@workstation> Content-Type: text/plain; charset=KOI8-R Date: Mon, 13 Sep 2004 03:19:15 +0300 Message-Id: <1095034755.2763.69.camel@underdark.interexc.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.92.1 (1.5.92.1-alt0.5) Content-Transfer-Encoding: 8bit X-Virus-Scan: smtp-vilter X-SMTP-Vilter-Version: 1.1.4 X-SMTP-Vilter-Backend: vilter-clamd X-SMTP-Vilter-Status: clean X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 00:19:01 -0000 Archived-At: List-Archive: 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 - будет. но мы ведь дождемся светлого будущего ;)