Learn how Autodesk broke the 300,000 issues barrier without impacting performance, keeping excellent uptime, with more than 3000 registered users and average of 1800 concurrent users. In this session you will discover the hardware architecture, system settings and other interesting data from Autodesk experience in the field.

2. JIRA Performance
after 300,000 issues"
Claudio Ricardo Ombrella!
Senior Technology Architect – Autodesk Development Sàrl – Neuchâtel - Switzerland"
http://www.linkedin.com/pub/claudio-ombrella/0/919/17a

4. Agenda"
• Let’s Get to Know Each Other"
• JIRA at Autodesk"
• JIRA Status and Audit"
• Changes We Implemented and Their Results"
• Process – the Rules of “P”"
• Conclusions "
• Questions and Answers"

5. Do you know Autodesk?"

6. Probably you
know AutoCAD "

7. Autodesk in a Nutshell "
• Founded in 1982" • Revenue: 2.22 billion FY12"
• 6800+ employees" • Markets:"
• 90 products in 18 languages" • Architecture, Engineering,
Environment, Computer Science,
• 16 films Academy Award" Computer Graphics and
Animations"
• 10 mln professional users "
• 7 mln consumer users"

8. What about you?"

9. JIRA
Users & Issues
"

10. Windows / Linux?"

11. JIRA at Autodesk
"

12. JIRA at Autodesk "
• 2005 – “the year we made contact” – JBoss site"
• 2008 – Localization Services migrated Notes to JIRA"
• 2009 – Some projects in Global Engineering adopt JIRA"
• 2012 – 250,000 issues (Feb 8th), 300,000 issues (May 5th)"

13. JIRA at Autodesk - Statistics"
• 302,000+ issues"
• 3200+ active users"
• 384 projects (340 Agile)"

14. JIRA at Autodesk - Infrastructure"

15. JIRA Status – Mid 2011"
• JIRA 4.01 Running on Windows 2008 Server R2"
• Average uptime was 6 to 15 days"
• Could not assign more than 1248 MB to Java VM"
• Running on ESX Virtual Farm"
• Clients"
• 90% running on MSIE 8"

16. Performance Audit Plan"
Application
Client
Network
Server
PERFORMANCE
Process

17. What Did We Change?
"

18. Server"
• Migrated to Linux 64-bit 32GB RAM"
• Next three slides will explain why we made this decision"
• Virtual server running on VMWare ESX farm"
• Configured as High Priority Pool"
• 6 cores"
• Actually running version 4.4.4 and testing Beta 5.1"

19. Java Benchmark – Less is Better"

20. Java Benchmark – More is Better"

21. Java Benchmark – More is Better"

22. Client"
• Advised users to use Chrome, Firefox and Safari"
• MSIE has the slowest JavaScript engine in the market"
• Clear browser cache frequently"
• Exclude antivirus on browser cache folder"

23. Browser Performance"
Tests by Jacob Gube – Six Revisions

24. Application – 12GB RAM to Java VM"

25. Application – Activated GZIP "

26. Application – GreenHopper Cache"

27. Application – Kept MySQL Local "

28. Application – SSL Only If Needed"

29. Network"
• Configured SilverPeak for WAN acceleration"
• If you have Packteer - create a Level 5 policy"
• You can also use Riverbed for WAN acceleration"

30. Results
"

35. What About Process?
The Rule of 5 “P”
"

36. Proficiency
Proof
Proliferate
Production
Process
"
Procrastinate
Plugins

37. Proficiency"
• Build knowledge about your infrastructure"
• Audit your systems"
• Survey your users"
• Observe new technology trends"

38. Proof Production"
• Never update without testing your production data on a
staging environment"
• Involve your users in the acceptance testing"
• Go live with their consensus"

39. Plugins"
• Never install unsupported or discontinued"
• For commercial ones, have a support contract"
• Install only those that are strictly needed"
• Update plugins on staging first, then production"

40. Procrastinate"
• Do not upgrade “for the press release”"
• Proceed by steps: don’t change in one go, DB, OS,
Application. Let the changes “marinate.”"
• Avoid changes close to important deadlines: product
release, end of quarter."
• Exercise the “change freeze” option."

41. Proliferate"
• Keep users informed:"
• on upcoming system changes"
• on usage tips – best practices
(browsers, settings, etc.)"
• Newsletter"

42. RFC – Request For Change"
• Track all your changes: • Use an approval workflow"
allows you to step back in
• Deny implementation in
case of problems."
case of doubt"
• Record the testing done on
• Do maintenance outside
staging environment"
business hours"
• Document your roll-back
• Keep RFC process on
plan"
another system, not JIRA"

43. RFC – Log"

44. RFC – Log"

45. Conclusions
"

46. Managing #JIRA Performance is not all about
infrastructure. Also how you manage your enterprise
processes.
#summit12

47. Join me on Linked-in Group
JIRA Performance
http://www.linkedin.com/groups?
home=&gid=4454622&trk=anet_ug_hm "

48. Thank you!
claudio.ombrella@autodesk.com
http://www.linkedin.com/pub/claudio-ombrella/0/919/17a