This session from the IBM Exceptional Web Experience is on portal performance tuning techniques. It is hosted by Hunter Presnall and Denny Pichardo of IBM. This particular post does not summarize the entire session but instead focuses on key points and topics that resonate with what I’ve seen happen in the field with customers and performance challenges and solutions.
Performance Benchmarking Best Practice
Goals must be defined to measure success. It isn’t possible to measure performance unless there is a point of reference and a goal. Examples are:
- Throughput, e.g. pages per second
- Response time under a given load
Another one is that performance testing is an iterative process. When a performance test is run and a bottleneck is found, fix it and find the next one until the goals are met or exceeded.
Regarding the benchmark, here are a few best practice:
- Measure the right thing – Use real world scenarios
- Measure things right – Use relaistic ramp up, login rates, valid think times, etc.
- Measure for enough time – A 1000 user test for 10 minutes may not yield the same results as running for a day
Avoid invalid performance benchmarks. Below are examples:
- Running all simulations with one or very few users
- Using invalid data, e.g. no backing data in a database or connected system
- Unrealistic read write to read percentages – most real world workloads are < 5% writing
- Running on hardware or a configuration drastically different than production
Server Side vs Client Side
Web 2.0 applications have a significant client side component. Load simulators cannot simulate CPU consumption on a client browser or devise, they request and respond to HTTP requests. Response time from a load simulator may not actually be what an end user gets.
Smaller is Faster
Keeping everything possible smaller will generally yield better performance across the board. This especially includes:
- Sessions – fewer sessions = less memory -= faster replication
- Pages – Fewer pages visible to a user = better performance
- Portlets – keep the number smaller on a page when possible, preferably less than 8
- Themes & Skins – keep them lean. These impact every single page view in portal
- Optimize the home page – This gets hit the most, cache anything and everything possible
- Theme changes in 7.0.0.2 are much more efficient, modular and easier to change
- Significant client side improvements are available
- There are some server side benefits
Use the New Portal Theme
- Theme changes in 7.0.0.2 are much more efficient, modular and easier to change
- Significant client side improvements are available
- There are some server side benefits
It’s not just portal you need to worry about
Portal is usually blamed for “being down” or performing poorly when connected systems are often the cause. Don’t forget about:
- LDAP and SSO Infrastructure
- Web server
- Caching proxy
- Load balancers
- Connected services
Tuning Checklist
These tend to be some checklist items that should be looked at when performance tuning
- JVM – Heap, Gencon, 32 vs 64 bit
- Threads
- Caches
- Rendering Mode
- Portlet Complexity
- Theme Profiles
- Hardware
Common WCM Tuning
Web Content Management is a big opportunity for performance bottlenecks or performance tuning. Here are some concepts to remember:
- WCM needs same tuning as portal
- Tune the JCR Database
- Use as much memory as you can
- Runstats & reorg to the database after content population
- Mange old content
- History cropper to remove old versions
- Member Fixer to remove old users
- Use Pre-rendering when possible
- Portlet fragment caching or WCM basic caching bring huge benefits when possible
- Cache on a proxy server – not just for WCM
- Authoring
- Disable versioning if not required
- Reduce number of fields on authoring templates
- Minimize access control records in database by using inheritance
Performance tuning is critical to any portal implementation. If the portal performs slow, that will quickly become your number one complaint for your users.
