Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-12 Thread Brian J. France

On Aug 11, 2005, at 7:48 PM, steve roussey wrote:

o Apache 2+ uses SO_LINGER by default if it defined for that system.


Really?  We just did a around of discussion/debugging on this at work 
and I found that it uses ap_lingering_close which is like the 
lingering_close function in 1.3.



Apache 1 will only use it if you define USE_SO_LINGER (I suppose in
configure).


Right and the default is to use lingering_close, unless NO_LINGCLOSE is 
defined on some os-es like SUNOS4, IRIX, NEXT, AUX3, UW.



 Apache2 has all sorts of stuff in the comments of the code
and in the manual which is just wrong. Its all from Apache1 and does
not reflect on Apache2's implementation. I wish they just erased it
instead.


I just wish people would fix the TCP stack, it is broken damn it.


o As far as I can tell, current Linux will block until all data is
sent, then return (doing the actual closing part in the background)
with SO_LINGER.


This is what we found for Linux and FreeBSD, kernel guys say it is not 
a bug in the TCP stack sense everybody blocks.



o Lingerd caused my apache setup to crash. It was worth a try if it
didn't take much effort, but not worth fixing.


Are people really finding that they need lingerd?

For 1.3 we have keepalive off and build with NO_LINGCLOSE, which means 
be blast the data to the kernel buffer (set large) close the socket and 
move on.  We have been doing this for at least 3+ years and I have 
never heard any complaints and we server a lot of requests/client (I am 
tied with Rasmus).


Brian

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-12 Thread steve roussey
srclib/apr/network_io/unix/sockopt.c:if
(setsockopt(sock-socketdes, SOL_SOCKET, SO_LINGER, (char *) li,
sizeof(struct linger)) == -1)
...

It gets set if APR_SO_LINGER, is set which it is:

   srclib/apr/include/apr_network_io.h:#define APR_SO_LINGER1 
  /** Linger */

and if SO_LINGER is set, which it is inside the linux socket include
file (the included bits one, but I'm going by memory here).


On 8/11/05, Xuefer [EMAIL PROTECTED] wrote:
 sorry, but i don't see any SO_LINGER, except some comments in apache2
 source code, even you want to enable it by configure option. can you
 bring me to the source or document where you're told that apache2 uses
 SO_LINGER?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-12 Thread steve roussey
On 8/12/05, Brian J. France [EMAIL PROTECTED] wrote:
 Really?  We just did a around of discussion/debugging on this at work
 and I found that it uses ap_lingering_close which is like the
 lingering_close function in 1.3.

:)

Yes, it does do ap_lingering_close, and it sets SO_LINGER. I have no
idea why they do both, I only assume they know what they are doing and
it works out for the best. I have my ideas, but they are just
postulates... I'm surprised it is an ap call and not an apr call, but
I am not a web server programmer!

  o Lingerd caused my apache setup to crash. It was worth a try if it
  didn't take much effort, but not worth fixing.
 
 Are people really finding that they need lingerd?
 
 For 1.3 we have keepalive off and build with NO_LINGCLOSE, which means
 be blast the data to the kernel buffer (set large) close the socket and
 move on.  We have been doing this for at least 3+ years and I have
 never heard any complaints and we server a lot of requests/client (I am
 tied with Rasmus).

I should give that a test. But the value to me would be temporary,
since I want to move to Keep-Alive under the same hardware layout.

-steve--

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-12 Thread Brian J. France


On Aug 12, 2005, at 10:52 AM, steve roussey wrote:

On 8/12/05, Brian J. France [EMAIL PROTECTED] wrote:

Really?  We just did a around of discussion/debugging on this at work
and I found that it uses ap_lingering_close which is like the
lingering_close function in 1.3.


:)

Yes, it does do ap_lingering_close, and it sets SO_LINGER. I have no
idea why they do both, I only assume they know what they are doing and
it works out for the best.


