RadarURL
Skip to content
조회 수 2094 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

= 동시접속자수, 서버용량, 로드 밸런싱

 

회선 대역폭 이용한도란 미디어호스팅 고객사이트에서 다운로드 전송되는 동영상 데이터로인해 발생하는 회선트래픽의 양을 의미합니다. 아래 예제는 동시접속자와 예상 대역폭을 계산하였습니다. 즉, 고객님의 홈페이지에서 한개의 동영상을 대상으로 최대 몇명의 동시 접속자가 발생하는지를 예상하여 서비스를 선택하실 수 있습니다.

예)300Kbps로 인코딩된 동영상 파일을 10명이 동시에 예) 감상하는 경우

 

..- 300Kbps × 10명 = 3,000Kbps = 3M bps

..- (bps = bitper second : 초당 전송 바이트수)

 

..- 만일 한개의 사이트에 위와같은 동영상이 10개가

..- 동시에 서비스된다면 전송량은 10배가 됩니다.

 

 

 

 

동시접속자수는 웹서버에 최근 10초 사이에 서비스요청이 있었던 사용자를 접속중인 사용자로 보아 계산한다.

 서비스요청 제한수는 추후에 웹서버의 성능 테스트 결과에 따라 변경할 수 있다.

 

 

 

동시접속자수(천 분의 1초 사이에 동시에 request를 보내는 사용자수) 40명이라는 안정적인 수치를 확보하였다.

시스템의 운영중에 이를 초과하는 접속자수의 급격한 증가로 네트워크 트래픽이 발생하면 이를 위해서는 서버에

연결되어 있는 전용선의 용량을 증대시켜 속도개선을 취해야 한다.

 

 

=====================================================

 (급) 웹서버 구축시 동시 가능 접속자수 예상법

=====================================================

 

웹서버 구축시 (intel Xeon 2.4Ghz, win2000, IIS서버) 서버가 얼마만큼의

동시 가능 접속자를 서비스 할 수 있을까요?

-> 일반적으로 IIS 의 경우 커넥션 수를 대략의 폭만 정하고 있습니다.

그렇기 때문에 CPU 나 RAM 등의 사양에 따라 상이하게 틀려질수 있습니다.

그리고 Xeon cpu 를 사용 하고 계시는데 이xeon cpu 의 경우 하이퍼쓰레드 를

지원 합니다. 그러나 win2k 는 완벽히 지원을 하지 못합니다.

이것이 첫번째 이유 입니다.

 

두번째 이유 입니다.

구성을 계획하고 계시는 사이트 의 DB 커넥션 수라던지 소스의 크기 그리고 가져가는 소스 들의 사이즈 에 따라 성능이 틀려 집니다.

 

세번재 이유 입니다.

사용 하실수 있는 트래픽의 대역폭이 어떻게 되는 건가요?

그 한계를 끌어 들였을때 동시에 값을 계산을 하여야 합니다.

 

apache web server 의 경우는 일반적인 지원 커넥션이 256 이고 컴파일을 하면서 옵션을 주며 1024 이 되는걸 알고 있습니다.

 

그런데 IIS 상에서는 대역폭 설정만 있으며 그 값이 세분화 된것이 아니며

그냥 10만 이하 이상 등의 방법으로 하고 있습니다.

 

 

일반적인 사이트 의 경우 동시 접속은 100을 넘는 경우가 드물며.. 활성화된 동호회 사이트 는 1000정도 그리고 잘나가는 게임 사이트 등 초대형 사이트 들은 1 만 에서 10만 정도로 알고 있습니다.

이 서버들이 부하를 못견디는건 웹서비스 가 아닌 DB 커넥션과 소스 의 입출력이 되는

트래픽 입니다.

 

 

시물레이션 할 수 있는 방법 또는 평균 예상치(벤치마크) 있나요?

-> 답이 되셨을지...

 

======================================================

서버용량

======================================================

 

