Docker로 Webpagetest private instance 구성하기


다들 잘 알고 있는 FE성능 분석 사이트인 webpagetest.org 를 docker를 이용하여 편리하게 private instance를 구성하는 방법을 해보자.

팀내에 구성해놓으면 여러모로 나름 쓸모가 있고

sitespeed.io의 Dashboard와 연계해서 사용해도 나름 나쁘지 않다.

Local WebPagetest Using Docker 의 내용을 기준으로 번역 및 짧게 요약.

Docker 실행환경 준비

대부분 맥을 사용한다고 생각하고 아래 URL에서 Docker 를 다운로드 받아 설치하면 된다.

https://docs.docker.com/docker-for-mac/install/

설치가 완료되면 상단 Docker(고래모양 Toolbox가 나오게 되는데 )

눌러보면 현재 Docker의 상태를 알수 있다.

Docker Container 설정.

WebPageTest는 Server와 Agent로 나누어 진다. Agent가 다양할수록 여러 브라우저에서 테스트가 가능하다.

Server : https://hub.docker.com/r/webpagetest/server/

Agent : https://hub.docker.com/r/webpagetest/agent/


$ docker pull webpagetest/server
$ docker pull webpagetest/agent

Docker Container 실행

Server -> Agent 순으로 구동을 시켜야만 한다.

Server 구동

# -d background 모드로 실행한다고 생각하면 된다. 이걸 사용안하면 표준출력을 그대로 보게 된다.
# -p 포트지정.(4000 port외에 자유지정 가능.)
# --rm Docker를 종료할때 컨테이너가 자동으로 제거되도록 한다.
$ docker run -d -p 4000:80 --rm webpagetest/server

http://localhost:4000 에 접속하여 확인가능

Agent 구동

# --network="host" 에이전트가 서버 컨테이너와 통신 할 수 있게한다.
# -e SERVER_URL을 지정안하면 Agent 구동시 에러가 발생한다.
# 위에서 Server구동시 4000포트를 바꾸었다면 아래 SERVER_URL의 port를 바꾸어 준다.
# 여기서도 -p 시 포트는 자유지정 가능하다.

$ docker run -d -p 4001:80 \
   --network="host" \
   -e "SERVER_URL=http://localhost:4000/work/" \
   -e "LOCATION=Test" \
  webpagetest/agent

구성 확인하기

기본으로 따라하였다면 http://localhost:4000 접속시 화면이 보일 것이다.

http://localhost:4000/install 을 들어가보면 설치 상태를 확인할 수 있다.

Mac OS의 경우 Traffic Shaping 지원불가로 인해 추가 작업 필요.

제목과 Mac에서는 Traffic Shaping 지원 불가로 테스트 해보면 실행이 되지 않는다.. ㅠㅠ

따라서 아래 작업이 필요하다.

SERVER

디렉토리를 생성해서 아래 두 파일을 만들고 build를 수행한다.

참고로 Dockerfile은 어떤이미지에 어떠한 행위를 하겠다고 기술해 놓는 파일이다.

아래 Dockerfile내용을 보면 webpagetest/server 이미지에 "/var/www/html/settings/" 위치에 locations.ini 파일을 추가 하라는 뜻으로 해석하면 된다.

Dockerfile 파일

FROM webpagetest/server
ADD locations.ini /var/www/html/settings/

locations.ini 파일


[locations]
1=Test_loc
[Test_loc]
1=Test
label=Test Location
group=Desktop
[Test]
browser=Chrome,Firefox
label="Test Location"
connectivity=LAN

도커파일 빌드.

# 도커파일 빌드
$ docker build -t local-wptserver .

Agent

디렉토리를 생성해서 아래 2 파일을 만들고 build를 수행한다.

Dockerfile


FROM webpagetest/agent
ADD script.sh /
ENTRYPOINT /script.sh

script.sh


#!/bin/bash
set -e
if [ -z "$SERVER_URL" ]; then
 echo >&2 'SERVER_URL not set'
 exit 1
fi
if [ -z "$LOCATION" ]; then
 echo >&2 'LOCATION not set'
 exit 1
