We are so immersed with content management systems that we have forgot the simple static HTML pages power.
The static pages have the ability to save us CPU cycles and cost of hardware and even energy.
We all know their downturn that it takes expertise to fabricate them.
But is it that difficult?
Some of the current CMS systems sallow you to generate static files out of your templates and serve them on a web server and not the applications server to save on CPU cycles.
Vignette my employer have a product called HPD that auto generates sections of the template as HTML and serves those instead of the content regions been dynamically generated. The HPD also regenerates those sections if the content has changed.
We have content sections in website that change so infrequently that serving them from the application server is a crime, i will name a few:

• About us
• Meet the team
• location/contact details
• etc…

These are wonderful candidates of joining the 404 and becoming a static page on the web server.
The simplest solution to achieve that is to go to the page and save it as it is generated from your content management system.
Then put the page on the web server file system and configure the web server to get this page instead of the one from the Content Management system when the URL matches.
This is probably true to non php systems and more to java .net CMS.
In php you need to configure the same server to serve an HTML file and not your php code.
i took on a few assumptions that you have all your static assets (images, javascript, css etc) served from the web server and not your content management, if you are using the content management to serve those you need to first solve that problem and not the static content.

I have started a small implementation of the Vimeo API in java project on SourceForge.
Its going to be a challenge that i will enjoy.
I like Vimeo over the youtubes due to the cooler guys that have created it like its founder Jakob Lodwick.
Hope you can join in.

I love the idea of Liferay portal, its a self sustaining portal and content management system that comes with many applications out of the box that enable you to shape your site as you wish without seeking a third party applications or plug-ins. The portal supports the JSR 168 and 286 for portlet development allowing you to develop a very elaborate applications on top of it with the power of Java, Spring, Hibernate, EJB, JSF and more.
The position of this Portal as of all portals is more in the mid-size business more then the personal site developer.
But with this positioning comes some software design and architecture responsibilities.
The portal should be able to cluster easily and be able to give better performance using caching.
The good news is that although clustering is not a simple switch in the configuration it is not allot more complex then a configuration of the web server, cache and Liferay. caching is also OOTB and has the benefits of the Hibernate.
Having this is very good and very reassuring for the business that sets its eyes on establishing a portal as their website.
The other great feature in the portal is the CMS based on the popular Journal portlet. though it is not a really great and flexible CMS with many of an enterprise CMS features it does get the job with simple content like Articles and so on. Dont expect to get the Vignette Content Management server out of it.
I do have some problems with the portal, especially GUI design and the separation of interfaces.
My first trouble started with the lack of a backend administrative application. i am used to this type of mechanism in most of my web applications including the WordPress i am using now. the separation of preview and management is some thing i find very important for applications.
For an example i would bring the page template management. though i have chosen a very arguable example i believe that this should be a part of the navigation tree and it should be possible to make a selection of several pages and change their templates collectively.

But this is not the end of the problems with the lack of administrative application, the administration is done by pages in the system that make it very elaborate to make it clear what is user controlled and what is administrative.
Now i have not gone beyond the simple install and have not tried to integrate it with any LDAP for users and groups or any other integration to Caching mechanisms but it appears that there is some community out there that will be happy to try and help and you might be able to archive your goal.
So if your company is in the route to get a portal and you want to go the open source way you probably should consider Liferay Portal. if you want an enterprise portal Come to Vignette.

This is a lesson learned from yesterdays fun at the Data center.
The IBM Http server and probably the Apache web server are sensitive to memory of the operating system regardless of the memory allocated to them.
We have been experiencing a problematic behavior from our webservers. they were slowing the application response time by 15-20 seconds and were generally running on high CPU cycles.
The system they were running on had 1Gb of memory allocated to it and we were sure this was sufficient since the JVM of the webserver was around 256Mb.
At some point we noticed a big amount of page faults on the Apache process and decided to get the memory increased.
We had installed on our servers 4Gb memory chips instead of the 1Gb and restarted the servers.
Accidentally we had hit the server prior to resetting its memory allocation and we were surprised that the response was less then a second.
Getting this response made us really happy and we decided to leave the memory as is and let it run that way.
Appearance there is an issue with the OS and the JVM stepping on each other heals in the Processing area and not the JVM area thus creating a slower processing from the Http server.
So next time you have a webserver with performance issues you might consider just putting some memory chips in it and see what it does.