Date: Thu, 8 Jul 1999 13:51:16 -0500 (CDT) From: Mohit Aron <aron@cs.rice.edu> To: jayanth@yahoo-inc.com (Jayanth Vijayaraghavan) Cc: freebsd-net@freebsd.org Subject: Re: paper on improving webserver performance Message-ID: <199907081851.NAA14204@cs.rice.edu> In-Reply-To: <3784EF83.8E7DD130@yahoo-inc.com> from "Jayanth Vijayaraghavan" at Jul 8, 99 11:35:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907081851.NAA14204>