2. 1. Talos ?
- Talos is a python performance testing framework that is usable on Windows, Mac and Linux.
cf ) why Talos?
Talos is the bronze automaton of Greek myth. Talos protected the island of Crete, throwing giant boulders at unwary seamen.
He's also purported to have heated himself glowing hot and then embraced his enemies. Basically, he was awesome.
- Talos code lives at http://hg.mozilla.org/build/talos
4. 8.1 개요 (I)
Firefox 프로파일 생성 브라우저 설정 지정된 검사 실행 보고
한 페이지를 검사
(특정 처리부 시간)
여러 페이지 검사
(적재 시간)
메모리 사용량
페이지 적재 시간
GC
서로 다른 브라우저 모드
* 목표
다양한 종류의 검사를 수행할 수 있고
검사 자체에 정의된 여러 성능 특정 들을 측정할 수 있고
최대한 범용적인 검사 시스템을 만드는 것
http://www.wikihow.com/Create-a-Firefox-Profile
5. 8.1 개요 (II)
소스코드
변화
제출Tals 장비 그래프 서버
Run
Regression Script
Regression
통지 이메일
* 문제점
- 입력되는 자료의 Noisy값들을 실제 Regression 으로 오인하는 경우가 많아 결과의 신뢰도가 떨어짐 (?)
- Regression 판정을 위해 이전, 이후 버전의 코드를 체크인해야 하고 시간이 지난 후에야 검사 결과 확인 가능
- 그래프 서버에는 미리 정의된 플랫폼, branch, 검사 종류, 구성을 만족해야 하는 요구사항 때문에 새로운
검사 추가가 어려움
- 범용성을 강조한 탓에 configure 단계를 통해 구성 스크립트를 생성 후 이것을 이용해서 검사를 실행해야 하기
때문에 실행이 어려움
그래서 신뢰성 높은 검사 결과를 산출하기 위한 여러가지 노력을 통해
최적으로 검사를 실행하는 방법 파악
6. 8.2 측정 대상의 이해 (I)
- 검사결과에 나온 이 수치가 무엇을 의미하는가 ?
> 수년 전 개발된 것이거나, 문서화가 되지 않은 것들이 많아 파악하기 어려움
- 자동화된 검사에서 얻은 결과를 Local에서 똑같이 재현하는 것이 불가능 ??????????????????
> Talos 시스템이 계산을 수행하며 그래프 서버도 계산을 수행
- 페이지당 검사된 여러 수치들을 단 하나의 수치로 축약하고 시간의 흐름에 따라 그 수치를 표현 (median 계산)
> CSS 파싱이 빨라졌지만 이미지 적재가 느려진 경우 검출 불가능
> 특정 페이지는 느려지고 다른 페이지들은 이전과 동일하다는 점을 알아내기 어려움
> 최종 수치를 가지고 regression 을 유발하는 특정 페이지가 무엇인지 알아내기 어려움
7. 8.2 측정 대상의 이해 (II)
- 여러개 페이지 검사의 자료에서 Noisy를 줄이는 것이 가능함을 입증하자
> 페이지 적재 시간에 영향을 미치는 시스템의 다른 요인들(캐싱..)을 검사로부터 격리
> 여러 페이지들을 차례로 적재하는 대신 같은 페이지를 여러 번 적재하도록 변경
└ 가장 많이 캐싱된 페이지의 적재 시간을 측정 가능
└ 사용자가 실제로 웹을 브라우징할 때의 성능을 나타내진 않지만 자료의 Noisy를 줄이는 데에는 효과가 있다
> 하나의 페이지를 적어도 20번 이상 적재할 때 Noisy가 줄어든다는 점을 확인
> 페이지를 25회 적재하되 처음 5회의 수치는 버리는 것이 가장 나은 결과를 나타낸다는 것을 알아냄
└ Noisy 섞인 결과의 95%가 처음 다섯 번 이내의 적재에서 발생했었다
└ 처음 다섯번의 수치들은 계산에 사용하지는 않지만, 나중을 위해 데이터베이스에 저장
8. 8.2 측정 대상의 이해 (III)
- 새로운 요구사항
> 수집된 모든 자료를 데이터베이스에 저장
> 페이지당 20회 이상 검사한 수치를 저장해야 한다.
> 한 페이지의 개선 때문에 다른 페이지에서 Regression이 일어난 것 처럼 보이는 현상을 방지하기 위해
각 페이지를 반드시 개별적으로 계산해야 한다. 페이지들간의 평균은 구하지 않는다.
> 각 검사마다 담당 개발자를 배정하고 무엇을 왜 수집하는지 문서화 한다
> 검사가 끝나고 결과들이 보고되었을 때, 임의의 주어진 페이지에서 Regression이 있었는지를 명확하게
알 수 있어야 한다.
이러한 요구 사항을 적용하려면 많이 뜯어고쳐야 된다 -> 재 개발 vs 리팩터링
9. 8.3 재작성 대 리팩터링
처음에는 Talos와 그래프 서버를 계속 돌리면서 리팩터링
그러나 입력된 원본 자료들을 처리하기 위해서는 데이터베이스 스키마 구조를 많이 고쳐야 한다
-> 그래프 서버를 재 개발 (Datazilla 프로젝트)
10. 8.4 성능 문화 만들기
Talos 프레임워크를 다루는 개발자 2명, Datazilla/그래프 서버를 다루는 개발자 2명, 통계학자 2명, 외부인 여러명
즉, 같이 열심히 만들었다
누군가가 파이어폭스의 코드를 변경하면 Talos 는 아래 일들을 수행한다.
- Talos는 각 페이지마다 25번 검사하여 결과 수치를 수집
- 결과 수치들을 모두 Datazilla 에 제출
- Datazilla는 처음 5개의 수치를 버리고 통계 분석 수행
- T-Test 이용하여 수치들을 분석.
이전 버전과 비교하여 특이한 사항이 없는지 점검
- T-Test 분석의 모든 결과를 False Discovery Rate로 필터링
- 위 결과가 허용 범위 이내이면 Datazilla는 exponential smoothing 알고리즘을 적용하여 새로운 trend line을
생성하고, 결과가 허용 범위 밖이면 실패로 표시
- 통과된 페이지가 95%이상이면 통과로 처리
