A common problem that customer's often face is having a large Portal cluster in one part of the world, but having to access it from another. Because of the large number of "GET" requests needed to render a Portal page along with the latency of transcontenental access, performance typically suffers.
A typicaly Portal topology might look like this:
Client browser <-> WebServer <-> Portal Server
To improve the performance, a user can change the topology to this:
Client browser (in EMEA, for example) <-> WebServer (in EMEA) <-> Web Server (in USA) <-> Portal Cluster (co-located in USA)
In addition, the WebServer in EMEA would impliment a caching proxy as a part of the reverse proxy cache. So, the client brower would access the site via the EMEA WebServer. That EMEA webserver would serve content from it's local cache as able. If the content is not in the local cache, it would forward the request to the USA WebServer. Note that this would always happen for the base Portal page as well as any statics not already in the EMEA cache.
Instead of using the address of the server(s) in the USA, the EMEA customer would now request the page via the hostname of the EMEA WebServer. Something like this:
http://host.usa.com/wps/portal becomes http://host.emea.com/wps/portal
Users could either use the new hostname (as immediately above), or the DNS server in their geography could return the EMEA webserver instead of the USA version of it. The later would make this local proxy server strategy transparent to the user.
The EMEA Apache web server would use this in it's httpd.conf to proxy the request to the USA webserver:
ProxyPass /wps/ http://host.usa.com/wps/
RequestHeader unset Accept-Encoding
Note also that the EMEA web server would also use mod_disk_cache for the local caching of static content.