Everyone likes fast things
Alex Hennecke
Senior Java Dev
GreenHopper JIRA Plugin
JIRA Plugin Performance Tuning
Why tune a plugin?
Server Side Profiling
Client Side Profiling
Performance Pitfalls
Why tune a plugin?JIRA is optimised for own use cases
Plugins may do crazy, unexpected things with JIRA's data
Slow applications suck
Server Side Profilingallows you to...
find long-running code
find code waiting for locks
but...
profiling can have deceptive overhead
depends on external factors like GC, I/O, ...
JIRA and JProfileradd profile option to catalina.sh
watch the console for when to connect the profiler
JProfiler CPU View
identify long-running call
see the chain of calls that leads to slow methods
Profiling under LoadKeep an eye on memory usage and GC times
jconsole
Profiling under LoadWatch for pool size limits
server.xml
Wrap-Up
Setting up JIRA for Profiling is not hard
Profiling saves time pinning down performance problems
Client Side Profilingwhy?
rich UIs are heavy on JavaScript
JS frameworks can hide performance traps
allows to...
identify reasons for slow page load
find performance hotspots in JavaScript
JIRA and dynaTraceinstall a VM with Windows and target IE Version
install dynaTrace AJAX Edition
login and remember-me to JIRA from IE
add the URL you're testing to dynaTrace
Profiling Result - Overview
JavaScript Details
identify hotspots
script callstack
script source
Wrap-Up
Use client side profiling as a starting point
Tune JavaScript and page load time
Performance PitfallsJQLs vs HitCollector: Example from GreenHopper for a 50% gain
Dangerous convenience: CSS selectors in IE
JQL vs HitCollectorFor statistics, both use Lucene
LuceneSearchProvider.searchCount is faster for few queries
Single search with a HitCollector is faster than many JQL queries
Why is that?Creating a JQL query does permission checking
HitCollectorJIRA offers DocumentHitCollector
HitCollectorDocumentHitCollector has to load the document from Lucene, not just count the index
Custom logic is required to do the actual counting
But it still beats many JQL queries
GreenHopper 5.0
Statistics performance on the server increased by 50%
CSS Selector in IEIE has no native way to find nodes by class
Attribute selectors or selectors with wildcards have to walk the DOM tree
Prototype's extension mechanism is slow on IE
Bad examples
$('.myCssClass')
$('div[class*=myCssClass]')
$('div#myId')
Good examples
$('#myId div.myCssClass')
$('#myId div[class*=myCssClass]')
$('#myId')
Prototype CSS Selector in IETimeline view in the profiler
slow method
Prototype CSS Selector callsprototype element
extension
prototype CSSselector
CSS Selector after tuningModified Prototype with switch for element extension
hotspot is gone
There's a lot moreCache data that's expensive to fetch
Use Web Resources, they give you
no cache expiry (no more 304's)
batched mode (less requests)
Further Readinghttp://confluence.atlassian.com/display/ATL/Alex+Hennecke
JIRA Web Resource
http://confluence.atlassian.com/display/JIRA/Web+Resource+Plugin+Module
jQuery Performance Rules
http://www.artzstudio.com/2009/04/jquery-performance-rules/
dynaTrace Application Performance Almanac
http://blog.dynatrace.com/2010/01/12/dynatrace-application-performance-almanach-2010/
Kirk Pepperdine
http://www.javaperformancetuning.com/
Performance is King