first lesson of portal architecture

the first thing that struck me: Edge Components Caching Proxy (CP) is so ignored into our customers solutions, here in .ro

Even when looking and searching for resources world-wide I seem to have a hard time finding any good resources of people trying stuff and sharing with community ...

I am not into the sales/licensing stuff, but I think that any license of WebSphere Portal comes with entitlement to install/use the Caching Proxy.

So, why do I see so ignorance for this product which actually enhance the Portal performance ? How did I see this ? On my own experience, and here's how I saw it:
On my laptop (with 3GB RAM, well..) I installed two Linux virtual machines:
- one has Portal 6.1.0.3
- the other one has IBM HTTP Server with WAS plugin, plus the Edge Caching Proxy. IHS responds on 8080, CP responds on 80 and forward all traffic to IHS.

After I finished the setup (it took me a long time due to other stuff I am dealing with), I noticed a boost in Portal performance when accessed through the Caching Proxy. I mean, the performance is crystal clear visible when accessing: http://my_host_name:8080/wps/portal (without CP), versus http://my_host_name:80/wps/portal (with CP)

And, by no means I am an expert into Caching Proxy stuff, not just yet.
Sure, Portal has several layers of caching, out of which DynaCache is/can/should be used programatically by developers, but usually developers don't bother with it. Or, our developers here in .ro don't bother ...

So, when architectural decisions are in my hand, I am not going without a CP, set-up and used as a reverse proxy for the Portal. I think it should be installed whenever you get the chance, it finally looks good for the Portal solution itself.

more details to come, as I will learn more :)