우선 한게임 싸이트는 일반 웹서비스와 차원이 다릅니다..

각 유저마다 서버가 접속해 있는지 아닌지를 항상 확인하는 데몬(혹은 세션) 이 떠 있어야 하는데..

이것은 즉.. 각 사용자에게 최소한의 패킷 과 메모리가 ( 한 100 bit 쯤 되지 않을까..? ㅡㅡ^ )

할당 되어 있어야 한다는 뜻이죠.. 즉 서버가 엄청난 고사양이어야 한다는 것입니다.

 

그런데 그것도 한계가 있습니다.

라인 용량의 한계요...결국에는 그래서 서버수를 늘리는 거죠...

모르긴 몰라도 한게임 은.. 한 서버당 최대 수용이 800 정도가 아닐까 하는

개인적인 생각을 가지고 있습니다.

 

 

암튼,

님이 말씀하시는 싸이트의 성격이 어떤 서비스를 하려는 곳인지는 잘 모르겠지만,

우선 제 경험 상으로는.. [ 제가 운영하는 곳은 쇼핑몰입니다.]

동시 접속자 수가 편균 3000 입니다.

최대 수용은 4000 정도가 되죠..

 

웹서버 3 대와 관리자서버 1 대 , 파일서버가 1 대, 디비 서버가 1 대죠..

일반적으로 이렇게들 생각하실겁니다..

"아니 그럼 웹서버 한대가 1000 ~ 1400 을 커버 한단 말야..? "

 

가능합니다 충분히....더 할 수도 있습니다.

문제는 위에 말씀드렸던 세션 부분과 메모리 할당은 어떻게 최소화 할 것이냐와

네트워크를 오가는 패킷[데이타] 를 어떻게 최소화 할 것이냐의 문제..

그리고 데이터 베이스와의 통신의 양을 가장 적게 할 수 있는 방법들을 살펴 보면 가능합니다...

 

즉 시스템의 튜닝 뿐 아니라 돌아가는 프로그램의 [ 그것이 웹서비스던, 아니던간에~!!]

튜닝도 같이 이뤄져야 한다는 것을 의미합니다.

 

서버가 100 Mbps 의 라인을 이용하고 있다고 칩시다.

이론적으로 100 Mbps 지만.. 실제로는 네트웍이 30Mbps ~ 35Mbps 면 잘 나오는 겁니다.

그러면 봅시다...

한 서버가 초당 내보낼수 있는 라인의 용량의 한계가 35Mbps 라고 한다면..

동시접속자수가 1000 명이라고 할때..

한명당. 35 Kbps 정도가 한계라는 거죠...

 

또한 아마 저정도면 웹서비스 데몬이 적어도 메모리를 2 Giga 는 되야 할겁니다.

 

결론은 총체적으로 여러가지 부분에서 선행되어야 하는 문제들이 있지만.

그냥 기본적으로 생각할때..

동시 접속자 수가 5000 정도라고 한다면..

 

약 서버 5 대 정도와 디비 1 대 정도라고 말씀드릴수 있겠습니다.

( 그외에 관리서버 , 파일 서버, 백업서버, L4 스위치 등등 머 따지구 들자면 끝없지만..)

 

참고로 저희 사양을 말씀드리면..

웹서버,관리,파일 서버는 2 CPU/2 Giga

디비서버는 4 CPU/8 Giga 입니다..

 

 

답변이 되셨을지 모르겠네요

 

 

======================================================

동시접속자수 부하에 견디는 하드웨어

======================================================

 

안녕하세요. AnyMOS 서버팀 입니다.

저희가 가장 어려워 하는 질문이네요...

일반적으로 저희 Q&A를 살펴 보시면 아시겠지만 어느 특정한

서버를 놓고 '이 서버는 몇명의 동시접속자를 수용 할 수 있습니다.'

라고 하는 것은 옛날 서버가 귀하던 시절의 영업 방식입니다.

그러므로 정확한 답변은 드릴 수 없다가 저희가 드릴 수 있는 답변

