Stuart.... Thanks for the notes...I am currently setting up a portal for my company and I have in the configuration stage. Are you setting your system up to use group based access (where the a new person is added to a group and security is based off the group and not assigned to the individual).
Allen -----Original Message----- From: Stuart Belden [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 11:27 AM To: [EMAIL PROTECTED] Subject: Jetspeed performance tips I've been trying to get our jetspeed based portal up to acceptable response times (< 1sec), and since the topic has come up several times on this list I thought I'd share some of what I've come up with. Additionally, I'd love to hear any corrections or additional tips you might have. :-) A quick overview of our app: We're working with 1.4b1 still, using role based psml, stored in a db. We use velocity almost exclusively. Content is grouped and organized by tabs; e.g. Home, For Staff, Employment, etc... Some of these tabs have sub-tabs. Each pane has one or more portlets associated with it. Customization is controlled by a turbine permission called PortletConfig. If you have it you can customize everything, otherwise you can customize nothing. Our main slowdown was caused by checking for this permission. For each tab, page, pane, and portlet we were checking the user for this permission using a helper function that would return a list of all a user's permissions given a username. The function was written to be a convenience, and to be used sparingly; it takes a username, retrieves all the roles associated w/ said name, and iterates through those roles, building a list of permissions. This list, once retrieved, wasn't being stored in the session or anywhere so it was being called numerous times per page. Obviously this was pretty damning. :-) My quick fix was the simply change the PortletConfig permission to a Role since only "admin" had the permission anyway. There are other solutions but this one was such a benefit it was good enough for now. Attached is a document which is basically a checklist of things to make sure are set in various .property files before moving to production. If your files are generated through ant/maven/whatever this will be of less use. If anyone notices something I have forgotten, or see something I shouldn't have changed please point it out: I'm not an expert at configuring Jetspeed by any stretch of the imagination. The jist of the file is this: Turn on module and template caching. set appropriate max # of db connections. set appropriate modification check intervals. Comment out stuff we don't use. Some of the things I recommend commenting out break some of the admin only portlets we don't use. FYI. All these apply to 1.4b1; some things may have changed since then. Cheers, stu
This message may contain proprietary or confidential company information. Any unauthorized use or disclosure is prohibited.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
