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

alex@atlassian.com