이고요. 이 부분은 저희와 이상환님의 검증아래 가장 근접한 데이터를

수집하는 것으로 일을 시작해야 합니다. 일반적으로 포털 사이트인

경우 왭서버의 경우엔 시스탬의 부하량 보다는 네트웍의 부하가 우선시

됩니다. 즉 네트웍 대역폭이 받처 주는 상황에서 서버를 선정 하는 것

이 순서입니다. 기본적인 스팩의 서버로 유저들이 접속 할 경우에 대한

CPU점유률 메모리 사용량 등등을 계산하여 하나의 서버가 처리 할 수

있는 용량을 염두해 두시고 필요한 수량을 선정 해야 합니다.

이전에는 접속자가 많은 대형 포탈 서비스 업체인 경우 엔터프라이즈급

의 서버를 많이 선호 하였으나 요즘은 저가 사양의 서버에 사용자의

수에 따라 유연하게 대처 할 수 있는 로드발란싱 기술을 좀 더 선호

하고 있는 추세 입니다. 오버 사이징으로 인한 비용 낭비를 막고

하나의 서버에 집중화 시켜 부담을 주기 보다는 하드웨어나 소프트웨어

적인 결함을 유연하게 대처 할 수 있는 설계가 환영 받고 있죠.

어느정도 답변이 되셨을지 궁금하네요.

혹시 저희 AnyMOS의 제안에 동의 하셨다면 연락 부탁 드리겠습니다.

저희 AnyMOS에서는 고객사가 보다 정확한 서버를 선정하기 위해 필요

로 하는 장비들을 지원해 드리고 있습니다. 물론 비용은 들지 않습니다.

감사합니다.

 

 

 

 

======================================================

로드 밸런싱을

======================================================

 

       (3) 세션 관리

 

             * 기본적으로 세션 관리 기능 제공

 

             * 세션때문에 관리와 배포가 힘든 경우도 있는데, 대규모 사용자가 있을 경우에는

 

               세션 정보 자체가 오버헤드가 될 수 있고, 로드 밸런싱을 할 때 문제가 발생할 수 있다.

 

               session 객체는 메모리 안에 생성된 객체이기 때문이다. 이 문제는 특정 브라우저를

 

               특정 서버와 통신하도록 로드 밸런싱 서버를 설정함으로써 해결할 수 있기는 하지만,

 

               해당 서버가 다운 되는 등의 경우는 Session Migration을 해주어야 한다.

 

출처 : http://nimba.tistory.com/m/entry/%EB%8F%99%EC%8B%9C%EC%A0%91%EC%86%8D%EC%9E%90%EC%88%98-%EC%84%9C%EB%B2%84%EC%9A%A9%EB%9F%89-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%8B%B1

 

 

 

=나의 웹서버는 얼마나 튼튼한가?

 

이 문서는 웹서버를 운영하면서 자신의 웹서버가 어디까지 버틸수있는지 웹서버의 임계치를 유추해내는 방법에대한 문서이다. 자 이제부터 내 웹서버는 어디까지 버틸수있을지를 실험해보자.

 

작성자 : 김형채 

작성일 : 2005년 6월

1. 서문

 

리눅스를 설치하면 대부분 웹서버를 많이 설치한다. 그냥 모르고 설치하는 사람도 있고 개인적은로 웹서버를 운용하기위해서 설치하기도 하고, 공부를 위해서 설치하기도 하는등 다양한 이유로 웹서버는 설치된다.

이 문서는 나의 하드웨어 사양에서 내가 설치한 웹서버의 능력을 알려고 하면 어떻게 해야할까에서 시작된다. 같은 페이지가 보인다고 해서 같은 성능은 아니다. 이제부터 내 웹서버의 성능이 어디까지 나오는지를 테스트해보기로 하자.

 

2. 테스트를 위한 프로그램

 

웹서버의 성능 테스트를 위해서는 아래의 프로그램 들이 필요하다.

 

