From owner-freebsd-net Wed Jul 7 22:11:54 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 58CA9154A4 for ; Wed, 7 Jul 1999 22:11:37 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id AAA28180; Thu, 8 Jul 1999 00:11:33 -0500 (CDT) From: Mohit Aron Message-Id: <199907080511.AAA28180@cs.rice.edu> Subject: Re: paper on improving webserver performance To: jlemon@americantv.com (Jonathan Lemon) Date: Thu, 8 Jul 1999 00:11:33 -0500 (CDT) Cc: freebsd-net@freebsd.org In-Reply-To: <19990707231308.40142@right.PCS> from "Jonathan Lemon" at Jul 7, 99 11:13:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Yes, I thought the same thing too. Originally, my implmentation simply > moved all connections in a TIME_WAIT states onto a separate timing wheel, > and left the rest of the code alone. > > Turns out that the overhead of inserting/deleting events from the timing > wheel is trivial as compared to the cost of checking the hash buckets and > walking the chains checking for events. > Possibly that might be the reason why my timing wheel is performing worse. In any case, a 5% difference isn't much to worry about - the earlier drafts of my paper also had a full description of the timing wheel. We threw that out because of space limitations and since the list implementation was simple and promising enough. In any case, I'd like to know how your timing wheel performs vs my list based implementation (the latter is really easy to implement). Perhaps you can compare the two. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message