From owner-freebsd-stable@FreeBSD.ORG Fri Dec 7 19:23:40 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 024F916A41A; Fri, 7 Dec 2007 19:23:40 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (unknown [IPv6:2001:610:1908:1000:204:23ff:feb7:ef56]) by mx1.freebsd.org (Postfix) with ESMTP id 7A85013C4CC; Fri, 7 Dec 2007 19:23:39 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id lB7JNViq021100; Fri, 7 Dec 2007 20:23:32 +0100 From: Pieter de Goeje To: Eugene Grosbein Date: Fri, 7 Dec 2007 20:23:31 +0100 User-Agent: KMail/1.9.7 References: <4758DCDA.ED9F0C56@kuzbass.ru> <200712071541.41808.pieter@degoeje.nl> <20071207144730.GA45443@svzserv.kemerovo.su> In-Reply-To: <20071207144730.GA45443@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712072023.31632.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Jeremy Chadwick , Patrick van Iersel , freebsd-stable@freebsd.org Subject: Re: Extreme load with local password db lookups X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 19:23:40 -0000 On Friday 07 December 2007, Eugene Grosbein wrote: > > I would like to point out that in FreeBSD 7.x there is a daemon called > > nscd. I believe it was created exactly for this purpose (speeding up name > > lookups by caching them). > > Is it true that 4.x has nearly O(n) lookup speed while later versions > has O(n^2) method? Why 4.x does not need caching daemon to be quick? > I don't really know but judging from the others posts the "files" lookup method is still O(n) thus no change there. The "compat" method could be slow because of a number of reasons, one of them is bad complexity. One would have to look at the code to find out...