웹서버 - 이것은 당연히 설치가 되어있다고 가정한다.

httperf - 웹서버에 부하를 주면서 성능을 측절하는 프로그램이다.

idleconn - Idle connection 을 만들어 주는 프로그램이다. 동시접속자의 상황을 만들수있다.

 

httperf & idleconn

 

httperf 는 아래의 주소에서 다운로드 받을수 있으며 설명서도 제공되므로 참고하기 바란다.

http://www.hpl.hp.com/research/linux/httperf/

ftp://ftp.hpl.hp.com/pub/httperf/

 

wget 을 이용해서 다운로드 받는다

[root@ns src]# wget ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.8.tar.gz

--15:31:03--  ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.8.tar.gz

          => `httperf-0.8.tar.gz'

Resolving ftp.hpl.hp.com... 192.6.19.21

Connecting to ftp.hpl.hp.com[192.6.19.21]:21... connected.

anonymous로서 로그인하고 있습니다...로그인 했습니다!

==> SYST ... 완료.    ==> PWD ... 완료.

==> TYPE I ... 완료.  ==> CWD /pub/httperf ... 완료.

==> PASV ... 완료.    ==> RETR httperf-0.8.tar.gz ... 완료.

길이: 146,107 (unauthoritative)

 

100%[===============================>] 146,107       73.21K/s            

 

15:31:07 (73.06 KB/s) - `httperf-0.8.tar.gz' saved [146,107]

 

다운받은 파일의 압축을 해제한다

[root@ns src]# tar -xvzf httperf-0.8.tar.gz

httperf-0.8/

httperf-0.8/timer.h

httperf-0.8/core.c

httperf-0.8/httperf.c

httperf-0.8/core.h

httperf-0.8/event.h

------- 중략 --------

httperf-0.8/config.guess

httperf-0.8/aclocal.m4

httperf-0.8/idleconn.c

[root@ns src]#

 

 

일반적인 소스 설치 방법대로 아래 과정을 수행해서 설치해준다.

./configure

make

make install

동시접속자를 만들기 위한 idleconn은 설치시에 복사되지 않으므로 수동으로 복사해준다.

[root@ns httperf-0.8]# cp idleconn /bin/idleconn

 

3. 성능측정

 

자 이제 설치를 모두 마쳤으면 성능을 측정해 보기로 하자.

테스트는 일단 idleconn을 이용하지 않은 상태에서 테스트하고, idleconn을 이용해서 접속자를 많이 생성한후에 한번 진행해 보기로 하자.

 

httperf의 각 옵션은 다음과 같다.

--server 서버주소 : 여기에 적어 준 서버로 접속을 시도하게 된다.
--port 숫자 : 여기에 적어 준 포트로 접속을 시도하게 된다. 웹서버는 기본적으로 80번 포트를 사용하지만 정확한 측정을위해서는 8080등의 포트를 이용할 것을 권장한다. (측정중 일반 사용자의 접속이 있으면 결과가 제대로 나오지 않기 때문이다.)
--num-conns 숫자 : 서버로 총 몇개의 접속을 만들 것인지를 결정한다.
--rate 숫자 : 1초에 몇개의 접속을 만들 것인지를 결정한다.
--timeout 숫자 : 이곳에 주어진 숫자만큼의 초동안 기다린 후 응답이 없는 연결은 timeout 에러로 처리한다.
--think-timeout 숫자 : CGI등 서버쪽에서 처리해야 하는 일들이 있는 페이지의 경우 서버측에 이를 처리할 시간을 준다. timeout에서 이곳에 주어진 숫자만큼을 더한 값이 진짜 timeout값이 된다.
--hog : 가능한 모든 포트를 사용한다. 이 옵션을 주지 않으면 기본적으로 1024부터 5000까지의 포트만 사용한다.

 

httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=500 --rate=50 --timeout=5 --think-timeout=5 --hog


