10. 서버(Server) 와 모바일의 태생적 차이
기본 제약들 서버/웹서버 모바일
상시 전원 공급 ● X
CPU / GPU 쿨러 (발열 방지) ● X
앱이 돌아가는 환경 단일 OS/ 디바이스 파편화
OS 버전 업데이트 (주체) 개발/운영사가 제어 플랫폼 회사 / 소비자 제어
배포 주도권 / 반영 시간 개발 ,운영사 / 즉시
플랫폼 회사, 소비자 /
2~7일 (안할수도 있음)
25. 클라우드 환경에서 수집해야 되는 대표적인 지표 몇개.
§ IOPS
§ Disk Queue Length (win) / iowait (linux)
§ CPU Steal Time 등..
§ http://bencane.com/2012/08/06/troubleshooting-high-
io-wait-in-linux/
26. 클라우드 에서의 성능 측정이 어려운 이유..
첫째, 일부 부분은 우리가 통제할 수 없다.
우리는 클라우드 솔루션을 평가하고 벤치마킹할 수 있지만
어딘가 예측할 수 없는 공유 시스템을 제공 받을 뿐이다.
우리가 모든 환경을 통제할 수 없으니 정확하게 느려지거나
단절 되는 이유를 알아내기 매우 힘들다.
Sasha Goldshtein
Velocity 컨퍼런스 : Linux Performance : Tracing the Cloud
https://www.oreilly.com/ideas/linux-performance-tracing-the-cloud
28. 서버 단에서 봐야하는 자원 병목 포인트
DRAM DRAM
Disk Disk Port Port
CPU
Interconnect
Memory
Bus
CPU
2
Expander Interconnect
Network
Controller
CPU
1
I/O Bus
I/O
Bridge
I/O
Controller
Interface Transports
29. 60초안에 서버 성능 보기.
http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
load averages
kernel errors
overall stats by time
CPU balance
process usage
disk I/O
memory usage
network I/O
TCP stats
check overview
30. 어려운 방법보다 USE 메소드를 이용.
Saturation
Utilization
X
Errors
Utilization : 얼만큼 자원을 썼는지?
Saturation : 얼마나 많은 부하(extra works)가 들어왔는지.
Error : 발생한 에러는?
31. USE 메소드의 예
Resource Type Metric
CPU utilization CPU utilization
CPU saturation run-queue length
Memory utilization Available memory
Memory saturation Paging or swapping
NetworkInterface utilization RX/TX tput / bandwidth
StorageDeviceI/O utilization Device busy percent
StorageDeviceI/O saturation Wait queue length
StorageDeviceI/O errors Device errors
49. 일반적인 해결책은
Static + Dynamic Profiling
User
MEM
CPU
GC
SQL
CONN
CONN
Static Profiling
Static Profiling
Static Profiling
1. 의심되는 메소드 지정
(Dynamic Profiling)
2. 의심되는 메소드 지정
4. 의심되는 메소드 지정
63. 3~4년 전 프론트엔드 (웹/모바일) 한국의
Enterprise 시장에서는 무슨 일이?
비용 절감 = Web App/ Hybrid App으로 가자.
Android, iOS, Web 언제 다 따로 만들어..
64. 대형 사건…
안드로이드 4.4 버전 이후부터
- Android Native 와 Chrome WebView의 분리.
안드로이드 5.0 이후부터.
- 타사 쿠키 차단, 혼합된 컨텐츠 차단
- HTML 문서 최적화를 통해 그릴 수 있는 부분만 지능적 선택(??)
WebView 컴포넌트 배포 권한은 구글이..
- 왜 네이버는 별도의 브라우저를 만들었을까?
68. S 은행은 발빠르게 2채널 전략
- 많은 기능, 다양한 상품은 Native로
- 간단한 것들은 Web View 로…
다른 은행들의 차세대의 중심이 모바일로 재편
- K은행
- G은행 등 차세대 준비.
2,3 금융권은 웹뷰와 네이티브가 병행
다른 은행 (1 금융권)들은..
80. Paint (GPU 개입)
각 요소에 배경색, 글자 색과 같이 픽셀을 채우는 과정입니다.
레이아웃 트리를 순회하며 페인트 기록을 생성
81. 핵심 변경을 흡수
DOM 구성부터 페인팅 까지 열심히
작업해서 화면에 표시.
브라우저를 스크롤하거나 줌하거나
자바스크립트 코드로 문서를 변경해
버리면, 다시 이미지를 렌더링
그래서 다 그리지 않고, 변경된 내용만
다시 그리는 것이 필요.
Reflow Render Tree 부분 재구성
82. 핵심 변경을 흡수
Reflow (Render Tree 재구성) 가 일어나는 대표적인 경우
- 페이지 초기 렌더링 시(최초 Layout 과정)
- 윈도우 리사이징 시 (Viewport 크기 변경시)
- 노드 추가 또는 제거
- 요소의 위치, 크기 변경
(left, top, margin, padding, border, width, height 등..)
- 폰트 변경 과(텍스트 내용) 이미지 크기 변경(크기가 다른 이미지로 변
경 시)
Repaint (Render Tree를 다시 화면에 그려주는 과정)
- 레이아웃에는 영향을 주지 않는 스타일 속성만 변경 시 Repaint만 수행
(background-color, visibility..)
85. 더 성능을 끌어올리기 위해 Compostion도입
유효성 검사로만으로는 성능개선의 어려움
화면을 구성하는 요소를 레이어 별로 쪼개서 이미지를 만든 뒤 화면에 합
쳐서 표현하는 방법을 '레이어 합성’.
일부 이미지 변경으로 전체를 다시 그리기보다 일부 레이어만 다시 그리기
86. 꽉찬 화면 이면 어떻게 하나? (Tiling – 타일링 / Layer Tiling)
화면을 거의 차지하는 스크롤 레이어가 있다면 레이어가 너무 커서 레이어 합성의 효과가 미미
한개의 레이어를 더 작은 단위인 타일로 쪼개고 타일의 위치나 특성에 따라 우선순위를 매겨 각 타일별 이
미지를 만듭니다
87. Web Browser 랜더링 프로세스
출처) 모질라 퀀텀 CSS 엔진 - https://cutt.ly/5maHEKM
88. 브라우저기준의 성능 측정하기
DOMContentLoaded 이벤트
HTML과 CSS 파싱이 끝나는 시점
렌더 트리를 구성할 준비가 된(DOM 및 CSSOM 구성이 끝난) 상황
load 이벤트
HTML 상에 필요한 모든 리소스가 로드된 시점
89. 크롬 개발자 도구에서 보면..
DOM 구성 1.79초, 화면 리소스가 로드된 시점 2.3초
93. 사용자 입장에서의 지표. (이후 반영 예정)
FP(First Paint)
흰 화면에서 화면에 무언가가 처음으로 그려지기 시작하는 순간.
FCP(First Contentful Paint)
텍스트나 이미지가 출력되기 시작하는 순간.
FMP(First Meaningful Paint)
사용자에게 의미 있는 콘텐츠가 그려지기 시작하는 첫 순간. 콘텐츠를 노출하는데
필요한 CSS, 자바스크립트 로드가 시작되고 스타일이 적용되어 주요 콘텐츠를 읽을
수 있다.
TTI(Time to Interactive)
자바스크립트의 초기 실행이 완료되어서 사용자가 직접 행동을 취할 수 있는 순간
이다.
108. 성능 저하 후보군 (WebView 랜더링) - K사 사례
• 웹뷰 화면 로딩 시간이 오래 걸림
• 50%의 사용자는 2.2초 내에 응답을 받으나 하위 5% 사용자는 7초 이상의 화면 로딩 시간이 걸림
(즉 100명중에 5명은 7초 이상의 화면 랜더링 시간이 걸림)
109. xxx.com/mweb/event/eventView/EVT*MARED.do
• 화면 js 다운로드 시간이 오래 걸림
내부 웹 서버에서 통신해서 받는 것으로 보이며 대기보다는 다운로
드시간이 많이 걸림
• 이미지 다운로드 문제
이미지 다운로드 시간이 20초 이상 걸림
대기 시간이 18초 이상 소요 / 실 다운로드는 2초
• 해결 방안
.(영속적으로 계속 사용하는 라이브러리라면) 주요 라이브러리는 앱
에 임포트 시켜서 배포하는 형태를 권장함
웹뷰 화면 로딩 시간 지연 케이스 – JS 다운로드 이슈
111. https://xxx.com/mweb/cart/cart_normal.do
• Facebook Event 로 정보를 전송 중에 오류가 발생함.
내부적인 문제보다는 외부 Facebook의 이슈로 보이며 다른 회사에서도 종종 발생하는 문제
실제 많은 모바일 앱이 kakao id 로그인, 외부 서비스와 연동 인터페이스 오류로 많이 지연됨.
• SNS와 같은 Third Party 연동의 경우 native 영역으로 바꿀수 있을지 체크 필요
웹뷰 화면 로딩 시간 지연 케이스 예시 – 외부 라이브러리 이슈
112. 참고자료
• 렌더러 프로세스의 내부 동작
https://d2.naver
.com/helloworld/5237120
• 크롬 랜더링 이해하기 - https://cutt.ly/hmaGzHW
• Reflow, Repaint 성능 최적화 - https://boxfoxs.tistory.com/408
• 웹 성능 최적화 - https://ui.toast.com/fe-guide/ko_PERFORMANCE
• 성능 최적화 - https://ui.toast.com/fe-guide/ko_PERFORMANCE