fi
EXTRA_ARGS=""
if [ -n "$NAME" ]; then
 EXTRA_ARGS="$EXTRA_ARGS --name $NAME"
fi
python /wptagent/wptagent.py --server $SERVER_URL --location $LOCATION $EXTRA_ARGS --xvfb --dockerized -vvvvv --shaper none

쉘 권한 추가 및 도커파일 빌드


# 실행권한
$ chmod u+x script.sh
# 도커파일 빌드
$ docker build -t local-wptagent .

기존 컨테이너 종료

$ docker ps
CONTAINER ID       IMAGE
5e2374829136       webpagetest/agent
1cf57d494fc8       webpagetest/server
$ docker stop 5e2374829136
$ docker stop 1cf57d494fc8

컨테이너 실행

$ docker run -d -p 4000:80 local-wptserver
$ docker run -d -p 4001:80 \
   --network="host" \
   -e "SERVER_URL=http://localhost:4000/work/" \
   -e "LOCATION=Test" \
  local-wptagent

Docker로 Webpagetest private instance 구성하기




다들 잘 알고 있는 webpagetest.org 를 docker를 이용하여 편리하게 private instance를 구성하는 방법을 해보자.

팀내에 구성해놓으면 여러모로 나름 쓸모가 있고

sitespeed.io의 Dashboard와 연계해서 사용해도 나름 나쁘지 않다.

Local WebPagetest Using Docker 의 내용을 기준으로 번역 및 짧게 요약.

Docker 실행환경 준비

대부분 맥을 사용한다고 생각하고 아래 URL에서 Docker 를 다운로드 받아 설치하면 된다.

https://docs.docker.com/docker-for-mac/install/

설치가 완료되면 상단 Docker(고래모양 Toolbox가 나오게 되는데 )

눌러보면 현재 Docker의 상태를 알수 있다.

Docker Container 설정.

WebPageTest는 Server와 Agent로 나누어 진다. Agent가 다양할수록 여러 브라우저에서 테스트가 가능하다.

Server : https://hub.docker.com/r/webpagetest/server/

Agent : https://hub.docker.com/r/webpagetest/agent/


$ docker pull webpagetest/server
$ docker pull webpagetest/agent

Docker Container 실행

Server -> Agent 순으로 구동을 시켜야만 한다.

Server 구동

# -d background 모드로 실행한다고 생각하면 된다. 이걸 사용안하면 표준출력을 그대로 보게 된다.
# -p 포트지정.(4000 port외에 자유지정 가능.)
# --rm Docker를 종료할때 컨테이너가 자동으로 제거되도록 한다.
$ docker run -d -p 4000:80 --rm webpagetest/server

http://localhost:4000 에 접속하여 확인가능

Agent 구동

# --network="host" 에이전트가 서버 컨테이너와 통신 할 수 있게한다.
# -e SERVER_URL을 지정안하면 Agent 구동시 에러가 발생한다.
# 위에서 Server구동시 4000포트를 바꾸었다면 아래 SERVER_URL의 port를 바꾸어 준다.
# 여기서도 -p 시 포트는 자유지정 가능하다.

$ docker run -d -p 4001:80 \
   --network="host" \
   -e "SERVER_URL=http://localhost:4000/work/" \
   -e "LOCATION=Test" \
  webpagetest/agent

구성 확인하기

기본으로 따라하였다면 http://localhost:4000 접속시 화면이 보일 것이다.

http://localhost:4000/install 을 들어가보면 설치 상태를 확인할 수 있다.

Mac OS의 경우 Traffic Shaping 지원불가로 인해 추가 작업 필요.

제목과 Mac에서는 Traffic Shaping 지원 불가로 테스트 해보면 실행이 되지 않는다.. ㅠㅠ

따라서 아래 작업이 필요하다.

SERVER

디렉토리를 생성해서 아래 두 파일을 만들고 build를 수행한다.

참고로 Dockerfile은 어떤이미지에 어떠한 행위를 하겠다고 기술해 놓는 파일이다.

아래 Dockerfile내용을 보면 webpagetest/server 이미지에 "/var/www/html/settings/" 위치에 locations.ini 파일을 추가 하라는 뜻으로 해석하면 된다.

