Performance of JIRA 3.13 compared to 4.4

[Dieter]

Has anyone done load or user experience tests to compare the performance of both versions on the same hardware and can share his results here?

[AlexH · Accepted solution]

Hi Dieter,

I didn't take the time to apache benchmark the changes, so I can't give you any hard numbers, but I can give you some good impressions. We didn't perform any database or app server changes, this was purely a software upgrade.

I migrated our site with ~290k issues, ~5000 users (only 2200 active) from JIRA 3.13.5 to JIRA 4.4.4 on Jan 30th 2012. I performed the upgrade in two steps over a 24 hour period of time.

1) 3.13.5 -> 4.0.2
2) 4.0.2 -> 4.4.4 (There were a lot of builds that required a full reindex so going all the way to 4.4.4 meant the upgrade tasks performed a full reindex nearly a dozen times. With 290k issues our site requires about 45 minutes to reindex.)

Overall JIRA 4.4 is MUCH faster at pretty much everything, but it also requires a LOT more memory. We went from running great with 2048m (32 bit java) to needing 6144m (64 bit java) before JIRA 4 stablized. We use a few settings to keep speeds reasonable for both 3.13 and 4.4

1) Our jira indexes are stored in a tmpfs file system.
2) We limit the maximum size of excel/xml exports to ~1000 issues.
3) Increased index lock timeout to 60000ms

GreenHopper (previously 3.8 -> now 5.7) performance is a bit of a mixed bag. GreenHopper 5.7 seems to be far more database dependent now than than the old version. GreenHopper takes much longer to load a project view but once loaded it stores all the calculated values in a cache so the view is very fast until GreenHopper decides it needs to refresh the cache. I've increased the default GreenHopper cache size to 100k issues. Sometimes loading a project view takes a full 5 minutes -- but again, once loaded it's very snappy.

Because of the heavy database activity for GreenHopper we're looking at a database server upgrade.

One of the biggest pains of the upgrade has been the new user management. You already helped me on one of our issues (thanks btw!): https://answers.atlassian.com/questions/36840/jira-user-picker-broken, another one is the issue with null users in LDAP: https://answers.atlassian.com/questions/28706/managing-expired-ldap-users-with-jira-embedded-crowd

If you have any specific questions I'd be happy to share what we've learned.

[AlexH]

We actually downgraded from java-1_6_0_29 to java-1_6_0_25 because I had to make a very hasty upgrade to a 64 bit version of java and _25 was the most recent I had built in 64 bit flavor.

[Dieter]

Thanks a lot, Alex. very helpful :)

[J. Caldwell]

I'm going to speculate that most folks probably won't be able to give you a solid answer. When I do version upgrades, I also tend to do Java and/or DB, hardware, etc. upgrades at the same time. Changing Java version can improve performance by itself.

I can't say to 4.4, but going to 3.13 to 4.1.2 was about a 3 fold increase in spead on the same hardware. The only other change was the JDK, which went from 1.5 to 1.6. Users were significantly happier with performance of the system, although it was a big jump that broke some folks brains.