Date: Thu, 16 Nov 2000 16:15:28 -0800 (PST) From: FengYue <fengyue@bluerose.windmoon.nu> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded tcp-server or non-blocking ? Message-ID: <Pine.BSF.4.21.0011161601150.19569-100000@shell.unixbox.com> In-Reply-To: <200011162354.SAA07155@repulse.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 16 Nov 2000, Bakul Shah wrote: ->Yes, this is definitely simpler and preferable when servicing ->a small number of concurrent requests. But you have to spawn ->off as many processes as the worst case number of concurrent ->requests you want to service since while all the processes ->are busy servicing, additional connections are not being ->accepted (after the listen backlog is exhausted). By using Well, with some additional coding, the parent process could easily monitor how many child processes are being used at a given time (like using mmap() to create a shared memory region and have the child process increases the busy_count...etc) and then to decide if it needs to spawn off some more processes into the pool based on the percentpage of number_of_busy_processes/total_processes_in_the_pool. Just like the way apache does it I guess. And, ofcoz, I agree that there are some performance impact if too many processes blocking on the accept() call. But then again, we're just talking about an easy solution for a webserver that only wants to handle no more than 15 clients at any given time:) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011161601150.19569-100000>