위의 명령은 linuxhowto.co.kr 이라는 주소를 가진 서버의 / 페이지에 80번 포트로 1초에 50개씩 총 500개의 접속을 만들게 된다. 또한 5초간 응답이 없을 경우 시간초과 에러로 처리한다.
웹서버가 정상적으로 요청을 처리한다면 10초후에는 결과가 나타난다

4. 결과분석방법

 

실제 테스트 결과 아래와 같은 결과가 나타난다.

각 항목이 무엇을 말하는지는 알아보자.

 

Total: connections 500 requests 500 replies 500 test-duration 9.983 s

 

Connection rate: 50.1 conn/s (20.0 ms/conn, <=1 concurrent connections)

Connection time [ms]: min 1.6 avg 1.8 max 2.9 median 1.5 stddev 0.1

Connection time [ms]: connect 0.0

Connection length [replies/conn]: 1.000

 

Request rate: 50.1 req/s (20.0 ms/req)

Request size [B]: 67.0

 

Reply rate [replies/s]: min 50.0 avg 50.0 max 50.0 stddev 0.0 (1 samples)

Reply time [ms]: response 1.8 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=500 3xx=0 4xx=0 5xx=0

 

CPU time [s]: user 3.06 system 6.90 (user 30.7% system 69.1% total 99.8%)

Net I/O: 294.0 KB/s (2.4*10^6 bps)

 

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

 

결과는 6개의 그룹으로 표시되고 전체테스트 요약("Total"), 접속상태관련("Connection"), HTTP request 부분 ("Request"), 서버로부터 받은 응답부분 ("Reply"), CPU 시간과 network bandwidth 사용량, 마지막으로 에러집계 ("Errors") 부분으로 구성된다

실제 테스트 결과에서 주의깊게 보아야 하는부분은 서버의 응답시간을 표시하는 Reply time 부분이다.

위의 결과에서는 응답시간이 1.8 ms 인것을 확인할수 있다.

 

5. 웹서버 괴롭히기

 

테스트결과 웹서버가 50개씩 500번은 무리없이 수행하는것을 알수있다.

자 그럼 웹서버를 좀 괴롭혀보기로 하자. 컴파일시에 생성된 idleconn 을 이용해서 동시접속자를 한번 만들어보자. idleconn 이라고 치면 아래처럼 사용법이 나온다.

[root@ns httperf-0.8]# idleconn

Usage: idleconn server port numidle

동시접속자를 한 250명정도 만들어본다

[root@ns httperf-0.8]# idleconn linuxhowto.co.kr 80 250

idleconn: creating and maintaining 250 idle connections

 

동시접속자가 정말 만들어 졌는지 확인해보자

[root@ns ~]# netstat -anpt|grep httpd|grep ESTA|wc -l

250

보는것처럼 250개의 연결된 접속을 생성해냈다.

 

이제 앞에서 테스트했던 방법대로 한번더 해보자.

httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=500 --rate=50 --timeout=5 --think-timeout=5 --hog

 

Total: connections 500 requests 500 replies 500 test-duration 9.982 s

 

Connection rate: 50.1 conn/s (20.0 ms/conn, <=1 concurrent connections)

Connection time [ms]: min 1.4 avg 1.9 max 16.2 median 1.5 stddev 0.7

Connection time [ms]: connect 0.0

Connection length [replies/conn]: 1.000

 

Request rate: 50.1 req/s (20.0 ms/req)

Request size [B]: 67.0

 

Reply rate [replies/s]: min 50.0 avg 50.0 max 50.0 stddev 0.0 (1 samples)

Reply time [ms]: response 1.9 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=500 3xx=0 4xx=0 5xx=0

 

CPU time [s]: user 2.91 system 7.03 (user 29.2% system 70.5% total 99.6%)

Net I/O: 294.0 KB/s (2.4*10^6 bps)

 

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

 

아직까지는 별 문제없이 잘 견디는것 처럼 보인다.

그럼 약간 더 괴롭혀 보자.

