∙To paraphrase Albert Einstein, “keep teamspaces as simple as possible, but no simpler”. In implementing this, consider both the number of pages as well as the number of portlets on each page. Adding additional pages or portlets to a teamspace increases the overhead associated with that teamspace. While this is not a great overhead when considering an individual teamspace, when aggregated across thousands of teamspaces, the overhead can become significant. In addition, the more portlets are on each page, the more work will required to render that page.
∙Another area to consider regarding teamspace complexity is the number of application roles. For many teamspaces, two roles (manager and user) are adequate. Don’t create additional roles unless they are really needed.
∙When assigning membership to a teamspace, the best performance will be seen when membership is assigned by groups rather than by individual users. For example, WebSphere Portal will cache permissions based on the way permissions are assigned, giving the chance for more cache hits if permissions are assigned by groups.
∙Memory demand increases with the number of teamspaces on the system. Therefore, if you expect to use large numbers of teamspaces, a
See also the section regarding “Use of Dynamic Content Features”. Experiments in our lab showed a reduced demand for memory, and thus an improvement in capacity, in the application infrastructure scenario when disabling dynamic content support.
4 5