Dockerfile 파일

FROM webpagetest/server
ADD locations.ini /var/www/html/settings/

locations.ini 파일


[locations]
1=Test_loc
[Test_loc]
1=Test
label=Test Location
group=Desktop
[Test]
browser=Chrome,Firefox
label="Test Location"
connectivity=LAN

도커파일 빌드.

# 도커파일 빌드
$ docker build -t local-wptserver .

Agent

디렉토리를 생성해서 아래 2 파일을 만들고 build를 수행한다.

Dockerfile


FROM webpagetest/agent
ADD script.sh /
ENTRYPOINT /script.sh

script.sh


#!/bin/bash
set -e
if [ -z "$SERVER_URL" ]; then
 echo >&2 'SERVER_URL not set'
 exit 1
fi
if [ -z "$LOCATION" ]; then
 echo >&2 'LOCATION not set'
 exit 1
fi
EXTRA_ARGS=""
if [ -n "$NAME" ]; then
 EXTRA_ARGS="$EXTRA_ARGS --name $NAME"
fi
python /wptagent/wptagent.py --server $SERVER_URL --location $LOCATION $EXTRA_ARGS --xvfb --dockerized -vvvvv --shaper none

쉘 권한 추가 및 도커파일 빌드


# 실행권한
$ chmod u+x script.sh
# 도커파일 빌드
$ docker build -t local-wptagent .

기존 컨테이너 종료

$ docker ps
CONTAINER ID       IMAGE
5e2374829136       webpagetest/agent
1cf57d494fc8       webpagetest/server
$ docker stop 5e2374829136
$ docker stop 1cf57d494fc8

컨테이너 실행

$ docker run -d -p 4000:80 local-wptserver
$ docker run -d -p 4001:80 \
   --network="host" \
   -e "SERVER_URL=http://localhost:4000/work/" \
   -e "LOCATION=Test" \
  local-wptagent

Posted by 다인,보리아빠
,


얼마전 회사 동료와 AWS의 CloudFront에 대해서 이야기하다 akamai의 CDN 서비스에서 최적경로를 찾아주는 방법에 대해서 이야기를 했었다.

서로 상반되는 부분이 있어서 정확하게 집고 넘어가는 것이 좋을 것 같아서 정리합니다.

결론부터 이야기하면 대부분 기본으로 세팅을 하는게 가장 빠르다.



기본적으로 CDN서비스를 사용하면 접속하는 User에게 가장 가까운(또는 가능빠른) 서버를 알려주게 된다.

이때 가장 가까운 서버를 알려주기 위해서는 CDN은 DNS 이용한다

대부분의 경우 사용자가 별도의 설정을 하지 않고 ISP를 통해서나 DHCP서버를 통하여 DNS 정보를 받게된다.

CDN의 DNS는 실제 요청자의 IP를 알수 없다.

다만 수없이 많은 DNS의 IP만을 알수 있다. 그중에 내가 사용하는 DNS도 있을 것이다.

CDN의 DNSDNS 매핑 테이블을 관리하여 요청하는 DNS의 IP별로 최적의 IP를 내려준다.

결국 PC에 설정되어 있는 DNS의 IP별로 최적의 서버로 할당을 해주는 구조이다.

따라서 Local DNS를 엄한 곳으로(예 : 거리상으로 먼곳에 있는 DNS) 설정을 하면 엄한곳에서 가장 가까운 IP를 알려줄테니 대역폭은 몰라도 레이턴시가 좋지 않게된다.

지속적인 다운로드가 아닌 이상 일반적인 웹페이지에서는 레이턴시는 매우 중요한 요소이다.

어느 이상의 속도가 되면 대역폭은 큰의미가 없다.

레이턴시는 빠르면 빠를수록 웹페이지가 뜨게된다.



아래 이미지를 보면 대역폭(상단), 레이턴시(하단)의 성능에 따라 페이지 로딩 시간의 차이를 보여준다.

그만큼 웹서비스에서는 레이턴시가 중요하다.

구글엔지니어에게듣는 네트워킹과 웹 성능 최적화 기법 책중

http://chimera.labs.oreilly.com/books/1230000000545


