JIRA 4.0.1 이제 20% 더 빨라졌습니다!
Andreas Knecht가 JIRA에 대해 이야기 합니다. (2009년 12월)
JIRA 3.13을 개발하는 동안, 우리 엔지니어 중 한사람은 Bamboo를 통해 매일 밤마다 Jira에 대한 자동 성능테스트를 하도록 환경구성을 하였습니다.
또한, 그 결과에 대한 요약화면과 JIRA의 성능 모니터링을 위해 Confluence에 성능 대시보드를 구성하였습니다.
성능테스트는 실제 사용데이터(http://jira.atlassian.com)로부터 시작되며 JMeter를 통해 웹인터페이스를 구성하였습니다. 실제 사용 프로파일링 데이터를 얻기 위해 수일간의 http://jira.atlassian.com 사이트 접속 로그를 확인하고 Jmeter를 통해 이 사용 패턴을 복제한 후에 JIRA가 동일한 로드가 걸린 것처럼 시뮬레이션 합니다.
저희가 JIRA 4.0을 릴리스 한 후에, 이것이 성능 모니터링에 대한 새로운 기준점이 되었습니다.
JIRA 4.0.1을 개발할 때, 상당한 성능 저하를 확인하게 되었습니다. (파란색은 JIRA 4.0을 의미하며, 오렌지색은 JIRA 4.0.x, 그리고 녹색은 JIRA 4.1.x 를 나타냅니다) 
이런. 이슈 페이지 보기가 JIRA 4.0 보다 8배나 느려졌습니다.
제시되는 결과를 보고 무엇이 속도저하를 유발하는지 고민하였습니다.
우리의 성능 테스트는 Bamboo에서 2개의 빌드플랜으로 구성됩니다. 하나는 프로파일링 된 것과 다른 하나는 프로파일링이 없는 것입니다. 프로파일링 된 빌드는 일반적으로 실제의 결과(프로파일링에 대한 오버헤드로 인해)와는 다릅니다. 그러나 이것은 jProfiler를 사용하여 성능저하를 일으키는 원인을 분석하는데 사용될 수 있는 CPU 스냅샷을 제공합니다.
그러한 스넵샷에 대한 조사는 많은 성능저하가 요청사항의 루프백을 피하기 위한 대시보드 플러그인 문제수정으로 인해 성능저하가 발생하였음을 보여주었습니다. (문제는 knowledge base article을 참조)
로컬 게짓 세부사항은 더 이상 캐쉬되지 않았으며, 더욱이 모든 리소스 번역작업은 게짓 스펙에서 인라인으로 처리되었으며 이것은 ResourceBundle (번역작업을 하는데 사용) 중요한 성능부하를 불러일으겼던 것입니다.
우리는 우선 JIRA 쪽에서 GadgetProcessor(리소스 번역 작업 담당)가 찾는 i18n 키를 캐쉬하도록 하고, 매번 새로운 인스턴스를 생성하기 보다는 (모든 i18n 플러그인이 모두 확인되어져야 해서 매우 시간이 걸리는) I18nBeanFactory 을 캐슁하여 i18nBean를 SAL에서 생성함으로서 문제를 수정하였습니다.
결국, JIRA쪽에서는 작업한 것이 없었지만, 샌프란시스코의 Atlassian Gadgets(AG) 팀에서 문제를 수정한 것입니다. AG 팀은 이제 로컬 게짓을 공격적으로 캐쉬처리하여 응답시간을 다음과 같이 떨어뜨렸습니다.: 
안타갑게도, 아직 JIRA 4.0에 비해 30% 정도 느린 상황입니다. 좀 더 추가적인 조사를 통해 우리는 어떤 코드를 정리하기위해 (그리고 JQL 자동완성기능 성능향상을 위해) deprecated permissionManager.getProjects() 대신에 permissionManager.getProjectObjects()를 사용하는데 과도하게 매쏘드를 호출한 것을 발견하였습니다.
GenericValue 기반의 오래된 매쏘드가 ThreadLocal에 캐쉬되었지만, 새로운 매쏘드는 캐쉬되지 않은 것이었습니다. 이 점이 수정되었으며 결과는 놀라웠습니다. 
여러분이 전체 통계을 보시면 JIRA 4.0.1 이 4.0 버전에 비해 20-30% 정도 빨라졌다는 것을 보실 수 있습니다. 또한 대시보드의 개선사항이 서버에 대한 루프백 요청을 제거하고 i18n 요청도 더욱 공격적으로 캐쉬되고 있습니다.: 
주의사항: JIRA 4.0.1 이 정말로 20% 가까이 빨라졌는지 아닌지는 사실 모든 사용자들에게 해당한다고 말하기는 어렵습니다. 우리들의 성능 테스트는 특정 요청사항과 특정 데이터 집합에 대해 부하가 걸리는 상황에서의 성능을 테스트한 것이기 때문입니다. 다른 데이터 집합과 다른 사용 패턴에서는 분명 결과가 달라질 수 있습니다. 또한 이러한 결과는 대시보드가 하나의 요청사항에 대해서 50%의 성능향상을 의미하지는 않습니다. 그러나 JIRA가 심한 부하에 있을 때 평균적으로 빠르다는 것에 대한 의미로 보실 수는 있는 것입니다.
(골드피처 주) 본 기사에 내용에서 세부사항은 JIRA를 잘 모르는 분들에게는 이해하기 어려울 것입니다만, 성능문제를 가시적으로 데이터화하고 이를 해결해가는 좋은 방법을 보여주고 있습니다.
'JIRA' 카테고리의 다른 글
| 이클립스나 Intellij IDEA를 사용하신다면 (0) | 2010.03.03 |
|---|---|
| 아이폰에서 JIRA가 느리나요? (0) | 2010.02.18 |
| 애플 아이폰을 사용하고 계십니까? (0) | 2010.02.02 |
| Atlassian 영업팀에서 JIRA를 어떻게 프로젝트 관리에 사용하는가 (0) | 2010.01.05 |
| JIRA 4.0 릴리스 (0) | 2009.10.14 |