데이터 이해하기
Last updated
Last updated
하위 5%는 성능이 좋지 못한 하위 5% 데이터의 평균값입니다. 성능이 좋지 못하다는 건 화면 로딩시간이나 응답시간이 느린 순, CPU와 메모리 사용량이 많은 순을 의미합니다.
예를들어, 화면 로딩시간 데이터가 1000건이 있다면 로딩시간이 느린 순으로 정렬했을 때 하위 5% 즉, 50건의 데이터의 평균값이 하위 5%가 되는 것입니다.
위 그래프에서 화면 로딩시간과 응답시간의 11:23~11:24구간을 확인해 보겠습니다. 화면 로딩시간의 경우 하위 5%와 평균의 차이가 적음을 알 수 있습니다죠. 이렇게 하위 5%와 전체 평균의 차이가 적으면 대부분의 사용자들이 경험하는 속도는 비슷하다고 판단할 수 있습니다. 반면 응답시간의 경우 하위 5%와 평균의 차이가 크다는 것을 확인할 수 있습니다. 이렇게 하위 5%와 전체 평균의 차이가 크면 일부 사용자들이 평균보다 긴 응답시간을 경험했다고 판단할 수 있습니다.
현재 위치한 앱 버전과 다음 우선순위 앱 버전의 최근 30분 동안의 크래시, 메모리, CPU, 응답시간, 화면 로딩시간의 5가지 성능 지표의 문제 발생률을 그래프로 표시합니다.
성능 문제 발생률이란 전체 데이터에서 기준치 이상 데이터의 비율을 의미하며, 평균 문제 발생률은 성능 문제 발생률의 평균을 의미합니다.
성능 문제 발생률: 각 성능 지표별 (기준치 이상 데이터 / 전체 데이터)*100
평균 문제 발생률: (기준치 이상 데이터 / 전체 데이터)*100의 평균 (성능 문제 발생률의 평균)
예를 들어,
크래시: 전체 앱 실행 수가 100건이고 크래시 발생 수가 30건일 경우 크래시의 문제 발생률은 30%로 표시하게 됩니다.
화면 로딩시간: 전체 데이터 수가 1000건이고 기준치 300ms 넘는 데이터 수가 100건일 경우 화면 로딩시간의 문제 발생률은 10%로 표시하게 됩니다.
'최근 5분 성능 지표'는 A/B 대시보드에서 확인할 수 있으며 A, B프로젝트의 최근 5분 동안의 화면 로딩시간, 응답시간, 자원 사용량(CPU/메모리)의 성능 변동을 실시간으로 확인할 수 있습니다. (1분마다 갱신)
이를 통해 5분 동안의 성능 분포 상태를 한눈에 파악할 수 있고, A,B데이터의 성능을 비교하기에 유용합니다.
그래프의 위치에 따라 아래와 같이 해석할 수 있습니다.
1. 50% 기준치에 분포한 경우(가장 이상적인 현상)
2. 95% 기준치에 분포한 경우 (관리가 필요한 현상)
3. 데이터가 넓게 분산되어 있는 경우(앱 성능이 고르지 못한 현상)
각 예시 데이터에 대한 자세한 설명은 블로그에서 상세히 확인하실 수 있습니다.
메모리는 수치가 높은 프로젝트 막대를 100%로 표시하고, 나머지는 상대 비율로 표시합니다. 따라서 메모리의 막대그래프 중 하나는 항상 100%로 표시됩니다. 메모리의 경우 최대 사용량을 정할 수 없기 때문에 수치가 높은 프로젝트의 막대를 100%로, 나머지를 상대 비율로 표기합니다.
막대그래프의 수치가 100%로 표시되어 있어도 성능이 좋지 않은 것은 아니니 그래프 아래의 CPU 사용량을 확인해 주세요.
OS: 운영체제 전체적인 자원 사용량
APP: 해당 앱이 할당하고 있는 자원 사용량
OS 사용량과 APP 사용량을 구분하여 우리 앱이 디바이스 자원을 얼마나 사용하는지 알 수 있습니다.
가로축은 문제 발생률 / 세로축은 성능 수치(화면 로딩시간, 응답시간, CPU, 메모리)로 표현하였고, 이는 '0'에 가까울수록 좋은 성능이라는 것을 의미합니다. 버블은 사용자가 방문한 화면으로 크기는 방문자 수를 나타냅니다.
문제 발생률, 성능 수치, 버블, 버블의 크기를 통해 A, B프로젝트의 상호 관계를 파악할 수 있고, 버블을 통해 평균적인 성능과 눈에 띄는 성능 저하 화면을 직관적으로 확인할 수 있답니다. 화면 버블을 클릭하면 '화면 성능 분석'을 통해 성능 저하 원인을 상세하게 분석할 수 있습니다.
버블 차트는 기본적으로 버블의 위치에 따라(4사분면) 아래와 같이 해석할 수 있습니다.
예시 데이터를 통한 버블 차트에 대한 설명은 블로그에서 상세히 확인하실 수 있습니다.
구간 분석은 전체 데이터 분포를 파악하거나 시간 별로 비교할 수 있으며, 특정 성능 저하 구간을 상세하게 확인할 수 있어 성능 저하 관리에 유용합니다. 날짜, 시간(30분 단위)별 성능 정보와 자원 사용량을 확인할 수 있으며, 성능 분포 그래프는 50%, 95% 기준선으로 3개의 구간으로 구분이 됩니다.
❶ 3개의 구간 중 상세 확인이 필요한 구간을 선택하여 확인 가능합니다. ❷ 사용자 정보에서는 화면, OS 버전, 디바이스, 위치/통신사, 프로세스, GPS 등 선택한 구간의 사용자가 어떤 환경에 있었는지 확인할 수 있습니다. ❸ 해당 구간의 성능 히트맵과 리소스 히트맵을 확인할 수 있습니다.
성능 히트맵(성능 현황): 화면 로딩시간, 응답시간, 프래그먼트 렌더링, 이벤트, 크래시의 히트맵 확인 가능
리소스 히트맵(자원 사용량): CPU/메모리 사용량, 네트워크I/O 히트맵 확인 가능
기본적으로 50% 기준선에 데이터가 분포되어 있다면 평균적으로 앱 성능이 고른 상태, 95% 기준선에 데이터가 분포되어 있다면 평균에서 벗어난 관리가 필요한 상태라고 이해할 수 있습니다.
1. 구간 1 (성능 최적화 구간)
구간 1은 전체 데이터 분포의 0 ~ 50% 미만에 해당되는 구간입니다. 데이터는 ‘0’에 가까울수록 좋은 성능이며, ‘0’에 가까운 데이터가 많을수록 50% 기준선도 ‘0’에 가까이 위치합니다. 이 구간은 평균 기준선 미만의 데이터로 성능 최적화 구간이라고 할 수 있습니다.
2. 구간 2 (성능 주의 구간)
구간 2는 전체 데이터 분포의 50% 이상 ~ 95% 미만에 해당되는 구간입니다. 평균 기준선에 분포한 데이터와 95% 기준선에 분포한 데이터가 공존하는 구간으로 성능을 주의해야 할 구간입니다. 평균 기준선에 분포한 사용자는 좋은 성능을, 95% 기준선에 분포한 사용자는 좋지 못한 성능을 경험했다고 판단할 수 있습니다.
3. 구간 3 (성능 위험 구간)
구간 3은 전체 데이터 분포의 95% 이상에 해당되는 구간으로, 성능이 가장 좋지 못한 하위 5%를 의미합니다. 성능 저하 문제를 관리하기 위해선 성능이 좋지 못한 데이터, 즉 성능 저하 구간인 구간 3을 집중 관리해야 합니다.
위의 각 예시 데이터에 대한 상세 데이터 분석에 대한 내용은 블로그에서 확인하실 수 있습니다.
성능 리포트는 각 성능 지표를 9구간으로 분할하여 표기하며, 컬러로 성능 안정/위험 구간을 구분합니다.
회색 구간: 성능 안정 구간
회색 이외의 구간: 성능 위험 구간
분할된 구간 내 비율을 보고 사용자 분포도를 확인할 수 있는데요. 기준치 구간(성능 안정 구간)에 대부분의 사용자가 분포되어 있다면 앱 사용이 원활하다고 판단할 수 있으며, 넓게 분포되어 있다면 앱이 다양한 사용자 환경에 최적화되어 있지 않음을 의미합니다.
성능 리포트는 성능 지표별 사용자 분포를 통해 몇 %의 사용자가 어느 정도의 성능 문제를 겪는지 알 수 있는데요. 이를 통해 하루 동안의 전체 성능 현황을 파악하는데 유용합니다.
위의 성능 리포트에서 네이티브 화면 로딩 시간을 해석해 본다면
전체 데이터 34, 523건 - 화면 로딩시간 100ms 이하(성능 안정 구간): 99.684% - 화면 로딩시간 101ms 이상(성능 위험 구간): 0.316%
대부분의 사용자가(99% 이상) 짧은 로딩시간을 경험, 즉 불편함 없이 앱을 사용했다고 판단할 수 있으며 그 외 일부 사용자는(0.316%) 40초의 긴 로딩시간을 경험, 즉 성능 저하로 인해 불편함을 겪었음을 알 수 있습니다.
병목 현상 리포트는 성능 지표별 하위 5%와 응답 시간 / 웹뷰 화면 로딩시간 하위 20으로 나누어져 있습니다.
성능 지표별 하위 5%: 네이티브 화면 로딩시간, CPU 사용량, 메모리 사용량 하위 5%의 화면과 사용자 환경(OS 버전, 디바이스, 위치/통신사) 확인
응답 시간 / 웹뷰 화면 로딩시간 하위 20: 일일 사용자 데이터 중 가장 응답시간이 길었던 하위 20 / 가장 화면 로딩시간이 길었던 웹페이지 20개 확인
성능 지표별 하위 5%를 통해 성능이 저하된 주된 화면, 성능 저하를 경험한 사용자의 환경과 비율을 확인할 수 있고, 응답 시간 / 웹뷰 화면 로딩시간 하위20을 통해 성능 저하가 있었던 항목, 성능 저하를 경험한 사용자 환경을 확인할 수 있습니다.
병목 현상 리포트는 성능 저하 원인을 자세히 파악할 수 있어 오류 보고서로도 사용할 수 있고, 성능 개선 지표로 활용할 수 있습니다.
