scottp at dd.com.au
Sun Feb 10 17:10:10 PST 2008
On 11/02/2008, at 11:47 AM, Ryan, Martin G wrote:
>>> Lastly, if you're definitely going to filter every page, then I hope
>>> you're using a reverse-proxy to cache the results?
>> There is no need to use a reverse-proxy to cache results from Apache.
> Is that a full stop at the end of that sentence? :-)
You misquoted a little, by cutting the rest of the email - which
coveres when to use and when not to.
> 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
> to reduce the load on apache content servers - not the load of
> 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
Remind me and I will tell you how it goes :-)
More information about the Melbourne-pm