I see the code for SO_LINGER in apr_socket_opt_set, but I don't see any 
place in the server code that calls apr_socket_opt_set with 
APR_SO_LINGER.


Running gdb I see APR_SO_KEEPALIVE, APR_SO_REUSEADDR and 
APR_TCP_NODELAY passed to apr_socket_opt_set but not APR_SO_LINGER.


(This is based on the svn of httpd with no changes)


 I'm surprised it is an ap call and not an apr call, but
I am not a web server programmer!


I agree, it took me a while to find the call again because I keep 
searching for apr_.


Brian

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-12 Thread steve roussey
On 8/12/05, Brian J. France [EMAIL PROTECTED] wrote:
 I see the code for SO_LINGER in apr_socket_opt_set, but I don't see any
 place in the server code that calls apr_socket_opt_set with
 APR_SO_LINGER.

I stand corrected. I should have used gdb and tested that before I
posted. So they put code in there to set it, but they don't have way
to reach it. A grep APR_SO_LINGER -rI httpd-2.1.6-alpha shows that
it is not mentioned much and looking through again this morning when
fresh, it never as a change to get to apr_socket_opt_set. So, I guess,
Apache2 has even less support for SO_LINGER than Apache1. Can't even
set a define in configure, must hack the code. Anyhow, sorry about the
incorect information.

I learned a lot through this thread and would like to thank everyone
for their thoughts, information, and ideas. I'll return next week with
some stats on FastCGI (various) vs mod_php.

-steve--

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-11 Thread steve roussey
Just a couple last notes on lingering: 

o Apache 2+ uses SO_LINGER by default if it defined for that system.
Apache 1 will only use it if you define USE_SO_LINGER (I suppose in
configure). Apache2 has all sorts of stuff in the comments of the code
and in the manual which is just wrong. Its all from Apache1 and does
not reflect on Apache2's implementation. I wish they just erased it
instead.

o As far as I can tell, current Linux will block until all data is
sent, then return (doing the actual closing part in the background)
with SO_LINGER.

o Lingerd caused my apache setup to crash. It was worth a try if it
didn't take much effort, but not worth fixing.

 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.

This actually sounds like an argument for NOT using mod_php. It sounds
like an argument for using Apache2 or lighttpd or xyz in conjection
with FastCGI. (Or a proxy arangement, which I've done, though in my
personal case, I like to get the same scaling with less machines since
I have to buy the machines). In that case, the webserver can be made
lightweight (not sure how lightweight Apache2 can be, but who knows?)
handling many open connections. Then there is a (much) smaller number
of heavy PHP processes in FastCGI.

I'm going to put a test together next week and have Apache1/mod_php,
Apache2/worker (not event)/FastCGI, and lighttpd/FastCGI run head to
head and see what happens. Maybe I'll even try with KeepAlive too
(though not with Apache1/mod_php since I already know that won't
work). I'll post my results back here if anyone is interested.

Andreas -- can you email me off list? I wouldn't mind some help
setting up lighttpd/FastCGI. Thanks!

-steve--

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-11 Thread Andi Gutmans

Hi Steve,

Will be interested to see your results. As I mentioned earlier, I believe 
you'll find FastCGI quite convenient in your case.


Andi

At 05:48 PM 8/11/2005 -0700, steve roussey wrote:

Just a couple last notes on lingering:

o Apache 2+ uses SO_LINGER by default if it defined for that system.
Apache 1 will only use it if you define USE_SO_LINGER (I suppose in
configure). Apache2 has all sorts of stuff in the comments of the code
and in the manual which is just wrong. Its all from Apache1 and does
not reflect on Apache2's implementation. I wish they just erased it
instead.

o As far as I can tell, current Linux will block until all data is
sent, then return (doing the actual closing part in the background)
with SO_LINGER.

o Lingerd caused my apache setup to crash. It was worth a try if it
didn't take much effort, but not worth fixing.

 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.

