steve roussey wrote: > On 8/9/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > >>PHP by default compiles as a non-pic shared library now which is just as >>fast as a static build inside Apache since it is the pic stuff that >>slows down a DSO. So there is really no need for static builds anymore, >>unless you happen to be on a fringe OS that doesn't support non-pic >>shared libs. > > > This is good to know. I guess it is time to rewrite my > build-a-new-webserver script. It has seen changes over the years but > not a comprehensive reevaluation. > > >>>Still, I looked at lighttpd and it looks promising. The one thing that >>>started all of this was Apache 2.1's event MPM that used a single >>>thread to handle all open Keep-Alives looked very efficient. >> >>I think you are probably better off solving this in a lightweight >>frontend process. Chances are you are going to need lingerd if you go >>keepalive, so perhaps the real solution is to make lingerd handle not >>just the shutdown, but also the startup of the request. > > > You know, I remember considering lingerd a long time ago... and I feel > like an idiot for not using all these years! If it is not in my script > it doesn't cross my mind. So I have that on today's todo list. (This > seems like something Apache2 should do automatically in its threaded > MPMs, not that we would be using mod_php here or anything, but maybe > > I am confused by your statement above, so I have tried not to email > back until I could find more information, but I could not. In the > lingerd website it says "lingerd can only do an effective job if HTTP > Keep-Alives are turned off" which is confusing when compared to your > statement above. Unless you are combining it with the lightweight > process (I assume a proxy server). Then it makes sense. Except for the > part about having lingerd hande the startup of the request, at which > point I'm clueless again.
Well, I don't know about the specific lingerd implementation, but the need for SO_LINGER sockets become more critical when you turn on keepalive because the chances of closing a socket when the client is sending or about to send something becomes much higher the longer you sit around with the socket open in a keepalive situation. And if you eventually move to support pipelined requests (if browsers would ever support that) then you absolutely must use SO_LINGER sockets. SO_LINGER sockets mean that we close down just one end of the socket and linger around waiting for the client to flush any data (which is then thrown out) and then finally shut down everything. The big problem is that most operating systems, for reasons I have never understood, block on the close when SO_LINGER is set on it. I always thought that made absolutely no sense and is something the damn kernel's stack should just take care of, but it doesn't, and you end up sitting around twiddling your thumbs in userspace waiting for the lingering socket to shut down. Apache has a workaround called lingering_close() that tries to address broken SO_LINGER implementations, but it also blocks. So, lingerd is supposed to help this situation by taking over the socket closing. Apache hands off to lingerd and can move onto the next request and lingerd sits around waiting for the sockets to close down. I don't really see a technical reason why lingerd cares whether the connection was a keepalive connection or not. Seems to me like a simple implementation detail of hooking the socket handoff into the right place in Apache. If you turn the concept of lingerd upside down and bounce socket descriptors back and forth between it and Apache between keepalive requests you can free up Apache from any sort of sitting around waiting on socket timeouts or linger outs. The last thing you want is a heavy single-threaded process like Apache sitting around waiting on some socket event. It should be crunching out pages as fast as possible not waiting on a keepalive or SO_LINGER timeout. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
