From owner-freebsd-net@FreeBSD.ORG Mon May 21 13:24:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B26116A400 for ; Mon, 21 May 2007 13:24:31 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.freebsd.org (Postfix) with ESMTP id BB17513C465 for ; Mon, 21 May 2007 13:24:30 +0000 (UTC) (envelope-from bushman@freebsd.org) Received: from [195.208.252.84] (shogun.cc.rsu.ru [195.208.252.84]) (authenticated bits=0) by mail.r61.net (8.14.1/8.14.1) with ESMTP id l4LDOI4S066088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 May 2007 17:24:18 +0400 (MSD) (envelope-from bushman@freebsd.org) Message-ID: <46519D79.7050306@freebsd.org> Date: Mon, 21 May 2007 17:24:09 +0400 From: Michael Bushkov User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20070521120021.926FE16A46D@hub.freebsd.org> In-Reply-To: <20070521120021.926FE16A46D@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Edwin Groothuis , Anton Yuzhaninov Subject: Re: faster /etc/services X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2007 13:24:31 -0000 Hi, As far as I remember this topic has been already discussed. There are basically 2 ways of speeding up /etc/services queries: 1. To use /etc/passwd-/pwd.db scheme - i.e. using BDB as the main data storage and allowing user to update it from /etc/services file by request. 2. Use the separate caching source - such as cached(8). The first solution will be very fast. But I'm not sure if it is not an overkill for /etc/services. The second solution is already implemented in cached(8). There is, of course an overhead, but there is also an average 5-times performance improvement (details are in the "Cached performance analysis" section of this paper: http://asiabsdcon.org/papers/P06-paper.pdf). In my perforce branch there is an implemented "precache" feature for cached(8), which makes things even faster. I've implemented the file-monitoring option (which updates cache automatically in case of file change) there also. But they cannot been committed before some changes in libc are made. BTW, I've sent a patch with one of such changes for review to this thread (http://lists.freebsd.org/pipermail/freebsd-net/2007-May/014128.html), but unfortunately received no feedback. Finally, I think that these solutions are pretty equal in terms of complexity and time. However, personally I think that cached(8) is more appropriate for this kind of task. But if we care about having this functionality in 6-stable, cached is not the choice, probably. > EG> - Instead of reading and parsing /etc/services every time, use a > EG> hash or btree file a la the aliases database. A hash one (first > EG> key, next key) could be a replacement to use with getservent(), > EG> while a btree one could be be a replacement to use with getservbyname(). > EG> This doesn't have the startup-penalty, but the sysadmin needs to > EG> keep track of changes in /etc/services and needs to rebuild it. > > I think it will be better solution. > /etc/services edited by sysadmin rarely and we can place comments in > this file about hash. > > EG> - Instead of reading and parsing /etc/services every time, open a > EG> socket and ask a daemon for the information. Which daemon is a > EG> good question, but it can automatically re-read the /etc/services > EG> file if it got changed. > > Connection to external daemon is additional overhead. > > Anyway, is there need to optimize getservbyname()? Is there any > applications, which call getservbyname() on each connection/request? > > IMHO /etc/services can be kept in current state. > > -- WBR, Anton Yuzhaninov -- With best regards, Michael Bushkov Southern Federal University