From owner-freebsd-hackers Tue Apr 10 15: 1:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 53C8737B42C for ; Tue, 10 Apr 2001 15:01:06 -0700 (PDT) (envelope-from dphoenix@bravenet.com) Received: (qmail 6420 invoked by uid 1000); 10 Apr 2001 22:01:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Apr 2001 22:01:05 -0000 Date: Tue, 10 Apr 2001 15:01:05 -0700 (PDT) From: Dan Phoenix To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lockf in apache In-Reply-To: <20010410131254.V15938@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok let's take this for example Listen 172.16.0.26:80 Listen 172.16.6.2:80 NameVirtualHost 172.16.0.26:80 NameVirtualHost 172.16.6.2:80 .6.2 is real ip for load balancer. .0.x is for internal use so let;s rewrite. Bind * Port 80 NameVirtualHost 172.16.0.26 NameVirtualHost 172.16.6.2 this the idea? not even sure why .0.26 etc was setup tha tis just for internal testing but a good thing to have...maybe a NameVirtual * VirtualHost * not sure if i can get away with that....i will play with it for abit.. let me know if you already know off hand. reason we even have namevirtualhost is because we have alot of virtual hosts setup and is required in that case as they all use same ip address. thx. Dan On Tue, 10 Apr 2001, Alfred Perlstein wrote: > Date: Tue, 10 Apr 2001 13:12:54 -0700 > From: Alfred Perlstein > To: Dan Phoenix > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: lockf in apache > > * Dan Phoenix [010410 13:02] wrote: > > > > > > show alot of that in top > > occasioanally....think that could be from nfs timeouts > > or just waiting on mysql connections to come back? > > > > what are they generally from? > > They're using a lockfile around the select() call on the accept'ing > socket. > > Basically, when apache is listening on multiple IPs/ports it needs > to select() on several filedescriptors. The problem (under FreeBSD > at least) is that whenever you have some process select()'ing on > a descriptor and another process wants to do the same you get a > "select collision", a collision requires that all processes waiting > on the same select channel wake up then reassert thier desire to > select. So... if you have 500 apache processes select()'ing and > one wakes up to service a request, finished serving, then goes to > select again, all the rest (499) have to wake up and reaffirm thier > desire to select(). > > This doesn't scale very well at all. > > What apache does to fix this, is only allow one process to select() > at any given time by keeping a lockf lock on a file while waiting > in select(). When select returns it releases the lock and this > allows another process to enter the select() call. > > It's still not as efficient because (under FreeBSD) I think this > still can wakeup each process blocked on the lock, but it's still > an order of magnitude better than having select() collisions. > > If you want to get it the most optimal, try to not specify individual > IPs for apache to bind to. If you can tell apache to bind to only > port 80 on "*" (all IPs) you'll get much better performance because > then apache no longer needs to select, it only needs to accept() > on a single socket which is the most optimal thing to do. > > You'll know if you've got the single select working if you see the > majority of the apache processes in "accept" rather than "lockf". > > You might also want to check out using accept filters to get even > more performance out of apache, see the accf_http manpage and check > the apache docs for the compile time stuff you need to do to enable > this. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message