From owner-freebsd-net Thu Jul 8 11:51:26 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 E66461506A for ; Thu, 8 Jul 1999 11:51:23 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id NAA14204; Thu, 8 Jul 1999 13:51:18 -0500 (CDT) From: Mohit Aron Message-Id: <199907081851.NAA14204@cs.rice.edu> Subject: Re: paper on improving webserver performance To: jayanth@yahoo-inc.com (Jayanth Vijayaraghavan) Date: Thu, 8 Jul 1999 13:51:16 -0500 (CDT) Cc: freebsd-net@freebsd.org In-Reply-To: <3784EF83.8E7DD130@yahoo-inc.com> from "Jayanth Vijayaraghavan" at Jul 8, 99 11:35:47 am 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 > In your paper you discuss about having an application restrict the no. of > idle connections to 10000 for http 1.1. I am sure there are a lot > of servers that have much more than 10000 connections that are idle > and have some sort of keep alive mechanism turned on (not just http 1.1), I consider the keepalive mechanism with HTTP/1.0 and the HTTP/1.1 styled persistent connections to be really synonymous. > even if the time for which the connections are idle be of the order of minutes. > Scanning the list now could be time consuming . Wouldnt a timewheel be more > generic as it handles all the timers ? > Absolutely - a timing wheel's performance degrades very little with idle connections. However, I was under the impression that most servers only allow idle connections upto a max of 15 secs. Second, I would've thought that servers would run into other problems with such a huge number of idle connections - e.g. running out of file descriptors. Though I don't know how real servers plan to control the idle connections, but I think they're probably going to impose some restriction on the maximum number of such connections and close them prematurely (which HTTP allows) after a timeout or after a max is reached. My results indicate that for 10000 idle connections (which seems rather large) the list implementation only has a degradation of 5%. The list implementation seemed both simple and scalable and that's the reason why I proposed it. However, the timing wheel performs within 5% and as far as performace goes, I don't really see compelling reasons for choosing one over the other. I've remarked this earlier on this list too. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message