우리가 크롬 브라우저로 ebay에 접속할때 domain으로 ip를 찾는 순서를 보자.

~ www.ebay.com 을 누르면 아래방법으로 순차적으로 IP를 찾아내서 실제 접속은 IP로 하게 된다.

  1. 브라우저 : 현재 caching하고 있는 DNS인지 확인한다.

  2. /etc/hosts

    • 기본적으로 /etc/hosts등에 특수한 경우에 대해서 domain과 ip를 매핑해놓는다.

    • 예 : 127.0.0.1 localhost

    • 127.0.0.1는 루프백 IP로 현재 컴퓨터를 뜻한다.

  3. resolev.conf 에 설정된 NameServer에 질의 요청을 한다.


테스트할 DNS

SK Broadband (브로드밴드) 현재 사용중인 ISP기본 DNS 서버 주소 - 210.220.163.82

KT DNS기본 DNS 서버 주소 - 168.126.63.1

Google Public (구글 퍼블릭)기본 DNS 서버 주소 - 8.8.8.8

조회된 IP별 레이턴시 비교

SKB -> round-trip min/avg/max/stddev = 3.834/5.170/7.445/1.112 ms

KT -> round-trip min/avg/max/stddev = 4.373/7.757/22.246/5.128 ms

GOOGLE - round-trip min/avg/max/stddev = 65.981/68.006/71.258/1.896 ms

정리하면

속도는 SKB -> KT -> GOOGLE 순으로 나왔다.

아마 KT 사용자였다면 KT -> SKB -> GOOGLE순으로 나왔을 것이다.

결과적으로 아카마이가 최단거리 서버를 잘 찾아준 것을 알수 있다.

실험 1 DNS에 따른 www.ebay.com 조회 결과(저는 브로드밴드사용자)

$ nslookup
> www.ebay.com
Server: 192.168.11.1
Address: 192.168.11.1#53

Non-authoritative answer:
www.ebay.com canonical name = slot9428.ebay.com.edgekey.net.
slot9428.ebay.com.edgekey.net canonical name = e9428.b.akamaiedge.net.
Name: e9428.b.akamaiedge.net
Address: 210.205.4.6

> server 168.126.63.1
Default server: 168.126.63.1
Address: 168.126.63.1#53
> www.ebay.com
Server: 168.126.63.1
Address: 168.126.63.1#53

Non-authoritative answer:
www.ebay.com canonical name = slot9428.ebay.com.edgekey.net.
slot9428.ebay.com.edgekey.net canonical name = e9428.b.akamaiedge.net.
Name: e9428.b.akamaiedge.net
Address: 104.76.90.106

> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> www.ebay.com
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
www.ebay.com canonical name = slot9428.ebay.com.edgekey.net.
slot9428.ebay.com.edgekey.net canonical name = e9428.b.akamaiedge.net.
Name: e9428.b.akamaiedge.net
Address: 104.124.245.241

실험2. 조회결과별 ping 10회 테스트

해당 테스트를 통해 round-trip(레이턴시) 이곳에서 해당 목적지까지 패킷이 다녀온 시간을 잰다.


$ ping 104.76.90.106 -c10
PING 104.76.90.106 (104.76.90.106): 56 data bytes
64 bytes from 104.76.90.106: icmp_seq=0 ttl=52 time=7.281 ms
64 bytes from 104.76.90.106: icmp_seq=1 ttl=52 time=4.755 ms
64 bytes from 104.76.90.106: icmp_seq=2 ttl=52 time=5.073 ms
64 bytes from 104.76.90.106: icmp_seq=3 ttl=52 time=7.184 ms
64 bytes from 104.76.90.106: icmp_seq=4 ttl=52 time=6.049 ms
64 bytes from 104.76.90.106: icmp_seq=5 ttl=52 time=4.373 ms
64 bytes from 104.76.90.106: icmp_seq=6 ttl=52 time=10.428 ms
64 bytes from 104.76.90.106: icmp_seq=7 ttl=52 time=22.246 ms
64 bytes from 104.76.90.106: icmp_seq=8 ttl=52 time=4.593 ms
64 bytes from 104.76.90.106: icmp_seq=9 ttl=52 time=5.587 ms

