From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 11 Sep 2004 01:32:53 +0400 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: Serge Pavlovsky Message-ID: <20040910213253.GK3462@workstation> Mail-Followup-To: =?koi8-r?B?5MXOydMg883J0s7P1w==?= , Serge Pavlovsky , ALT Linux Sisyphus discussion list 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> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1094836894.2790.52.camel@underdark.interexc.com> Cc: ALT Linux Sisyphus discussion list Subject: [sisyphus] Re: =?koi8-r?b?68HLINXTy8/SydTYINLBws/U1SDTINDP1M/Lwc3JPw==?= 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: Fri, 10 Sep 2004 22:32:38 -0000 Archived-At: List-Archive: 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 + нити). >> kevent в FreeBSD. >> aio. SP> чтобы почаще threads стартовать, чтоли ? ;) :-)))) >> Самое разумное -- выносить в отдельные нити _обработку_, а как раз ждать и >> данными кидаться в небольшом количестве нитей (в несколько раз больше чем >> количество процессорв, для большей равномерности). SP> многие весьма неглупые на вид люди тоже так наивно полагают. на самом SP> деле это получится один в один доморощенная реализация user-level SP> threads - там тоже один большой select. только вот сложность получается SP> O(n^2) - чем больше потоков, тем чаще им надо читать * на тем больше SP> накладных расходов на каждый select. спрашивается, зачем делать самому SP> userlevel threads и зачем вообще это делать если оно очень быстро SP> начинает дико тормозить ? Причём тут userlevel threads? Видимо вы меня неправильно поняли. Я не предлагаю городить диспетчер, который бы распихивал по потокам пришедшие события, боже упаси. Я предлагаю гораздо более тупую (т.е. простую) и эффектвиную схему: в момент создания соединения сокет привязывается статически к одной из нитей, и обрабатывается уже только ей. Нити используем для более эффективного использования нескольких процессоров (да и одного тоже несколько нитей будут эффективнее использовать) а epoll для формирования очереди сообщений на обработку. Ну и на 100k нитей что-то мне не верится что Linux на этом не будет загибаться. -- С уважением, Денис http://freesource.info