San Damiano Hall - Portal Performance

Owned by Sheri Crosby
Last updated: Oct 18, 2010Version comment
3 min read

Facilitated by Bill Brown of University of Chicago

Overview

U of C portal is rolled out to entire university community

Home page is customized for each user group.  When they log in they get a customized view

Performance lag on each initial load/log in due to externally located resources.

What are some tips and tricks that you use for your home page?

U of C uses shibboleth to authenticate there is overhead with that.

Load time is impacted due to number of portlets included on the home page.

Currently 5-10 second home page

*Is there an advantage to creating a fragement for each portlet?  *Not if the user doesn't have permission to a portlet.  If they don't have permission for a portlet then there is no overhead. At UWM, portlets are hidden from view until an employee checks the portlet to have it added.  There is no time cost associated with this.

U of C uses Oracle database.

Performance testing was conducted on the home tab

Talking with external systems IO is a killer for rendering times. Pre fetching and caching is a way to combat this (maybe an incubator portlet that can do this?)

U of C will be working with Stakeholder Committee to recommend removal or relocation of home tab portlets

What is the peak # of portlets included on a page before load time is compromised? Not an issue of performance for UWM but they add or remove portlets based on whether or not a user will use it. UWM had Unicon review the site who then recommended that 6 portlets to a page is ideal.  Less content on a tab has many benefits including no content below the fold and faster portlet rendering time.  UWM has around 70 portlets but they are not all viewable at once to any viewer.

Ideas

  • Audit home page and ensure no portlet has a time out of longer than 5 seconds
  • Remove portlets that are rendering for the user
  • Enable out of the box tool to gather Statistics for rendering time.
  • Remote fetching resource caching- cache locally on disks (eg during peak times, RSS feed is only fetched every 60 seconds, which saves 199db calls per minute)- This helps with reliability.
  • Change the default tab to only include timely and critcal information.  Include: Something that will only be there for a few days (e.g. Announcement items), How do I customize the portal? How do I find things on the portal? News portlet?
  • Weather Portlet-Check into who you are calling for data.  Accu-weather is notoriously slow.
  • Ajax can be a culprit in terms of slowness.
  • Portlets are started at the same time as all the portlets but they render asynchronously. (e.g. Portlets 1-10 may start at the same time however if portlet 2 takes 30 seconds to render, the full page won't load until that portlet is rendered.)
  • Increase the JAVA memory allocated to Tomcat (2G allocated to Tomcat manages 3K-4K log ins per day)
  • UWM portal is very dasboardesque (1-2 clicks to get where they need to go, not robust)
  • Choose the memory solution that is best suited for your primary portal type/usage needs
  • Store data in LDAP memory and not disk (2G of memory)
  • Use J Console-excellent for diagnosing and monitoring- connect the console to each node you are running individually. 
  • Watch for Garbage Collections
  • Access statistics through JAVA jmx api. Milikin has a portlet that utilizes this JMX interface.  This should be jasig incubated. 
  • Utilize database connection pooling.  There are settings on Tomcat that can be changed.