From The Atlassian Developer Blog:
You appear to be running Tomcat in development mode.
(http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html)
This means that source of every JSP is held in memory to provide
detailed messages in the event of an error. If you have large JSPs
this will hurt. It looks like this accounts for 50MB+
From Tomcat's Production Configuration documentation:
The main JSP optimization which can be done is precompilation of JSPs. However,
this might not be possible (for example, when using the jsp-property-group feature)
or practical, in which case the configuration of the Jasper servlet becomes critical.
When using Jasper 2 in a production Tomcat server you should consider
making the following changes from the default configuration.
- development - To disable on access checks for JSP
pages compilation set this to
false.
- genStringAsCharArray - To generate slightly more efficient
char arrays, set this to
true.
- modificationTestInterval - If development has to be set to
true for any reason (such as dynamic generation of JSPs), setting
this to a high value will improve performance a lot.
- trimSpaces - To remove useless bytes from the response,
set this to
true.
Seems like good information to know.
Granted, this post about how painful JSF is is almost 6 months old, but I think it's still mostly true.
Want to compare times? More than three man-weeks have been spent fixing silly JSF navigation problems. A full CRUD AJAX interface with Spring MVC and prototype in the same project took four days, and there was no previous experience with Spring MVC.
If you're going to use JSF, I highly recommend Facelets or Shale/Seam. However, those are mentioned as well:
The default view technology is JSP, even when no one in the real world would recommend it; instead, use Facelets, or Clay, or some other non-standard framework. Not trying to be sarcastic here, since Facelets is pretty good, but this complicates the hiring and education of the team and in fact invalidates the selling point of Faces 'being a standard'.
IMO, Facelets is very easy to learn. If you know how to program JSPs with JSF, you should be able to use Facelets in under an hour. When we converted AppFuse's JSF flavor from JSP to Facelets, rarely did the body have to change - we just had to change from taglibs to XML namespaces.
When you are not working with persistent data (if you are living in a cave or developing wizard interfaces) there are two scopes to store model state: the session context, which raises concurrency issues and is not recommended by the Faces community, and the conversation/process/whatever context, which is not standard and imply installing shale or seam to put even more lipstick on the pig.
There's two problems with Shale and Facelets - the activity on these projects is very low. Shale still has its creators around, so even while its seldom used, you can probably still get your questions answered. However, Facelets seems to be suffering from "developer abandonment".
Conclusion: don't use JSF simply because it's a "standard". Use other frameworks that are more actively developed and designed for the web. For component-based frameworks, the most popular are Tapestry and Wicket. Less popular ones are RIFE and Click.
If you still want to use JSF, you should probably use Seam, but don't simply use JSF because it's a standard. If it was a de-facto standard, that'd be another story.
Of course, you could also help improve JSF 2.0. But that's not scheduled for release until late 2008. I'm sure 2 or 3 commentors will claim we'll all be using Rails or Grails by then. 