This actually sounds like an argument for NOT using mod_php. It sounds
like an argument for using Apache2 or lighttpd or xyz in conjection
with FastCGI. (Or a proxy arangement, which I've done, though in my
personal case, I like to get the same scaling with less machines since
I have to buy the machines). In that case, the webserver can be made
lightweight (not sure how lightweight Apache2 can be, but who knows?)
handling many open connections. Then there is a (much) smaller number
of heavy PHP processes in FastCGI.

I'm going to put a test together next week and have Apache1/mod_php,
Apache2/worker (not event)/FastCGI, and lighttpd/FastCGI run head to
head and see what happens. Maybe I'll even try with KeepAlive too
(though not with Apache1/mod_php since I already know that won't
work). I'll post my results back here if anyone is interested.

Andreas -- can you email me off list? I wouldn't mind some help
setting up lighttpd/FastCGI. Thanks!

-steve--

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-11 Thread Rasmus Lerdorf
steve roussey wrote:
 This actually sounds like an argument for NOT using mod_php. It sounds
 like an argument for using Apache2 or lighttpd or xyz in conjection
 with FastCGI. (Or a proxy arangement, which I've done, though in my
 personal case, I like to get the same scaling with less machines since
 I have to buy the machines). In that case, the webserver can be made
 lightweight (not sure how lightweight Apache2 can be, but who knows?)
 handling many open connections. Then there is a (much) smaller number
 of heavy PHP processes in FastCGI.

Well, I am not sure about your conclusion there.  Generally you don't
want trivial requests going through the heavyweight Apache process, so
you can either try to make Apache less heavyweight and separate out the
dynamic stuff which is what you are suggesting, or you can separate out
the trivial requests.  The large players do the latter by Akamizing all
their static content or the trivially dynamic stuff and only handle
heavy requests on their own servers.  For smaller players the common
solution is to have a separate set of servers doing static requests.
thttpd, Tux, lighttpd, etc. which are easier to strip down than the
heavier (and more flexible) Apache server.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-11 Thread steve roussey
Yes, thanks! Hopefully by next week I'll have learned how to set
FastCGI up securely and with a php opcode accelerator active. Then
I'll give it some time and return with results.

On 8/11/05, Andi Gutmans [EMAIL PROTECTED] wrote:
 Hi Steve,
 
 Will be interested to see your results. As I mentioned earlier, I believe
 you'll find FastCGI quite convenient in your case.
 
 Andi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-11 Thread steve roussey
Yes, you are quite correct in that a very large site (Yahoo, Google,
etc) will use a caching ISP (aka Akami). In fact, I imagine that it
would be a completely separate domain name so there would be no
cookies and everyone down the chain can easily cache the content as
well. Doesn't work for all object content (great for images) since JS
for example might loose its ability to set cookies.

I'm not really considering these things anyhow, since 99% of what I
work with is access controlled or could be at a moments notice. It all
needs to be logged as well, down to the things like images.

So I'm really just looking at dynamic requests. It bears noting that
usually a set of servers serving static content could use KeepAlive
and the dynamic ones not, and a lot of this discussion is meaningless.
But, if you are say, Google Maps, and doing AJAX type stuff (or
chat, if only more browsers supported multipart responses from your
XMLHttpRequest object) then the situation changes -- you need the
Keep-Alive connections for all your dynamic connections too. And now
I'm back at the beginning of the thread.

I have my doubts about stripping Apache2 down to something
'lightweight'. I have my own thoughts on how that project was
engineered. But there is nothing like a SmackDown to see where the
cookies crumble.

Thanks!

-steve--


On 8/11/05, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
 Well, I am not sure about your conclusion there.  Generally you don't
 want trivial requests going through the heavyweight Apache process, so
 you can either try to make Apache less heavyweight and separate out the
 dynamic stuff which is what you are suggesting, or you can separate out
 the trivial requests.  The large players do the latter by Akamizing all
 their static content or the trivially dynamic stuff and only handle
 heavy requests on their own servers.  For smaller players the common
 solution is to have a separate set of servers doing static requests.
 thttpd, Tux, lighttpd, etc. which are easier to strip down than the
 heavier (and more flexible) Apache server.
 
 -Rasmus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-11 Thread Xuefer
