-
웹 성능 진단하기네트워크 & 인프라 2022. 4. 14. 11:39
이번엔 미션을 통해서 배포한 사이트의 성능을 진단하고 성능을 개선키도록 하였다.
먼저 웹 성능 진단을 알아보자.
서비스의 상태 진단
우선 서비스의 상태진단은 전구간, 인터넷구간, 브라우저 렌더링을 제외한 전 구간으로 실행할 수 있고 각각의 상태진단 방법은 다음과 같다.
- 전구간 : 브라우저로 직접 QA
- 인터넷 구간 : webpagespeed등의 도구
- (브라우저 렌더링을 제외한) 전구간 : 부하테스트
가용성과 성능
먼저 가용성이란 시스템이 서비스를 정상적으로 제공할 수 있는 상태로 가용성을 높이기 위해선 단일 장애점(SPOF -> 서버장비가 장애 날 경우 서비스가 중단)를 없애고 다중화를 이용하여 장애가 발생하여도 시스템 기능을 계속할 수 있는 장애내성을 기르고 확장성 있는 서비스를 만들어야 한다. 성능이란 얼마나 많은 사람이 사용할 수 있는지 (Users), 일정시간동안 얼마나 많이 처리할 수 있는지 (TPS), 서비스가 얼마나 빠른지 (Time) 으로 측정될 수 있다.
처리량 (TPS)
처리량은 서비스 처리 건수 / 측정 시간 = 요청 사용자 수 / 평균 응답 시간 = 동시 사용자 수 / 서비스 요청 간격 으로 계산되어 진다. 사용자가 많아질 수록 처리량이 증가하는데 더이상 이를 처리하지 못하는 지점이 발생되어 TPS는 어느지점에서 유지되며 처리 시간은 증가하는 모습을 보이게 된다. 이 지점이 서버가 처리할 수 없어 누적되는 작업량이 늘어나 응답시간이 급격하게 증가하는 부분으로 우리가 stress테스트를 통해 파악하려하는 한계점이다.
늘어나는 처리량(TPS)을 해결하기 위해서 서버를 증설하는 scale out 과 서버 리소스 스펙자체를 올리는 scale up 이 존재한다. 성능에 문제가 있는 경우에는 단일 사용자에 대한 응답 속도가 느려지지만, 확장성에 문제가 있는 경우에는 당장은 문제가 없지만 부하가 많아질 경우 응답속도가 느려진다.
처리량을 늘리기 위해서는 단일 사용자에 대해 먼저 scale up을 통해 속도를 늘리고 더 필요하다면 scale out을 통해 속도를 증가시키도록 한다.
Users
- 시스템 관리자의 관점 : 등록된 사용자 vs 등록되지 않은 사용자
- 서버의 관점 : 로그인 한 사용자(세션) vs 로그인하지 않은 사용자
- 성능 테스트의 관점 : Concurrent User(부하를 줄 수도 있는 사용자) vs Active User (부하를 주고 있는 사용자=계속해서 요청)
시간
사용자에겐 응답시간만 존재하지만 실제 서비스에서는 사용자가 요청에 대해서 응답을 받은 후에 웹 페이지를 보는 드으이 작업을 하는 Think time이 존재한다. 인터넷 구간은 webPageTest등을 통해서도 확인할 수 있다. 브라우저와 웹 서버간 에서는 정적파일 크기, Connection 관리, 네트워크 환경 등의 영향을 받을 수 있고, server 구간 의 문제는 서버의 리소스 문제, 프로그램 로직상의 문제, DB 혹은 다른 서비스와의 연결문제로 발생할 수 있다. 네트워크 이슈의 경우 테스트를 진행하는 환경에 따라 달라질 수 있으므로 요청을 많이받는 테스트 대상을 잘 선택하여야 한다.
웹 성능 진단 및 목표값 설정
https://pagespeed.web.dev/?utm_source=psi&utm_medium=redirect
위의 사이트를 통해서 현재 웹사이트에서 부족한 부분을 확인할 수 있다.
- Security Score : TLS 및 HTTP 헤더 보안성 + JS 라이브러리 보안 취약성
- First Byte Time : 서버 응답시간 + 네트워크 비용 ( 웹서버에서 받은 첫번째 바이트가 얼마만에 도착하는지)
- Keep-Alive Enabled : 매번 3 way handShake 덩의 과정(TCP연결)을 거쳐 Connection을 생성하지않고 재사용 하는지
- Compress Transfer : gzip 압축 여부 (스크립트 파일이 Content-Encoding으로 압축 되어 있는지)
- Compress Image: 이미지 압축 여부 (사용자는 이미지 품질 차이보다 네트워크 지연에 더 민감하다)
- Cache Static Content : JS, CSS, 이미지, 웹 폰트 등 정적 컨텐츠 캐싱 여부 (불필요한 요청수 감소)
- CDN : CDN 여부 (가까운데서 받는 것이 효율적)
현재 웹사이트 결과는 다음과 같았다.
https://www.webpagetest.org/result/220325_BiDc1R_8GW/3/performance_optimization/
다음은 서울교통공사와 카카오, 네이버, 현재 앱인 지하철사이트의 성능을 분석한 표이다.
성능 71 94 91 67 First Byte 1.503S 1.208S .803S 1.038S First View 7.160s 5.619s 3.213s 7.256s First Contentful Paint 3.784S 1.696S 2.165S 6.133S Speed Index 4.446S 4.235S 6.050S 6.119S Largest Contentful Paint 5.551S 3.270S 7.119S 6.298S Cumulative Layout Shift .001 .004 .037 .004 Total Blocking Time 1.071S .000S .006S .000S Total Byte 1,365KB 1,564KB 774KB 2,493KB Time To Interactive 2.0S 0.6S 1.0S 2.8S 위의 결과를 통해서 다음과 같이 목표값을 설정할 수 있다. 웹 성능 예산은 정량 / 시간 / 규칙 기반으로 설정할 수 있다.
- 정량
- 이미지 최대 크기, 웹 글꼴 최대 크기, 스크립트 최대 크기, 스크립트 최대 갯수, HTML, CSS 최대 크기, 동영상 최대 크기 등
- 시간
- FCP, LCP, TTI, TBT, CLS 등 page speed 에서 제공되는 데이터
- 정량
- webPageTest, pagespeed 등 웹 사이트에서 측정한 점수를 지표로 사용
여기서 중요한 점은 3초의 법칙 (3초안에 로딩되지 않으면 53%의 사용자가 떠난다)과 다른 사이트보다 20%이상 차이가 나게 되면 사용자가 그 차이를 인식 할 수 있으므로 차이값을 그 이내로 만족하도록 하는 것이다.
- Light house : (71+94+91)/3 = 85.33 -> 85점 이상
- FCP : (3.784+1.696+2.165)/3 = 2.548 -> 3.05초 이내 (평균값과 20% 차이 이내)
- SI : (4.446+4.235+6.050)/3 = 4.91 -> 5.892초 이내 (평균값과 20% 차이 이내)
- TTI : (2.0+0.6+1.0)/3 = 1.2 -> 1.44초 이내 (평균값과 20% 차이 이내)
- First View : (7.160+5.619+3.213)/3 = 5.33 -> 6.396초 이내 (평균값과 20% 차이 이내)
- LCP : (5.551+3.270+7.119)/3 = 5.31 (만족)
- CLS : (.001+.004+.037)/3 = 0.016 (만족)
( 참고한 사이트 )
NextStep 프로젝트 공방
'네트워크 & 인프라' 카테고리의 다른 글
서버 진단하기 ( + 로깅, 모니터링) (0) 2022.04.14 부하 테스트 ( + k6, grafana + influxdb, ngrinder) (0) 2022.04.14 AWS 망 구성하고 서비스 배포하기 (0) 2022.03.28 Mac에서 docker, docker machine, virtualbox설치하기 (0) 2022.03.28 통신 확인하기 (0) 2022.03.23