MPM - 1. 실시간 모니터링
현재 성능 현황을 모니터링하고 성능 문제 여부를 파악하고 분석 우선 순위를 설정할 수 있는 방법을 안내합니다. 빈번하게 발생하는 성능 저하 현상에 대한 예시 그래프를 통해 쉽게 그래프를 해석해 보세요.
1. 성능 대시보드
MPM 대시보드에서는 현재 모바일 성능에 대한 현황을 한눈에 확인할 수 있습니다. 다양한 성능 지표를 정확하게 이해하고 분석하는 방법을 확인하시고, 효율적으로 성능 관리를 진행해 보세요.
* IMQA의 모든 데이터는 1분마다 갱신됩니다. (계약에 따라 상이할 수 있음)
1.1. 한눈에 파악하는 성능 현황
빠르게 최근 30분 동안의 성능 전반을 한눈에 확인해야할 때는 아래 3가지 항목을 먼저 확인해 보세요.
(1) 평균 문제 발생률
최근 30분 동안의 각 성능 지표(화면 로딩시간, 응답시간, CPU, 메모리, 크래시)의 기준치를 넘는 데이터 비율인 문제 발생률의 평균을 빠르게 확인할 수 있습니다. 숫자가 클수록 성능 문제가 발생하고 있다는 의미이므로 빠른 확인과 개선이 필요합니다.
| 성능 지표 | 산출 구간 | 병합 방식 |
|---|---|---|
평균 문제 발생률 | 최근 30분 | 각 성능 지표 문제 발생률 (기준치 이상 데이터 / 전체 데이터)*100 의 평균 |
각 성능 지표의 문제 발생률의 평균이기 때문에 수치가 낮더라도 성능 지표 중 1개에서 문제가 발생하고 있을 수 있습니다. 수치가 매우 낮은 경우가 아니라면, 반드시 상세 데이터를 확인해 주세요.
(2) 성능 날씨
최근 30분 동안의 평균 문제 발생률에 따라 5단계로 날씨 아이콘이 표시됩니다. 평균 값이기 때문에 맑음이어도 성능 저하로 불편함을 겪고 있는 사용자가 있을 수 있으므로 반드시 세부 데이터를 확인해 주세요.
(3) 성능 문제 발생률
최근 30분 동안의 크래시, 메모리, CPU, 응답시간, 화면 로딩 시간의 5가지 성능 지표에서 문제 발생(설정한 기준치를 넘은 상황) 비율을 그래프를 통해 한번에 확인할 수 있습니다. 막대 그래프가 보이는 상태라면 성능 문제가 발생한 상황이니 빠른 확인과 개선이 필요합니다.
| 성능 지표 | 산출 구간 | 산출 값 | 병합 방식 |
|---|---|---|---|
크래시 | 최근 30분 | 문제 발생률 | 크래시 발생 수 / 앱 실행 수 |
메모리 | 최근 30분 | 문제 발생률 | (기준치 이상 데이터 / 전체 데이터)*100 |
CPU | 최근 30분 | 문제 발생률 | (기준치 이상 데이터 / 전체 데이터)*100 |
응답시간 | 최근 30분 | 문제 발생률 | (기준치 이상 데이터 / 전체 데이터)*100 |
화면 로딩시간 | 최근 30분 | 문제 발생률 | (기준치 이상 데이터 / 전체 데이터)*100 |
기준치는 ‘관리 > 프로젝트 프리셋’에서 설정할 수 있습니다. 운영 초기, 기준치 설정이 어렵다면 각 지표별로 안내해드리는 가이드를 참고하여 설정해 보세요. (툴팁에서 확인 가능)
1.2. 각 성능 지표별 성능 현황 확인
성능 모니터링에 꼭 필요한 화면 로딩시간, 응답시간 및 CPU, 메모리 사용량을 그래프로 확인할 수 있습니다. 대시보드에서 가장 많이 볼 수 있는 그래프이므로 기본적인 데이터 이해 방법과 각 케이스를 알아두시면 데이터를 이해하시는데 용이합니다.
(1) 데이터 이해하기
시계열 그래프로 표시된 성능 지표 현황을 바르게 이해하기 위해선 아래 항목을 반드시 확인해 주세요. 아래 그래프는 가장 이상적인 형태의 그래프이니 그래프 형태와 각 항목에 대해 숙지해 보세요. 실시간 그래프 확인 시, 순차대로 아래 3개의 항목을 확인하시면 보다 정확하게 성능 현황을 파악하실 수 있습니다.
➊ 전체 평균과 하위 5%의 평균 2개의 그래프의 차이가 적으면 대부분의 사용자가 비슷한 성능을 경험했다고 판단할 수 있습니다. 특정 시간대에 차이가 클 경우, 특정 사용자가 성능 저하를 경험했다고 판단할 수 있습니다. ➋ 변동 추이 확인 변동 추이에 큰 변화가 없다면 최근 30분 내 동일한 현상이 지속되고 있음을 확인할 수 있습니다. ➌ 기준치 확인 붉은선은 각 성능 지표의 기준치를 나타냅니다. 만약 전체 평균과 하위 5%의 그래프가 차이가 없이 고른 상태라도 2개의 그래프가 붉은선을 넘는 경우라면 심각한 성능 문제가 발생한 것으로 빠른 해결이 필요합니다.
전체 평균과 하위 5%의 그래프가 차이가 없이 고르고 기준치를 넘지 않는 상태일 경우, Y표 지표를 확인해 주세요. 그래프가 0에 가까운 상태라면 성능이 좋다는 것을 의미하나, 숫자가 크다면 대다수의 사용자가 성능 저하를 겪고 있는 상황일 수 있습니다.
(2) Case Studty
① 일부 사용자의 성능 저하
가장 많이 확인할 수 있는 그래프로, 일부 사용자가 성능 저하 현상을 겪고 있는 상황입니다. 아래 예시 그래프의 분석 방법을 참고하여 현재 성능 현황을 파악해 보세요.
➊ 전체 평균과 하위 5%의 평균 확인 2개의 그래프의 차이가 비교적 적으나, 특정 구간(14:18)에서 하위 5%의 그래프가 높아진 것을 확인할 수 있습니다.
➋ 변동 추이 확인 전반적으로 큰 변화가 없으나, 특정 구간(14:18)에서 하위 5%의 그래프가 높아진 것을 확인할 수 있습니다.
➌ 기준치 확인 특정 구간(14:18)에서 기준치를 넘은 것을 확인할 수 있습니다.
하위 5%가 기준치를 넘는 문제를 겪고 있음을 확인할 수 있습니다. 이 경우 특정 사용자가 느린 로딩시간을 경험한 것으로, 해당 사용자/사용 환경을 대상으로 빠른 개선이 필요합니다.
② 전반적인 성능 저하
앱이 안정적으로 운영되는 경우에는 쉽게 나타나지 않는 그래프이나, 해당 그래프는 매우 심각한 상황으로 빠른 개선이 필요하니, 반드시 숙지해 두세요.
➊ 전체 평균과 하위 5%의 평균 확인 2개의 그래프의 차이가 크지 않고, 변동 추이도 고른 것으로 보아 최근 30분 내 대부분의 사용자가 비슷한 로딩시간을 경험했다고 판단할 수 있습니다.
➋ 변동 추이 확인 그래프의 큰 변동은 없으나, 세로축 지표를 확인했을 때 전반적으로 로딩시간이 긴 상태입니다.
➌ 기준치 확인 전체 데이터가 기준치 이상인 상태로, 성능 문제가 발생한 상태입니다.
최근 30분 간 대부분의 사용자가 느린 로딩시간으로 불편함을 겪고 있다고 판단할 수 있습니다. 느린 로딩시간은 사용자 이탈의 주요 원인이 되므로 빠른 개선이 필요합니다.
위 그래프와 유사한 형태에서 그래프가 기준치를 넘지 않더라도 기준치 근처에 위치해 있다면 사용자 대다수가 느린 로딩시간을 겪고 있음을 의미하므로 빠른 확인이 필요합니다.
③ 데이터 미수집
앱 성능 외에도 장애 및 데이터 수집 현황을 함께 확인해야 하는 경우입니다.
➊ 전체 평균과 하위 5%의 평균 확인 2개의 그래프의 차이가 크지 않고, 변동 추이도 고른 것으로 보아 대부분의 사용자가 비슷한 성능을 경험했다고 판단할 수 있습니다.
➋ 변동 추이 확인 - 특정 구간(14:10~14:12)의 데이터가 ‘0’으로 표기되므로 확인이 필요합니다. - 전반적으로 데이터 폭의 차이가 크므로 확인이 필요합니다.
➌ 기준치 확인 전체 데이터가 기준치 이상인 상태로, 성능 문제가 발생한 상태입니다.
위 그래프는 아래 3가지 상황에서 나타날 수 있는 그래프입니다.
1. 앱 성능이 고르지 못한 상황이라고 판단할 수 있습니다. 2. 특정 구간에서 장애로 인해 데이터가 수집되지 않은 것일 수 있습니다. 3. 실제 사용자가 없어 수집된 데이터가 없는 상황일 수 있습니다.
장애로 인해 데이터가 수집되지 않는 경우 빠른 개선이 필요합니다.
④ 연계 분석을 통한 원인 분석
성능 모니터링의 주요 지표인 화면 로딩시간, 응답시간, CPU 사용량, 메모리 사용량은 개별 분석보다는 연계하여 함께 분석해야 합니다. 아래 예시를 통해 그래프를 어떻게 읽고, 원인을 찾아야 하는지 확인해 보세요.
화면 로딩시간을 보면 전체 평균과 하위 5% 평균의 차이가 큰 것을 확인할 수 있습니다. 화면 로딩시간이 느리다는 것은 사용자의 화면이 늦게 뜬다는 최종 결과이므로 다른 성능과 연계하여 원인 분석을 해야 합니다.
1. 응답시간과 자원 사용량(CPU, 메모리)를 함께 확인해보면, 응답시간과 메모리 그래프는 위에서 살펴본 이상적인 그래프와 매우 유사한 형태입니다. 2. CPU의 경우 전반적으로 사용량이 많은 것으로 확인됩니다. 3. 이 경우, CPU의 높은 사용량이 화면 로딩시간을 지연시키는 원인일 수 있다고 분석할 수 있습니다.
1.3. 화면별 성능 현황 확인
화면별 화면 로딩시간, 응답시간, CPU 사용량, 메모리 사용량을 숫자와 색상을 통해 한눈에 파악할 수 있습니다.
(1) 요약 정보
최근 30분 동안의 사용자가 방문한 화면 별 성능 현황을 리스트로 한번에 확인할 수 있습니다.
방문율순, 문제 발생률순, 하위 5%순, 평균순으로 정렬된 화면에 어떤 성능 저하가 있었는지 한눈에 확인할 수 있습니다. 색상과 숫자로 설정한 기준치 이상의 데이터 비율과 위험도는 ‘관리 > 프로젝트 프리셋’에서 설정하실 수 있습니다.
(2) 화면 카드
최근 30분 동안의 사용자가 방문한 화면을 방문율순, 문제발생률순, 하위 5%순, 평균순으로 정렬하여 확인할 수 있습니다. 기본적으로 방문율이 높은 순으로 정렬되며 화면 카드 클릭 시 ‘화면별 성능 분석’ 페이지로 이동합니다.
화면 이름은 이해하기 쉽도록 IMQA에서 표시할 이름으로 변경 가능하며, 노출/숨김 설정도 가능합니다. ‘관리 > 화면 관리’에서 변경하실 수 있습니다.
특정 몇 개의 화면만 ‘보기' 설정을 했을 경우, 실제 사용자가 방문한 화면에서 발생하는 성능 저하 문제를 대시보드에서 파악하기 어려우니, 유의해 주세요.
(3) Case - 성능 분석 우선순위 파악
성능 대시보드 내 화면 카드는 방문율 순으로 정렬되며, 설정한 기준치를 초과한 비율을 색상과 숫자로 확인할 수 있습니다. 수많은 화면 카드 중 어떤 화면부터 성능 확인 및 분석이 필요한지 빠른 판단이 필요합니다. 아래와 같은 기준에 따라 우선순위를 정하고, ‘화면별 성능 분석’에서 자세히 확인해 보세요.
방문율 순으로 정렬된 위 이미지에서 표시된 2개의 화면 카드 중, 어떤 화면부터 확인해야 할까요?
2번 화면이 문제 발생률은 훨씬 높지만 방문율 순으로 정렬되어 있으므로 1번 화면에 비해 이용자가 적게 방문한 화면임을 알 수 있습니다. 반면 1번 화면의 경우, 2번 화면에 비해 문제 발생률은 낮지만, 방문율이 13%로, 0.4%인 2번 화면에 비해 더 많은 사용자가 방문하여 성능 문제를 겪고 있을 수 있습니다.
따라서 방문율 순으로 화면을 분석할 경우, 문제 발생률이 비슷하다면 좌측 상단에 가까운 화면부터 확인하는 것이 좋습니다. 문제발생률, 하위 5%, 평균 순으로 정렬하여 분석할 때도 방문율을 함께 고려하여 우선순위를 정해 보세요.
2. 화면별 성능 분석
선택한 화면별 성능 현황을 30분 단위로 상세하게 확인할 수 있습니다. 화면 성능 정보와 각 성능 지표에 대한 히트맵을 통해 성능 분포 및 저하 상황을 확인하실 수 있습니다.
2.1. 시간대별 데이터 수
각 시간대별 집계된 데이터 수에 따라 타임라인의 색상 농도가 4단계로 표시됩니다. 색상을 통해 30분 단위로 구분된 시간대별 데이터 수를 확인해 보세요. 색상에 따른 데이터 수는 우측의 툴팁으로도 확인하실 수 있습니다.
2.2 화면 성능 정보
좌측 상단의 화면 성능 정보에서는 현재 화면에서 어떤 성능 저하가 있었는지 한눈에 확인할 수 있습니다.
위의 화면 로딩시간과 같이 평균과 하위 5%의 값이 큰 차이가 있는 경우 성능이 고르지 못하고, 편차가 심한 상태입니다. 특히 값이 클수록 성능 저하를 겪고 있는 상황이니 우선적으로 확인해야 합니다.
만약 응답시간처럼 평균과 하위 5% 값이 큰 차이가 있으나, 전반적으로 값이 작을 경우에는 성능이 좋은 상태임을 알 수 있습니다.
2.3. 성능 분포와 성능 저하 상황 확인
화면 성능 정보를 통해 우선적으로 확인이 필요한 성능 지표를 확인하였다면, 이제 우측에서 각 성능 지표에 대한 히트맵을 통해 성능 분포와 성능 저하 상황을 상세히 확인, 분석할 수 있습니다. 웹/하이브리드 앱의 경우, ‘웹뷰 화면 로딩시간’과 ‘웹뷰 응답시간’을 함께 확인할 수 있습니다.
(1) 히트맵 구성
6개의 성능 정보의 기본 구성은 동일합니다. 범례, 색상의 경우 화면 로딩시간 / 응답시간 / CPU, 메모리가 다르므로 처음 데이터를 확인하신다면 범례를 꼭 확인해 주세요.
➊ 웹뷰 페이지 해당 네이티브 화면에 속한 웹뷰 화면이 있을 경우, 웹뷰 화면 로딩시간을 확인할 수 있습니다. 기본 ‘전체’ 웹 페이지 기준으로 히트맵이 표시되며 페이지 변경 시 히트맵을 갱신합니다. 해당 네이티브 화면에 속한 웹뷰 화면이 있을 경우, 웹뷰 화면 로딩시간을 확인할 수 있습니다. 기본 ‘전체’ 웹 페이지 기준으로 히트맵이 표시되며 페이지 변경 시 히트맵을 갱신합니다.
➋ 범례 기준치 이상 구간일 경우 빨강, 미만일 경우 파랑으로 표시됩니다. 같은 시간 축에 집계된 데이터 비율에 따라 색상 농도를 4단계로 표시합니다. 응답시간의 경우, 수집된 정보에서 4xx대, 5xx대 응답코드인 경우에는 빨강, 그 외 응답 경우에는 파랑으로 표시되며, 동일하게 색상 농도를 4단계로 표시합니다. 색상 농도는 상대적 데이터(비율)이기 때문에 해당 시간에 전체 데이터가 많다면 색상이 흐려도 데이터가 많을 수 있습니다. 해당 내용은 아례 예시를 통해 상세히 확인하실 수 있습니다.
➌ 상세 정보 셀에 마우스 포인터를 올리면 ‘날짜, 시간, 데이터 수, 성능 구간’이 툴팁으로 표시됩니다. 확인이 필요한 셀을 클릭하거나 드래그하여 해당 부분에 대한 ‘네이티브 스택 상세’, ‘웹 리소스 상세’ 데이터를 확인할 수 있습니다.
(2) 히트맵 데이터 이해하기
히트맵으로 표시된 성능 지표를 바르게 이해하고, 데이터 확인, 분석 우선 순위를 정하기 위해선 아래 항목을 숙지해 보세요. 아래 항목과 관련된 예시 상황도 이어서 안내해 드리니, 함께 확인해 보세요.
➊ 기준치 이상 데이터 확인 기준치 이상의 데이터는 빨강색으로 표기되기 때문에 직관적으로 확인하실 수 있습니다. 여기서 4단계로 구분되는 농도는 위험도가 아닌 같은 시간 내 데이터 수로 구분됩니다. 이점 유의해 주세요.
➋ 세로축 확인 6개의 히트맵 모두 상세 확인이 필요할 경우, 우선 순위를 정하기 위해서는 세로축 값을 확인해야 합니다. 기준치에 가까워도 빨강색으로 표시되기 때문에 기준치에서 많이 벗어난(값이 큰) 데이터를 우선적으로 파악해야 합니다.
➌ 데이터 수 확인 세로축값이 비슷한 상황이라면 마우스 오버하여 데이터 수를 확인해 주세요. ➊번 항목에서 확인했다시피, 같은 시간축 내 데이터를 기준으로 농도를 구분하기 때문에 농도가 흐려도 데이터 수가 많을 수 있습니다.
히트맵에서 개별 성능만 확인하는 것이 아닌 화면 로딩시간-응답시간, 화면 로딩시간-CPU/메모리처럼 연계하여 함께 분석해 보세요. 화면 로딩시간이 길어지는 현상은 응답시간, CPU, 메모리 사용량 같은 다른 성능 지표가 원인일 가능성이 높으니 같이 확인하는 것이 좋습니다.
(3) Case Study
① 네이티브/웹뷰 화면 로딩 시간 모두 기준치를 초과한 상황
성능 상세 분석에서 가장 많이 볼 수 있는 상황으로 네이티브 화면 로딩시간과 웹뷰 화면 로딩시간 모두 기준치를 초과한 데이터가 있을 때, 어떤 것을 확인해야 하는지 아래를 통해 확인해 보세요.
아래, 위 모두 기준치 이상인 상황에서 위인 네이티브는 진한 색상으로, 아래 웹뷰는 흐린 색상으로 표기되었습니다. 보통 최상단에 있는 진한 색상의 데이터를 확인하는 경우가 많습니다. 그렇다면 이 데이터부터 확인하는 것이 좋을까요? 앞에서 설명한 방법대로 상세 확인해 보겠습니다.
➊ 기준치 이상 데이터 확인 화면 내 모든 데이터가 기준치 이상이기 때문에 빠른 개선이 필요합니다. 기준치가 너무 낮게 설정된 경우에도 모든 데이터가 기준치 이상으로 보일 수 있습니다. 아래 항목과 함께 확인해 보세요.
➋ 세로축 확인 세로축 값을 확인했을 때, 웹뷰 화면 로딩시간이 더 긴 상황임을 확인할 수 있습니다.
➌ 데이터 수 확인 마우스 오버 시, 아래 농도가 낮은 웹뷰 화면 로딩시간의 문제 구간의 데이터가 더 많은 것을 확인할 수 있습니다. 이 경우, 화면 로딩시간도 상대적으로 더 길고, 데이터가 많은 아래 웹뷰 화면 로딩시간부터 확인하여 개선하는 것이 좋습니다.
② 응답시간이 긴 경우
응답시간은 4xx, 5xx 상태 코드 외 응답 코드일 경우 파랑색으로 표시됩니다. 히트맵 전체가 파랑색으로 표기되어 4xx, 5xx 대 상태 코드가 없는 것을 확인하였습니다. 전반적으로 문제가 없어 보이지만 세로축을 확인했을 때, 응답시간이 긴 부분을 확인할 수 있습니다. 이 경우, 상세 확인을 하여 문제의 원인을 파악해야 합니다.
③ 특정 시간대의 문제 발생
위의 이미지와 같은 히트맵의 경우, 특정 시간대(19:40)에 전반적으로 문제가 발생한 것을 확인할 수 있습니다. 이 경우 해당 시간대에 서버, 통신사 문제 등 외부적 요인이 있을 가능성이 있으므로 응답시간 히트맵을 같이 확인하는 것이 좋습니다. 또한 해당 시간대 전체의 상세 정보를 확인하여 특정 고객만의 문제가 아닌, 해당 시간대의 이용 고객들의 문제인지 확인이 필요합니다.
3. 성능 상세 분석
앞의 성능 히트맵에서 셀을 클릭하거나 구간을 마우스 드래그하면 항목에 따라 네이티브 스택 분석, 웹 리소스 분석을 확인할 수 있습니다. 스택과 웹 리소스를 확인하기 전 아래 항목을 먼저 확인해 보세요.
➊ 디바이스 정보 리스트 화면/페이지, 앱 버전, OS 버전, 디바이스, 통신사, 위치, 화면 로딩시간, 사용자 수에 대한 정보를 먼저 확인해 보세요. 특정 디바이스, 통신사, OS, 위치가 동일하다면 해당 문제 일 수 있으니 우선 확인하는 것이 좋습니다. 확인이 필요한 디바이스를 선택하시면 하단에서 네이티브 스택/웹 리소스 상세 확인이 가능합니다.
특정 디바이스, OS 버전, 위치가 반복적으로 문제가 발생한다면, 해당 부분만 선택하여 알림을 받으실 수도 있습니다. 예를 들어, 신규 디바이스 출시 시, 해당 디바이스에 대한 관리가 집중적으로 필요하다면, ‘알림 > 알림 정책 관리’에서 설정하실 수 있습니다.
➋ 사용자 행동 분석(역추적 행동 분석)
성능 저하 문제가 발생한 화면은 어느 경로로 이동했는지에 따라 문제 상황이 다를 수 있습니다. 디바이스 정보 리스트에서 디바이스 선택 후, ‘사용자 행동분석’ 버튼을 클릭하면 해당 디바이스 사용자의 앱 실행부터 앱 종료까지의 화면 흐름을 ‘행동분석’ 페이지에서 확인하실 수 있습니다. 페이지 이동 시, 문제가 발생한 화면과 다음 화면이 표시되어 빠르게 확인할 수 있습니다. 해당 기능을 통해 문제 화면 전후를 포함한 이동 경로를 빠르게 확인하실 수 있습니다. 화면명 클릭 시, 해당 화면에 대한 성능 데이터를 확인할 수 있으며, 항목 클릭 시 상세 데이터 확인이 가능합니다.
4. A/B 대시보드
A/B 대시보드에서는 두 개의 앱, 앱 버전(A,B 프로젝트)을 동시에 모니터링할 수 있습니다 Android와 iOS를 비교하고 싶은 경우, 이전 버전과 최신 버전을 비교하고 싶은 경우 A/B 대시보드를 활용해 보세요.
대부분의 그래프는 성능 대시보드 내 그래프와 동일한 것으로, 데이터 읽는 방법은 성능 대시보드의 데이터 읽는 방법을 참고해 주세요. 성능 대시보드에서 확인할 수 없는 그래프는 아래 내용을 참고하여 모니터링을 시작해 보세요.
4.1. 앱 요약 정보 확인하기
우측 상단의 드롭다운 버튼을 통해 비교할 앱과 앱 버전을 선택하실 수 있습니다. 선택한 앱에 대한 성능 날씨, 평균 24시간 이용자 수, 최근 24시간 실행 수, 평균 문제 발생률과 같은 요약 정보를 비교하여 확인할 수 있습니다. 데이터는 상단의 표시된 컬러로 구분하실 수 있습니다.
4.2 시계열 그래프 분석하기
이용자&실행 수, 크래시, 화면 로딩시간, 응답시간, CPU 사용량, 메모리 사용량의 시계열 그래프는 성능 대시보드와 동일한 형태입니다. 성능 대시보드에서는 하위 5%와 평균 데이터를 확인하실 수 있던 것과는 달리 선택한 앱과 앱 버전의 데이터를 동시에 확인할 수 있습니다. 그래프를 확인하는 방법은 ‘1. 성능 대시보드 > 1.2. 각 성능 지표별 성능 현황 확인’을 참고해 주세요.
4.3 성능 문제 발생률
성능 문제 발생률에서는 최근 30분 동안의 크래시, 메모리, CPU, 응답시간, 화면 로딩시간의 문제 발생률을 한 눈에 확인할 수 있습니다. 크래시는 ‘크래시 발생 수/앱 실행 수’로 산출하며, 이 외 나머지 성능 정보는 ‘기준치 이상 테이터/전체데이터*100’으로 산출됩니다.
위험도는 정상, 경고, 위험 범위로 컬러로 구분하여 표시합니다. 문제 발생률이 가장 높은 성능 지표를 표시하기 때문에, 정상 범위의 지표도 표시될 수 있습니다.
4.4 화면별 성능 현황
최근 30분 동안 사용자가 방문한 화면을 버블 차트 내 분포로 확인할 수 있습니다. 화면별 방문자 수, 각 성능의 문제 발생률, 평균 값을 확인할 수 있습니다. 버블 차트에 대한 구성과 각 분포에 따른 성능 현황에 대해 확인해 보세요.
(1) 버블 차트 구성
➊ 가로축: 문제 발생률 / 세로축: 성능 수치
➋ 화면에 대한 상세 데이터 마우스 오버 시, 해당 화면에 대한 방문자 수, 성능 지표, 문제 발생률을 확인하실 수 있습니다.
➌ 버블 위치 0에 가까울수록 좋은 성능을 의미합니다. 위의 그래프처럼 좌측 하단에 버블이 모여있는 것이 좋습니다.
➍ 화면 성능 분석 클릭 시, 해당 화면에 대한 ‘화면 성능 분석’ 화면을 확인할 수 있습니다.
➎ B프로젝트 기준선 가로 점선은 B프로젝트의 성능 지표별 기준치를 표시합니다.
➏ A프로젝트 기준선 가로 실선은 A프로젝트의 성능 지표별 기준치를 표시합니다.
(2) 버블 차트 데이터 이해하기
화면별 성능 현황에서 버블의 크기는 각 성능 지표에 대한 이용자 수가 많은 화면을 의미합니다. 버블의 크기와 위치로 상세 분석 우선 순위를 정할 수 있습니다. 또한 데이터의 분포, 밀집 현상을 한눈에 확인할 수 있습니다.
➊ 버블 위치 확인 우선 버블이 어디에 모여있는지 확인해 보세요. 0에 가까울수록 성능이 좋은 것이며, 이 외에 위치할 경우 문제가 발생한 것일 수 있으므로 확인이 필요합니다. 위치에 따른 현황은 아래 이미지를 참고해 주세요.
⓵ 문제 발생률이 낮은 위치로 보아 전체 사용자 대비, 상대적으로 적은 일부 사용자가 성능 문제를 겪었음을 의미 ⓶ 가장 관리가 필요한 부분으로 대다수의 사용자가 동일한 화면에서 성능 문제를 겪었음을 의미 ⓷ 가장 이상적인 분포로 대부분의 사용자가 성능 문제 없이 원활하게 앱을 이용하고 있음을 의미 ⓸ 상당수의 사용자가 기준치를 초과한 성능 문제를 겪은 상태이나 최근 30분 내 가장 높은 성능 수치 대비 낮은 상황임을 의미
➋ 기준선 확인 실선과 점선으로 구분된 A, B 프로젝트의 기준선을 확인해 보세요. 버블이 기준선 보다 위에 있는 경우, 해당 화면의 평균 성능 데이터가 기준치를 초과한 상황으로 상세 확인이 필요합니다. 기준치가 너무 낮거나, 높은 경우 ‘관리 > 프로젝트 프리셋'에서 툴팁 가이드를 참고하여 변경해 부세요.
➌ 세로축 확인 전반적인 성능 수치를 확인하기 위해선 세로축의 값도 확인해야 합니다. 30분 내 성능 수치에 따라 세로축 값은 변동되므로 버블의 성능 수치를 확인하기 위해선 위치 외 세로축 값도 반드시 확인해야 합니다.
버블 차트는 히트맵과 비슷하게 전반적인 성능 수치와 이용자 수를 함께 고려하여 성능 문제 확인 우선순위를 설정해야 합니다. 문제 발생률 높고, 기준치를 초과했는지, 전반적인 성능 수치가 어떠한지 확인이 필요합니다. 비슷한 위치에 여러 개의 버블이 위치해 있다면, 상대적으로 버블이 더 큰 화면부터 확인해야 합니다. 버블이 큰 경우, 해당 화면의 이용자 수가 많다는 의미로, 성능 문제를 겪고 있는 이용자가 많을 수 있으므로 개선이 필요합니다.
(3) Case - 가장 관리가 필요한 상황
아래 이미지와 같은 경우, 전반적인 성능 관리가 시급합니다. 모든 버블이 해당 위치에 있지 않더라도 특정 버블이 군집에서 벗어나 아래와 같은 위치에 있다면 관리가 필요합니다. 특히, 해당 버블의 크키가 크다면 빠른 개선이 필요합니다.
➊ 버블 위치 확인 위와 같이 버블이 위치한 경우, 성능 관리가 필요합니다. 위 이미지 기준, 모든 화면에서 이용자가 성능 문제(높은 문제 발생률)를 겪고 있음을 알 수 있습니다.
➋ 기준선 & 세로축 확인 모든 화면이 기준치에서 크게 벗어 났으며, 최대값이 14,000ms로 전반적인 성능 수치도 매우 높습니다. 따라서 모든 화면에 대한 빠른 개선이 필요하며, 크기가 큰 (방문자가 많은) 버블부터 개선을 시작하는 것이 좋습니다.
4.5. 최근 5분 화면 로딩시간/응답시간 분포
최근 5분 간의 A, B 프로젝트의 성능 분포 상태를 한눈에 확인할 수 있습니다.
(1) 그래프 구성
아래 그래프는 ‘통계 > 구간분석’에서 다룰 그래프와 유사한 형태로 기본 구성 항목을 익히시면 전체 구간 분석에서 데이터를 이해하시는데 도움이 되니, 꼭 알아두세요.
➊ A/B 평균 A/B 프로젝트의 최근 5분 화면 로딩시간, 응답시간의 전체 평균 값을 확인할 수 있습니다.
➋ A/B 평균 기준선 A/B 프로젝트의 평균 값을 확인할 수 있는 기준선으로 ①과 동일한 값입니다. 평균 기준선이 0에 가까울 수록 빠른 성능을 의미합니다.
➌ 95%(하위 5%) 기준선 성능 하위5% 기준선으로 전체 데이터 분포의 하위 5% 시작되는 지점입니다. 성능이 가장 낮은 데이터를 파악하는 경우 유용하며, 해당 기준선 역시 0에 가까울 수록 빠른 성능을 의미합니다.
➍ 수집된 데이터의 수 세로축은 수집된 데이터의 수로, 막대 길이를 통해 데이터 수를 확인할 수 있습니다.
➎ 툴팁을 통한 데이터 확인 마우스 오버 시 해당 구간에 대한 상세 데이터 및 데이터 수를 확인할 수 있습니다.
➏ 상세 데이터 확인 막대 클릭 시 ‘네이티브 스택 분석’, ‘웹 리소스 분석’, ‘상세 응답 분석’ 팝업 확인이 가능합니다.
➐ 화면 로딩시간: 0~5,000ms, 응답시간: 0~10,000ms 까지의 계급
(2) Case Study
① 가장 이상적인 상황
위의 그래프의 경우, 가장 이상적인 상황의 그래프입니다. 평균 값이 900ms이며, 대다수의 데이터가 0~1,800ms 내 분포하고 있습니다. 화면 로딩시간이 0~1.8초 걸렸고, 평균적으로 1초 내 로딩이 되어 사용이 원활함을 알 수 있습니다. 전반적인 성능은 좋으나, 일부 로딩시간이 긴 경우가 있으므로 이 부분은 확인하여 개선하는 것이 좋습니다.
② 앱 성능이 고르지 못한 현상
앞선 예시의 경우, 대부분의 데이터와 평균 기준선이 0에 가까워 성능이 좋음을 알 수 있습니다. 반대로 데이터가 95%(하위5%) 기준선 아래로 모여있다면 성능이 좋지 않음을 직관적으로 알 수 있습니다. 그렇다면 위 이미지와 같은 경우는 어떠할까요? 데이터가 넓게 분산되어 있는 것으로 앱 사용자들이 1초, 3초, 5초 등 제각각 다른 로딩시간을 겪었음을 알 수 있습니다. 다양한 사용자 환경에 최적화되지 않았음을 의미합니다.
4.6 최근 5분 CPU/메모리
➊ A/B 평균 A, B 프로젝트의 최근 5분 CPU, 메모리 사용량의 전체 평균을 확인할 수 있습니다.
➋ CPU 사용량 CPU 사용량 평균은 막대 길이로 표시되며, 100% 기준으로 상대 비율로 표기됩니다. 클릭 시 ‘CPU 상세 분석’ 팝업이 뜹니다.
➌ 메모리 사용량 메모리는 CPU와 달리 100% 값을 설정이 어려워 A, B 프로젝트의 상대 비율로 확인할 수 있습니다. 따라서 2개의 프로젝트 중 메모리 사용량이 더 많은 그래프는 100% 값으로 표기됩니다. 아래 숫자로 표기된 사용량을 참고해 주세요. 클릭 시 ‘메모리 상세 분석’ 팝업이 노출됩니다.
Last updated
