Hello David, Are those changes also in post-2.1.2? You mentioned some in the past. The preload feature doesn't seem to be there thou. Are you still updating the post-2.1.2?
Thank you. ---Yang -----Original Message----- From: David Sean Taylor [mailto:[email protected]] Sent: Tuesday, December 16, 2008 1:47 PM To: Jetspeed Users List Subject: Re: Jetspeed performance issue with portlet preferences On Dec 16, 2008, at 8:58 AM, Dutertry, Nicolas wrote: > Hi, > > We are facing a serious performance issue with Jetspeed (version > 2.1.3). > > Our web application, based on jetspeed, contains portlets using > portlet > preferences. When several users connect to the application at the same > time (60 users or more), it seems that access to portlet preferences > highly slow down the application. We discovered that threads are > blocked > on access to preferences. > Here is a part of the stack trace where threads are blocked : > java.utils.prefs.AbstractPreferences.node(String) > > org > .apache.jetspeed.components.portletentity.portletEntityImpl.getPrefer > enceSet(Principal) > > org > .apache.jetspeed.components.portletentity.portletEntityImpl.getPrefer > enceSet() > > org.apache.pluto.core.impl.PortletPreferencesImpl.<init>(Integer, > PortletEntity) > > org > .apache.pluto.factory.PortletObjectAccess.getPortletPreferences(Integ > er, PortletEntity) > org.apache.pluto.core.impl.RenderRequestImpl.getPreferences() > com.hraccess.portlet.NewsPortlet.doView(RenderRequest, > RenderResponse) > ... > > Do you know any workaround to solve this problem ? > Just to make sure, you are using the 2.1.3 final release, right? A few things to check: 1. make sure you have applied the prefs.xml indexes described here (Migrating from 2.1.2 - 2.1.3): http://portals.apache.org/jetspeed-2/guides/guide-migration.html PREFS_NODE IX_PREFS_NODE_1 non unique PARENT_NODE_ID PREFS_NODE IX_PREFS_NODE_2 non unique FULL_PATH PREFS_PROPERTY_VALUE IX_FKPPV_1 non unique NODE_ID Make sure you have a index on the FULL_PATH, not having that index can drastically degrade performance 2. There was a preference preload feature added to the 2.1.3 post release. Preloading will slow down startup time, but can really improve retrieval time at runtime See the prefs.xml, 2nd and 3rd constructors, you can preload default preferences per portlet application, and/or all entity preferences. Careful with this if you have lots of preferences <!-- Preferences Implementation --> <bean id="PreferencesProviderImpl" class ="org.apache.jetspeed.prefs.impl.PersistenceBrokerPreferencesProvider" name="prefsPersistenceBroker" init-method="init"> <constructor-arg index="0"> <value>JETSPEED-INF/ojb/prefs_repository.xml</value> </constructor-arg> <constructor-arg index="1"> <ref bean="preferencesCache" /> </constructor-arg> <!-- list of portlet applications default preferences to preload, leave list empty to not preload --> <constructor-arg index='2'> <list> <value>j2-admin</value> </list> </constructor-arg> <!-- preload ALL Entities: warning this can chew up lots of memory --> <constructor-arg index='3'><value type="boolean">false</ value></constructor-arg> </bean> Then make sure to adjust your ehcache.xml for the preferences cache: <cache name="preferencesCache" maxElementsInMemory="10000" maxElementsOnDisk="1000" eternal="false" overflowToDisk="false" timeToIdleSeconds="28800" timeToLiveSeconds="28800" memoryStoreEvictionPolicy="LFU"> </cache> 3. Another addition to the 2.1.3 post release, the preference retrieval algorithm was improved, see https://issues.apache.org/jira/browse/JS2-886 4. You can moving your default preferences to PSML preferences, see http://issues.apache.org/jira/browse/JS2-786 Recommend doing this as lowest priority NOTE: for the 2.2 release, preferences will be stored in a different database format. We have dropped the Java Preferences impl in favor of a more performant solution --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
