* FengYue <[EMAIL PROTECTED]> [001116 16:15] wrote:
>
> 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.
Actually FreeBSD uses wakeup_one() for accept(), the only problem
is when your server must wait on more than one port/IP, then you
need to use select(), however when many processes are selecting
on the same descriptor it kills performance, that's why things
like apache use semaphores or file locks instead of select.
> 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:)
Yes, it may be overkill. :)
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
