웹 서버 포퍼먼스 튜닝 [2] – 웹성능 체크

앞내용에 이어서 튜닝이 필요한 상황인지를 파악하는 단계로 웹성능

체크와 웹 부하률 체크에 대해 다루겠습니다.

3. 웹 부하량 체크 방법

제대로된 튜닝을 하기 위해서는 우선 자신의 네트워크 및 시스템에 대한 부하를 체크할 필요가

있다.

여기서는 네트워크 및 웹 서버에 대한 종합적인 부하량 측정 방안을 알아보겠다.

가. 네트워크 부하량 체크

Traceroute (ftp://ftp.ee.lbl.gov/traceroute.tar.Z)

네트워크 연결 경로에 대한 라우팅 홉(HOP)지점마다의 주소와 그 속도를 측정할수 있는

유틸리티로 Linux의 경우 기본적으로 설치되어 있다.

– Sample –

[root@ns named]# traceroute -q 3 www.netkiller.com

## www.netkiller.com 에 대한 각 지점간 연결 속도를 3번씩 측정

traceroute to www.netkiller.com (210.103.183.35), 30 hops max, 40 byte packets

1 204.252.144.146 (204.252.144.146) 1.465 ms 1.433 ms 1.419 ms

2 210.116.126.41 (210.116.126.41) 17.030 ms 17.389 ms 357.989 ms

3 203.235.126.250 (203.235.126.250) 132.341 ms 18.414 ms 19.626 ms

4 210.103.227.38 (210.103.227.38) 203.928 ms 206.006 ms 179.701 ms

5 210.103.183.35 (210.103.183.35) 243.521 ms 24.088 ms 20.738 ms

Ping

양 끝단의 전체적인 속도 및 패킷 에러율을 체크하고자 할 경우 ping을 통해 일정량의 패킷을

보내어 다시 받을 때까지 걸리는 전체 시간과 패킷 손실율을 측정할 수 있다.

– Sample –

[root@ns named]# ping -c 10 www.netkiller.com

## www.netkiller.com 으로 총 10번의 ping을 실행한다.

PING www.netkiller.com (210.103.183.35): 56 data bytes

64 bytes from 210.103.183.35: icmp_seq=0 ttl=251 time=377.5 ms

64 bytes from 210.103.183.35: icmp_seq=1 ttl=251 time=417.6 ms

64 bytes from 210.103.183.35: icmp_seq=2 ttl=251 time=247.7 ms

64 bytes from 210.103.183.35: icmp_seq=3 ttl=251 time=367.1 ms

64 bytes from 210.103.183.35: icmp_seq=4 ttl=251 time=462.1 ms

64 bytes from 210.103.183.35: icmp_seq=5 ttl=251 time=957.6 ms

64 bytes from 210.103.183.35: icmp_seq=6 ttl=251 time=179.3 ms

64 bytes from 210.103.183.35: icmp_seq=7 ttl=251 time=77.0 ms

64 bytes from 210.103.183.35: icmp_seq=8 ttl=251 time=69.9 ms

64 bytes from 210.103.183.35: icmp_seq=9 ttl=251 time=498.8 ms

— www.netkiller.com ping statistics —

10 packets transmitted, 10 packets received, 0% packet loss

round-trip min/avg/max = 69.9/365.4/957.6 ms

이 경우 Avg Round-Trip time이 365.4 ms 가 나왔다.

일반적으로 자사의 라우터와 ISP간에 약 1,000 번의 ping 결과에서 에러율이 3~4% 미만이어야

한다.

netstat , ifconfig

서버의 전체적인 네트워크 패킷 충돌율을 체크할 경우 netstat – i 나 ifconfig -a

의 결과에서 직접 계산할 수 있다.

– Sample –

[root@ns named]# ifconfig -a

lo Link encap:Local Loopback

inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0

UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1

RX packets:99477 errors:0 dropped:0 overruns:0 frame:0

TX packets:99477 errors:0 dropped:0 overruns:0 carrier:0

collisions:0

eth0 Link encap:Ethernet HWaddr 00:10:5A:69:ED:92

inet addr:203.231.38.2 Bcast:203.231.38.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:813704 errors:0 dropped:0 overruns:0 frame:0

TX packets:646433 errors:0 dropped:0 overruns:0 carrier:0

collisions:17681

Interrupt:10 Base address:0xec00

여기서 lo는 로컬이므로 의미가 없으며, eth0란에서 Collisions수만큼의 충돌이 TX packets

(출력 패킷)에 대해 발생하였으므로 (17681/646433) X 100 을 통해 충돌율이 약 2.7%

라는것을

확인할수 있다.

보통 약 8% 이상의 충돌율을 보인다면 네트워크를 점검해 보아야 한다.

MRTG등의 네트워크 전문 유틸리티를 통한 부하량 체크

앞서 언급한 MRTG나 XNI 등의 부하량 및 패킷 전문 체크 프로그램을 이용하면 보다

시각적으로

패킷 에러와 속도를 측정할 수 있다.

– Sample http://www.xni.com –

나. 웹 성능 측정 방법들

time

time은 유닉스에서 프로그램의 실행 시간을 측정해주는 기본 명렁어이다. 웹 서버의 접속 및

첫

Source를 받아오는데 걸리는 시간을 정확히 측정하고자 한다면 아래와 같이 해볼수 있다.

– Sample –

[root@ns named]# time lynx -source http://www.netkiller.com > /dev/null

0.05user 0.05system 0:02.34elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k

0inputs+0outputs (1651major+639minor)pagefaults 0swaps

이것은 www.netkiller.com 의 웹 사이트에 lynx 브라우저로 접속하여 초기 웹 페이지의

source를

가져오는데 걸리는 총 시간을 측정한 결과인데, 소스의 경우 굳이 볼 필요가 없으므로

/dev/null로

보냈다. User : 0.05 , System : 0.05 그리고 총 실행 시간이 0:02.34 (2초 34) 가

걸렸으므로,

실제 접속 시간은 2.34 – (0.05 + 0.05) = 2.24초가 된다. 보다 정확한 측정을 위하여

위의 명령을 몇번 실행시켜 평균 시간을 측정하여야 될것이다. 특히 처음 접속은 DNS서버의

캐시를

이용하지 않기 때문에 가장 느릴수 있기 때문이다.

ApacheBench (http://www.zeustech.net/)

아파치 서버를 위한 전문 측정 툴이다. 이 유틸리티는 레드햇 5.2 정품 리눅스의 경우 기타

application CD에 RPM으로 함께 제공되고 있는데 상당히 세밀하게 웹 서버의 성능을 체크할수

있다.

– Sample –

[root@ns named]# ab

ab: wrong number of arguments

Usage: ab [options] [http://]hostname[:port]/path

Options are:

-n requests Number of requests to perform

-c concurrency Number of multiple requests to make

-t timelimit Seconds to max. wait for responses

-p postfile File containg data to POST

-T content-type Content-type header for POSTing

-v verbosity How much troubleshooting info to print

-V Print version number and exit

-k Use HTTP KeepAlive feature

-h Display usage information (this message)

[root@ns named]# ab -n 10 http://www.netkiller.com:80/

This is ApacheBench, Version 1.2

Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Copyright (c) 1998 The Apache Group, http://www.apache.org/

Server Software: Apache/1.3.1

Server Hostname: www.netkiller.com

Server Port: 80

Document Path: /

Document Length: 11417 bytes

Concurrency Level: 1

Time taken for tests: 16.625 seconds

Complete requests: 10

Failed requests: 0

Total transferred: 115460 bytes

HTML transferred: 114170 bytes

Requests per second: 0.60

Transfer rate: 6.94 kb/s received

Connnection Times (ms)

min avg max

Connect: 65 209 390

Processing: 886 1453 2210

Total: 951 1662 2600

TOP

상당히 많이 사용되고 있는 Processor의 상태를 보여주는 유틸리티로 RAM, CPU, IO ,

SwapSpace의 사용량까지 %로 자세히 보여준다.

특히 웹 서버의 경우 CPU 사용량이 계속적으로 50% 이상이고 IO쪽의 사용량이 크면서 하드

드라이브의 소음(?)이 심해지면 이것은 웹 서버 부하에 대한 시스템의 부족한 RAM에 의해

CPU가

과도한 일을 하고 있는 것이므로 CPU가 아닌 RAM의 증가가 필요하다.

다음 편으로는 실질적인 아파치 웹서버의 설정 부분을 다루겠습니다.

그럼…