On 8/12/05, steve roussey [EMAIL PROTECTED] wrote:
 Just a couple last notes on lingering:
 
 o Apache 2+ uses SO_LINGER by default if it defined for that system.
 Apache 1 will only use it if you define USE_SO_LINGER (I suppose in
 configure). Apache2 has all sorts of stuff in the comments of the code
 and in the manual which is just wrong. Its all from Apache1 and does
 not reflect on Apache2's implementation. I wish they just erased it
 instead.
sorry, but i don't see any SO_LINGER, except some comments in apache2
source code, even you want to enable it by configure option. can you
bring me to the source or document where you're told that apache2 uses
SO_LINGER?
 
 o As far as I can tell, current Linux will block until all data is
 sent, then return (doing the actual closing part in the background)
 with SO_LINGER.
 
 o Lingerd caused my apache setup to crash. It was worth a try if it
 didn't take much effort, but not worth fixing.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-10 Thread Andi Gutmans

Yep and it works great.

At 07:34 AM 8/10/2005 +0200, Sebastian Bergmann wrote:

steve roussey schrieb:
 I'm assuming that the 4.3.0 Release Announcement that FastCGI
 was removed is bogus or reversed.

 It was merged into the CGI SAPI module.

--
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-09 Thread Rasmus Lerdorf
steve roussey wrote:
 On 8/9/05, Andreas Korthaus [EMAIL PROTECTED] wrote:
 
By using lighttpd with fastcgi we seperate the webserver process from
php processes (which could even work on other machines)...
 
 
 Someone else emailed me about using FastCGI with Apache 2.1/event but
 I just figured that there would be a significant slowdown using
 FastCGI rather than a module/handler. (Currently I compile PHP into
 Apache statically and turn off Apache's dynamic module loading ability
 -- something I couldn't figure out in Apache2). What is your
 experience with FastCGI?

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.

 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.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-09 Thread Andi Gutmans

Hi Steve,

From my experiences, FastCGI performance is comparable to mod_php.

Andi

At 02:24 PM 8/9/2005 -0700, steve roussey wrote:

On 8/9/05, Andreas Korthaus [EMAIL PROTECTED] wrote:
 By using lighttpd with fastcgi we seperate the webserver process from
 php processes (which could even work on other machines)...

Someone else emailed me about using FastCGI with Apache 2.1/event but
I just figured that there would be a significant slowdown using
FastCGI rather than a module/handler. (Currently I compile PHP into
Apache statically and turn off Apache's dynamic module loading ability
-- something I couldn't figure out in Apache2). What is your
experience with FastCGI?

 For simple dynamic requests we can use mod_cml

Sadly, this won't work with any system I manage since we do a lot of
stat reporting, even on a per user basis. And we need to have PHP
loaded to know the user, etc...

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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-09 Thread steve roussey
That is great to know. In that case, I won't worry about threading
again. I'm assuming that the 4.3.0 Release Announcement that FastCGI
was removed is bogus or reversed.

Unfortunately my source for mysql connection pooling was never
upgraded to support 4.1's APIs. If anyone knows one, pass it by me. :)

Thanks!

On 8/9/05, Andi Gutmans [EMAIL PROTECTED] wrote:
 Hi Steve,
 
  From my experiences, FastCGI performance is comparable to mod_php.
 
 Andi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-09 Thread steve roussey
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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-09 Thread Rasmus Lerdorf
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



Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help

2005-08-09 Thread Sebastian Bergmann
steve roussey schrieb:
 I'm assuming that the 4.3.0 Release Announcement that FastCGI
 was removed is bogus or reversed.

 It was merged into the CGI SAPI module.

-- 
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php