[Melbourne-pm] Blast from the past (was Re: Apache2::Filter::RE)

[Ryan, Martin G]

Hello all,

> From: Scott Penrose [mailto:scottp at dd.com.au] 
> Sent: Monday, 11 February 2008 12:10 PM
> ... <see below>
> Remind me and I will tell you how it goes :-) 

Amazing what you find wondering around in an old MPM folder, eh? :^)
So Scott... Consider yourself reminded - i.e. "do tell"

-----Original Message-----
From: Scott Penrose [mailto:scottp at dd.com.au] 
Sent: Monday, 11 February 2008 12:10 PM
To: Ryan, Martin G
Cc: Melbourne Perlmongers
Subject: Re: [Melbourne-pm] Apache2::Filter::RE


On 11/02/2008, at 11:47 AM, Ryan, Martin G wrote:

>> There is no need to use a reverse-proxy to cache results from Apache.
>
> I presume you mean "no point using a reverse-proxy if you're thinking
> that's going to save apache from having to continually re-apply the
> filter." - yes?
>
> I've seen large sites that use commercial file caches as reverse  
> proxies
> to reduce the load on apache content servers - not the load of  
> applying
> filters and whatnot - just the load of having to actually put the
> content on the cable.
>
> Is this a sane thing to do?

It can be. A proxy is often used to increase performance in place of  
caching. This is when it should not really be done. It is a matter of  
deciding where your caching should be done: Browser, ISP/Local/Company  
Proxy, Server Proxy, Apache, Application Cache, None - all have  
reason. The great advantage of using Apache to cache is that you get  
all the advantages of Applicaiton Cache (local control to expire it  
etc). Of course ideally we provide correct headers so that the Browser  
and ISP/Local/Company proxy can cache the objects.

However. The reality is that Apache can be slow. If it wasn't we would  
not need excellent projects such as LigHTTPD.

Solutions that have been used in projects include moving static  
content across to an alternative Apache instance or even physical  
machine, or caching the entire system (proxy - what people often call  
a reverse proxy - but it i just a cache).

Another common solution to the static problem is to use a CDN - Common  
Delivery Network. Basically this is just farming off your static work  
to someone else. But - the big advantages are that those producing a  
CDN network often put effort into getting geographically (or rather  
internet-agraphical) close mirrors of the servers. So when you click  
on www.apple.com - it is faster because the static content (a large  
portion of the code - images, css, js) is on a faster link.

I have just started doing this myself, sort of. Getting hosting  
overseas is expensive - too expensive for me. This is because I have  
unusual requirements, and need to run a large number of virtual  
machines running unusual system configurations. A 512K link is not too  
expensive - much cheaper than I can get a single machine elsewhere -  
and I can now run 100s of machines. However any large content is  
really effected over such a link. So I am trying out moving static  
content (not all static, but at least the css, js and associated  
images) to an ISP - and in this case an ISP that has a cheap service,  
as now I need nothing special - just a static web server and remote  
FTP access.

Remind me and I will tell you how it goes :-)

Scott