Apache web server development

steve | 1 Mar 2007 01:24

Re: What do you think about Lighttpd?

> I use it too, and have meddled with it enough at a source level to feel
> comfortable running it. It has obvious, documented, problems (don't use
> it with mod_ssl),

I didn't make it clear earlier -- I do use the event mpm.
Successfully. What *is* the problem with mod_ssl anyway??? I have used
the two together, and I haven't seen a problem....

BTW: FastCGI is not necessary as you can use all Apache all the time:

1. Compile once Apache 2.2 with the event MPM. This is your normal web
server on port 80.

2. Compile another Apache 2.2 with the prefork MPM and mod_php. This
is your PHP server. Run it on another port.

3. Use Apache's rewrite and proxy to forward the php requests from #1
server to #2 server. It seems a little heavy, but you can eliminate
FastCGI altogether. If needed, you can also have your "PHP" server on
another machine than your "Web" server. And you can have more PHP
servers and use the proxy balancer to load balance them.

Just seems a bit heavy weight when its going on a single machine. I
don't have real numbers on how much more weight this is than using
FastCGI. Anyone know? Config would be easier though... :)

Some questions:

1. What is the issue with event mpm and mod_ssl to a end-user?
2. How much more "heavy" is the above setup than using FastCGI?

(Continue reading)

headers

Greg Ames | 1 Mar 2007 23:03

Re: What do you think about Lighttpd?

--- steve <iamstever <at> gmail.com> wrote:

> > I use it too, and have meddled with it enough at a source level to feel
> > comfortable running it. It has obvious, documented, problems (don't use
> > it with mod_ssl),
> 
> I didn't make it clear earlier -- I do use the event mpm.
> Successfully. What *is* the problem with mod_ssl anyway??? I have used
> the two together, and I haven't seen a problem....

I had something to do with the event mpm also, but I've been out of the loop on
it for some time, so the following may not be quite right.

basically mod_ssl's input filters and check_pipeline_flush() have different
views of how to tell when there is no more input data queued.  there used to be
the possibility that when a client uses HTTP pipelining (multiple requests
back-to-back without waiting for a response after each), mod_ssl could have
data stashed in its input filters for requests after the first request, and the
httpd core (check_pipeline_flush() ) wouldn't realize it and make a bad
decision.  that could result in hangs or lost input.  you are unlikely to see
this problem without pipelining enabled in a browser.

it's fixable, just a simple matter of programming...

Greg

____________________________________________________________________________________
Sucker-punch spam with award-winning protection.

(Continue reading)

headers

steve | 2 Mar 2007 02:23

Re: What do you think about Lighttpd?

Ah, OK.... so I shouldn't panic until a browser ships with pipelining
enabled by default. HTTP pipelining would be nice, as in limited
tests, it had a nice performance increase on sites with lots of little
images/css/etc.

On 3/1/07, Greg Ames <ames_greg <at> yahoo.com> wrote:
>
> --- steve <iamstever <at> gmail.com> wrote:
>
> > > I use it too, and have meddled with it enough at a source level to feel
> > > comfortable running it. It has obvious, documented, problems (don't use
> > > it with mod_ssl),
> >
> > I didn't make it clear earlier -- I do use the event mpm.
> > Successfully. What *is* the problem with mod_ssl anyway??? I have used
> > the two together, and I haven't seen a problem....
>
> I had something to do with the event mpm also, but I've been out of the loop on
> it for some time, so the following may not be quite right.
>
> basically mod_ssl's input filters and check_pipeline_flush() have different
> views of how to tell when there is no more input data queued.  there used to be
> the possibility that when a client uses HTTP pipelining (multiple requests
> back-to-back without waiting for a response after each), mod_ssl could have
> data stashed in its input filters for requests after the first request, and the
> httpd core (check_pipeline_flush() ) wouldn't realize it and make a bad
> decision.  that could result in hangs or lost input.  you are unlikely to see
> this problem without pipelining enabled in a browser.
>
> it's fixable, just a simple matter of programming...

(Continue reading)