--- 104.76.90.106 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.373/7.757/22.246/5.128 ms


$ ping 104.124.245.241 -c10
PING 104.124.245.241 (104.124.245.241): 56 data bytes
64 bytes from 104.124.245.241: icmp_seq=0 ttl=52 time=68.003 ms
64 bytes from 104.124.245.241: icmp_seq=1 ttl=52 time=67.227 ms
64 bytes from 104.124.245.241: icmp_seq=2 ttl=52 time=66.554 ms
64 bytes from 104.124.245.241: icmp_seq=3 ttl=52 time=71.258 ms
64 bytes from 104.124.245.241: icmp_seq=4 ttl=52 time=69.599 ms
64 bytes from 104.124.245.241: icmp_seq=5 ttl=52 time=67.738 ms
64 bytes from 104.124.245.241: icmp_seq=6 ttl=52 time=65.981 ms
64 bytes from 104.124.245.241: icmp_seq=7 ttl=52 time=71.142 ms
64 bytes from 104.124.245.241: icmp_seq=8 ttl=52 time=65.984 ms
64 bytes from 104.124.245.241: icmp_seq=9 ttl=52 time=66.578 ms

--- 104.124.245.241 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 65.981/68.006/71.258/1.896 ms

Posted by 다인,보리아빠
,



sitespeed.io가 4가 2016년에 새로 릴리즈 되면서
여러가지 편의 기능들이 많이 추가 되어 정리 및 구현.


최근 보니 2016-10-27일에 V4가 나온후 2017-02-14일 v4.4까지 나온것 보면 요즘 필받아서 연신 기능 추가가 되고 있네요. 

 

https://www.sitespeed.io/


  • Installation
    • npm (현재 pc 브라우저를 활용하여 데이타 수집)
    • docker(컨테이너내 FFmpeg)
      • 데이타 시각화를 graphite, grafana 연동 제공
      • docker-compose을 이용한 graphite, Grafana, sitespeed.io 간편설치(5분) <--추천.

        • 설치 안내 URL : https://www.sitespeed.io/documentation/sitespeed.io/performance-dashboard/#docker-compose-file

  • 특징
    • chrome, firefox 지원
    • 반복실행(repeat test)
    • 대역폭 제어(TSProxy)
    • 레이턴시 제어
    • Selenium script 지원
    • User Agent지정 가능
    • Video 지원(로딩영상 캡처)
    • 크롤러지원으로 N depth 자동측정 가능(Simple crawler)
    • graphite - > View grafada 지원으로 지속적인 사이트/페이지 추이 측정 가능.
    • Slack 지원(결과에 대해서 지속적으로 슬랙에 제공 가능)
    • sitespeed이외 측정 연동 가능
      • Google Page Speed Insight 지원
      • webpagetest 연동지원(Private Instance)

 

  • graphite (그라파이트)
    •  시간과 데이타를 쌓아가는 데이타 저장소
    • Graphite-web 제공하여 대시보드를 제공함.

 

  • Grafana (그라파나)
    •  다양한 DB 지원(엘라스틱서치,인플럭스등그라파이트)
    •  먼가 있어 보이는 대시보드

 

  • 사용예 : 
    1. 사이트에 대해서 자동 n-depth 실행
    2. URL 명기한 파일을 실행시 추가.
    3. Config 만들어서 추가.(측정페이지 ,브라우저대역,레이턴시,에이전트등)
    4. 로그인이 필요한 경우 preScript 추가.

 

  • 결과보기.
    • 실행시 기본적으로 sitespeed.io result 페이지들 작성(폴더구분).
    • graphite 연동시 지속적으로 대시보드에서 확인 가능.
    • 데이타의 경우 sitespeed.io 리포팅이  세세하게   있음.(추이는 보기 힘듬)
    • grafana 경우 전반적인 추이를 보는데 용이.

 

