[Mod_gzip] mod_gzip, mod_proxy and mod_ssl ( follow-up )

[Christopher L. Everett]

TOKILEY@aol.com wrote:

>Hi Christopher...
>Kevin Kiley again...
>
>I forgot to mention something that most people
>probably don't realize when it comes to using
>'redirections' in Apache such as the ones that
>allow mod_gzip to work with mod_ssl in 
>the Apache 1.x series.
>
>Even though it might LOOK like you are sending
>requests to/from different 'Servers' by configuring
>various proxies and virtual-servers... the actual
>OVERHEAD for doing so is nothing like what you
>might be imagining in your head.
>
>These 'redirections' are taking place INTERNALLY
>in the Apache code and it's nothing like actually
>SENDING request to/from different 'machines'
>or even different Servers running as separate 'tasks'
>on the same machine.
>
>There are no 're-connects' or 're-transmits' that
>need to happen for these Apache INTERNAL
>re-directs. It all happens INSTANTLY inside the
>Server itself. It just sets some flags on the
>connection/request structure(s) and JUMPS
>instantly back to certain re-entry points.
>
Hi Kevin,

I actually compiled separate mod_ssl and non-mod_ssl apaches and
I had the mod_ssl apache proxy all requests to http://127.0.0.1:8080/
where the non-mod_ssl apache was listening.

That's why I think separate processes handle each SSL request.

I forget why I decided I needed a separate mod_ssl server.  IIRC there
was some show stopper about apache name virtual servers doing SSL
in the same process with name virtual servers not doing SSL having
the same server name.

As I write, my main production server has 21 light httpd-lite processes
and 11 httpd-ssl processes, which is a minimum number (Sunday night
and all).  Perhaps I should compile httpd-ssl with mod_gzip and move
the virtual servers that I use for compression and name handling from
httpd-lite to httpd-ssl and see if anything changes.

I'd use Apache 2.0 but I'm not sure it's ready for production use yet,
what with people saying this and that about mod_ssl and mod_perl for
Apache 2.0 being so new.

>It's not actually 're-connecting' to these 'other'
>Servers or anything like what actually happens
>between 2 'Servers' on 2 different machines.
>
>The 'data' itself is also not being 're-sent' to/from
>these 'other' internal 'connections'. They can
>all see the same data buffer(s) that have 
>already 'arrived'.
>
>The whole re-direct thing is really just 'pretending'
>that these internal redirects are 'different Servers'.
>
>mod_proxy is a very special module in Apache and
>the way it 'gets' its requests is by pre-pending 
>a special 'proxy:' keyword onto the front of the
>URIs travelling through the Server. It's just a way
>for every module in the Server to 'see' that this
>is a PROXY request instead of a normal one.
>Apache is not really 'talking' to some 'other' 
>Server when mod_proxy is in use. It is still just
>'talking' to itself at the speed of light.
>
>The overhead for using these Apache INTERNAL
>re-directs inside the same Server is really
>negligible. You could re-direct a transaction
>internally through a dozen VIRTUAL hosts
>and/or mod_proxy and it still wouldn't come
>near the overhead required to just run 1 single
>CGI script to process a transaction.
>
>Just thought I would point that out if you are
>thinking that these Apache re-directs are
>chewing up CPU and/or TCP/IP resources.
>
>It's really not the case.
>
>Later...
>Kevin
>
>
>  
>