JIRA Performance After 300,000 Issues

5,838 views

Published on

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.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,838
On SlideShare
0
From Embeds
0
Number of Embeds
2,602
Actions
Shares
0
Downloads
40
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

JIRA Performance After 300,000 Issues

  1. 1. 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
  2. 2. 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"
  3. 3. Do you know Autodesk?"
  4. 4. Probably youknow AutoCAD "
  5. 5. 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"
  6. 6. What about you?"
  7. 7. JIRA 
Users & Issues "
  8. 8. Windows / Linux?"
  9. 9. JIRA at Autodesk "
  10. 10. 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)"
  11. 11. JIRA at Autodesk - Statistics"• 302,000+ issues"• 3200+ active users"• 384 projects (340 Agile)"
  12. 12. JIRA at Autodesk - Infrastructure"
  13. 13. 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"
  14. 14. Performance Audit Plan" Application Client Network Server PERFORMANCE Process
  15. 15. What Did We Change? "
  16. 16. 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"
  17. 17. Java Benchmark – Less is Better"
  18. 18. Java Benchmark – More is Better"
  19. 19. Java Benchmark – More is Better"
  20. 20. 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"
  21. 21. Browser Performance" Tests by Jacob Gube – Six Revisions
  22. 22. Application – 12GB RAM to Java VM"
  23. 23. Application – Activated GZIP "
  24. 24. Application – GreenHopper Cache"
  25. 25. Application – Kept MySQL Local "
  26. 26. Application – SSL Only If Needed"
  27. 27. Network"•  Configured SilverPeak for WAN acceleration"•  If you have Packteer - create a Level 5 policy"•  You can also use Riverbed for WAN acceleration"
  28. 28. Results "
  29. 29. What About Process?
 The Rule of 5 “P” "
  30. 30. Proficiency ProofProliferate Production Process " Procrastinate Plugins
  31. 31. Proficiency"•  Build knowledge about your infrastructure"•  Audit your systems"•  Survey your users"•  Observe new technology trends"
  32. 32. 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"
  33. 33. 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"
  34. 34. 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."
  35. 35. Proliferate"•  Keep users informed:" •  on upcoming system changes" •  on usage tips – best practices (browsers, settings, etc.)" •  Newsletter"
  36. 36. 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"
  37. 37. RFC – Log"
  38. 38. RFC – Log"
  39. 39. Conclusions "
  40. 40. Managing #JIRA Performance is not all aboutinfrastructure. Also how you manage your enterpriseprocesses. #summit12
  41. 41. Join me on Linked-in Group
 JIRA Performance
 http://www.linkedin.com/groups? home=&gid=4454622&trk=anet_ug_hm "
  42. 42. Thank you!claudio.ombrella@autodesk.com http://www.linkedin.com/pub/claudio-ombrella/0/919/17a

×