이번에는 1초에 200개씩 요청하고 10000번 해보자.

httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=10000 --rate=200 --timeout=5 --think-timeout=5 --hog

 

Total: connections 10000 requests 10000 replies 10000 test-duration 49.999 s

 

Connection rate: 200.0 conn/s (5.0 ms/conn, <=3 concurrent connections)

Connection time [ms]: min 0.2 avg 1.8 max 13.3 median 1.5 stddev 0.3

Connection time [ms]: connect 0.0

Connection length [replies/conn]: 1.000

 

Request rate: 200.0 req/s (5.0 ms/req)

Request size [B]: 67.0

 

Reply rate [replies/s]: min 199.8 avg 200.0 max 200.0 stddev 0.1 (10 samples)

Reply time [ms]: response 1.8 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=10000 3xx=0 4xx=0 5xx=0

 

CPU time [s]: user 14.05 system 35.47 (user 28.1% system 70.9% total 99.0%)

Net I/O: 1173.9 KB/s (9.6*10^6 bps)

 

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

 

아직까지는 별문제 없는 상태이다.

이번에는 좀 더 많은 부하를 줘보자. 아래는 초당 1000 개의 요청을 20000개가 될 때까지 테스트하는 예이다.

 

[root@ns ~]# httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=20000 --rate=1000 --timeout=5 --think-timeout=5 --hog 

httperf --hog --think-timeout=5 --timeout=5 --client=0/1 --server=linuxhowto.co.kr --port=80 --uri=/ --rate=1000 --send-buffer=4096 --recv-buffer=16384 --num-conns=20000 --num-calls=1

Maximum connect burst length: 13

 

Total: connections 12506 requests 10011 replies 9984 test-duration 28.036 s

 

Connection rate: 446.1 conn/s (2.2 ms/conn, <=1022 concurrent connections)

Connection time [ms]: min 3.3 avg 876.3 max 12766.8 median 290.5 stddev 1345.5

Connection time [ms]: connect 546.2

Connection length [replies/conn]: 1.000

 

Request rate: 357.1 req/s (2.8 ms/req)

Request size [B]: 67.0

 

Reply rate [replies/s]: min 107.2 avg 399.2 max 499.2 stddev 165.2 (5 samples)

Reply time [ms]: response 336.2 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=9984 3xx=0 4xx=0 5xx=0

 

CPU time [s]: user 1.08 system 20.19 (user 3.9% system 72.0% total 75.9%)

Net I/O: 2090.1 KB/s (17.1*10^6 bps)

 

Errors: total 10016 client-timo 2522 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 7494 addrunavail 0 ftab-full 0 other 0

[root@ns ~]#

 

결과를 보면 타임아웃으로 처리를 못하는 경우가 절반이상이고, 응답시간도 매우 길어졌음을 알수있다

5초안에 대답을 못한 요청수가 10016 개이다. 테스트한 웹서버가 이 정도는 무리라는 결론이다.

 

자 이제 여러분의 웹서버를 마구 괴롭혀서 어디까지 견디는지 테스트해보자.

 

6. 참고문헌 또는 URL

 

http://www.hpl.hp.com/research/linux/httperf/docs.php

 

출처 : http://jikime.tistory.com/284 동시접속자수 테스트 방법 참조
 
 

출처 : http://phpdoumi.tistory.com/147

?

PageViews   Today : 699   Yesterday : 1,534   Total : 19,194,302  /  Counter Status   Today : 186   Yesterday : 507   Total : 1,252,535
Site Info   Member : 58  /  Total documents : 1,197   New documents : 0  /  Total comments : 25

Edited by JAESOO

sketchbook5, 스케치북5

sketchbook5, 스케치북5

나눔글꼴 설치 안내


이 PC에는 나눔글꼴이 설치되어 있지 않습니다.

이 사이트를 나눔글꼴로 보기 위해서는
나눔글꼴을 설치해야 합니다.

설치 취소