후기.

  • grafana 어느정도 데이타를 보여줄수 있는지는   찾아봐야 .
  • sitespeed 동영상에서 한글이깨진채로 나옴(해당 도커 컨테이너에 한글언어팩이  설치되어 있는듯함.

 

총평

  •  사이트/페이지가 전체적으로 너무 heavy 지지 않도록 어느정도 전반적인 추이를 가끔 보기에 깔끔하고 좋을  같음.
  •  성능의 경우 11번가에서도 handlebarjs  이용 초기 로딩  데이타를 그리는 부분들도 있어 실제 사용자가 보는 것과
    측정 결과와는 갭이 있을  있음.
  • 현재 11번가 같은 경우에도 리소스가 많이 분산되어 있으므로 front단에서 데이타를 모아 보여주고 데이타를 쌓아놓는것이
    나쁘진 않을  같다는 생각이 듭니다.
  • Frontend 성능측정 툴이나 사이트가 많긴 그리 나쁜 구성은 아닌듯 .
  • 구성을 한다면 webpagetest의 compare 기능이 있으면 좋을 듯함.

 

구성 예시

  • webpagetest private instance -> compare 기능을 위해.
  • sitespeed.io + (graphite + grafana) -> CLI + 대시보드 때문.

 

site 요약


페이지 요약






webpagetest결과





 


 


 



Posted by 다인,보리아빠
,

Chrome Extention App 을 이용하여 성능측정을 통해 튜닝포인트를 찾는 것을 해보았다.


Google의 PageSpeed 제품 성능 측정은 현재 3가지 방법을 제공한다.

1. Browser Extention App

2014/10/31 - [튜닝/성능측정] - Chrome PageSpeed를 이용한 Front-End 성능측정

2. PageSpeed Insights 사이트를 이용하는 방법

2014/10/31 - [튜닝/성능측정] - PageSpeed insights를 이용한 성능측정

3. PageSpeed openapi를 이용



그럼 PageSpeed insights 사이트에 대해 간단히 알아보자.


장점

1. 데스크탑과 모바일을 한번에 확인할 수 있다.

2. 모바일 측정 결과에 사용자 환경에 대한 UX 적인 측정이 가능하다.(그렇게 디테일하진 않다.)


단점

1. User Agent와 같은 것을 변경하여 처리할 수 없다.


사용 방법

1. PageSpeed insights 에 접속
URL : https://developers.google.com/speed/pagespeed/insights/
측정하고자 하는 URL 을 입력 후 분석 버튼을 누른다.


2. 결과 값으로 아래와 같이 모바일 페이지의 대한 측정/사용자 환경에 대한 측정 스코어와 개선 사항을 제안해 준다.
추가적으로 캡처 화면을 제공하여 사용자가 좀 더 명확하게 알 수 있도록 제공한다.


3. 데스크톱 탭을 선택하면 데스크톱 단에서 나온 측정 스코어와 개선안을 제안해준다.




Posted by 다인,보리아빠
,

Chrome PageSpeed는  특정 페이지의 Front-End 단 튜닝 요소를 찾아주는 확장앱이다.

예전에는 스코어도 주었는데 Chrome Extention App에서는 현재 스코어는 빠져 있다.

특정 페이지(예: 메인 페이지)에 대해서 Front-End 단에 튜닝이 필요한 부분에 대해서 

상,중,하로 구분하여 보여주어 사용자가 우선적으로 처리해야 하는 부분과 방법을 제공한다.


사용법을 간단하며 아래와 같다.


1. 크롬 앱스토어에서 PageSpeed Insights 를 검색하여 설치.


2. Chrome 도구메뉴에서 개발자 도구를 선택한다.(windows는 F12, Mac CMD + option + i)


3. 개발자 도구 메뉴중 PageSpeed를 선택 한 후 분석 시작 버튼을 누르면 해당 페이지를 분석한다.

4. 분석이 완료되면 아래와 같이 결과값을 보여준다.
제안사항 요약을 보면 H,M,L 로 구분하여 튜닝이 필요한 부분에 대해서 제안한다.

각각의 부분을 누르면 상세 내용을 제공하므로 항목별로 눌러서 확인해보면 된다.


5. 제안내용 외에 이미 처리 되어 있는 부분은 아래와 같은 항목들이 있다. 실제 튜닝을 하지 않았다면 상당부분이 미 완료 되어 있는 것을 확인할 수 있다. 


Posted by 다인,보리아빠
,