ApacheBench를 사용하여 Ubuntu 13.10 VPS에서 부하 테스트를 수행하는 방법
소개
부하 테스트는 배포 전에 수행하는 것이 좋습니다. 앞으로 더 자세한 테스트를 실행하기 전에 프로젝트에 대한 최상의 시나리오를 신속하게 설정하는 것이 좋습니다.
ApacheBench 도구(ab)는 임의 개수의 동시 요청을 전송하여 테스트 서버를 로드할 수 있습니다. ab는 Apache 설치를 테스트하기 위해 설계되었지만 모든 HTTP 서버를 벤치마킹하는 데 사용할 수 있습니다.
이 튜토리얼에서는 다른 서버를 사용하는 Ruby 인터프리터가 부하 상태에서 어떻게 작동하는지 살펴봅니다. 자습서 단계에서는 새로운 Ubuntu 13.10 x32 이미지를 가정합니다. 결과는 512MB 액적에서 얻었습니다.
설치
패키지 데이터베이스를 새로 고칩니다.
apt-get update
ApacheBench에 액세스하려면 apache2-utils 패키지를 설치하십시오.
apt-get install apache2-utils
제한된 권한 사용자
다음으로 Ruby를 관리할 사용자를 만듭니다. 다음 섹션의 일부 명령을 루트로 실행하는 것은 좋지 않습니다.
useradd -m -d /home/test -s /bin/bash -g sudo test
이 명령이 수행하는 작업:
- useradd - 새로운 사용자 생성
- -m - 홈 디렉토리 생성\n
- -d /home/test - 사용자의 홈 디렉토리를 /home/test로 설정합니다.\n
- -s /bin/bash - 사용자의 기본 쉘 bash를 만듭니다(Ubuntu는 기본적으로 대시를 사용함).\n
- -g sudo - sudo 그룹에 사용자 추가(sudo로 명령 실행용)\n
- 테스트 - 새 사용자의 이름
새 사용자의 암호를 설정합니다.
passwd test
새 사용자로 전환합니다.
su test
RVM
Ruby 버전 관리자를 사용하면 다양한 Ruby 환경에서 쉽게 작업할 수 있습니다. 특정 Ruby 버전을 설치하고 gemset을 격리하는 프로세스를 처리합니다. 현재 웹 사이트에서 bash 스크립트를 실행하여 설치됩니다.
\curl -L https://get.rvm.io | bash -s stable
rvm 명령을 사용하려면 먼저 rvm 스크립트를 실행해야 합니다.
source ~/.rvm/scripts/rvm
원하는 경우 사용자로 로그인할 때마다 rvm을 사용할 수 있도록 .bashrc에 넣을 수 있습니다.
echo "source ~/.rvm/scripts/rvm" >> ~./bashrc
유형의 헤드를 확인하여 rvm 스크립트가 사용되고 있는지 확인할 수 있습니다. 함수여야 하며 해시되지 않아야 합니다.
type rvm | head -1
rvm is a function
다음으로 Ruby 2.0.0을 설치합니다. RVM은 Ruby를 만들기 전에 다양한 종속성을 설치해야 하기 때문에 사용자의 암호를 묻습니다. RVM은 소스에서 Ruby를 빌드하므로 이 단계는 시간이 걸릴 수 있습니다.
rvm install 2.0.0
새 Ruby로 전환합니다. 이것은 설치 후 기본적으로 발생할 수 있지만 확인해도 문제가 되지 않습니다.
rvm use 2.0.0
테스트
이제 Ruby가 설치되었으므로 간단한 사이트를 만들고 얼마나 많은 요청을 처리할 수 있는지 확인할 수 있습니다.
시나트라를 설치합니다. Ruby 웹 애플리케이션을 만들기 위한 마이크로프레임워크/DSL입니다. --no-* 플래그는 문서를 건너뜁니다.
gem install sinatra --no-rdoc --no-ri
"hello world\를 에코하는 샘플 sinatra 앱을 만듭니다.
cd ~
vim app.rb
# app.rb
require 'sinatra'
get '/' do
'hello world'
end
서버를 실행합니다.
ruby app.rb
서버가 마침내 가동되면 부하 테스트를 시작할 수 있습니다. ab에 대한 호출은 다음과 같습니다.
ab -n <num_requests> -c <concurrency> <addr>:<port><path>
다른 터미널을 열고 서버에 다시 ssh합니다. ApacheBench로 테스트를 실행합니다. 100의 동시성으로 1000개의 요청을 사용했습니다. 경로의 마지막 '/'를 잊지 마세요.
ab -n 1000 -c 100 http://localhost:4567/
Server Software: WEBrick/1.3.1
Server Hostname: localhost
Server Port: 4567
Document Path: /
Document Length: 11 bytes
Concurrency Level: 100
Time taken for tests: 3.410 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 288000 bytes
HTML transferred: 11000 bytes
Requests per second: 293.23 [#/sec] (mean)
Time per request: 341.034 [ms] (mean)
Time per request: 3.410 [ms] (mean, across all concurrent requests)
Transfer rate: 82.47 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 2.0 0 11
Processing: 185 332 90.3 311 578
Waiting: 28 280 83.2 267 574
Total: 193 333 89.7 311 578
Percentage of the requests served within a certain time (ms)
50% 311
66% 357
75% 423
80% 446
90% 467
95% 480
98% 490
99% 501
100% 578 (longest request)
내 결과는 초당 약 300개의 요청으로 수렴되었습니다. WEBrick은 속도로 알려져 있지 않습니다. 계속해서 Ctrl-c를 사용하여 서버를 중단하십시오.
씬 설치
Thin은 구문 분석에 Mongrel을 사용하고 논블로킹 IO에 EventMachine을 사용하는 인기 있는 루비 웹 서버입니다. Thin을 설치하고 서버를 다시 실행하십시오. Sinatra는 Thin을 자동으로 로드하고 알려줄 것입니다("…Thin에서 백업 포함\).
gem install thin
ruby app.rb
이제 부하 테스트를 다시 시도하십시오. 이번에는 조금 더 빨라야 합니다.
Server Software: thin
Server Hostname: localhost
Server Port: 4567
Document Path: /
Document Length: 11 bytes
Concurrency Level: 100
Time taken for tests: 1.339 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 244000 bytes
HTML transferred: 11000 bytes
Requests per second: 747.00 [#/sec] (mean)
Time per request: 133.870 [ms] (mean)
Time per request: 1.339 [ms] (mean, across all concurrent requests)
Transfer rate: 178.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.8 0 8
Processing: 55 128 19.9 132 155
Waiting: 42 116 19.7 121 144
Total: 62 129 18.5 132 156
Percentage of the requests served within a certain time (ms)
50% 132
66% 135
75% 137
80% 139
90% 144
95% 149
98% 152
99% 155
100% 156 (longest request)
적어도 이 경우 Thin은 초당 700개 이상의 요청에서 WEBrick보다 훨씬 더 빠른 서버를 만드는 것처럼 보입니다(총 요청을 늘릴 수는 있지만 저에게는 그다지 높지 않았습니다).
참고: Arch Linux 드롭릿에서 초당 1000개의 요청을 받을 수 있었습니다.
결론
분명히 이러한 결과는 실제 서버 성능을 반영하지 않습니다. HTTP는 퍼즐의 한 조각일 뿐입니다. 느린 템플릿 엔진 및/또는 데이터베이스는 이러한 수치를 크게 떨어뜨립니다. 그래도 비교할 수 있는 빠른 야구장 수치를 제공합니다.
관심을 가질만한 다른 성능 도구:
- httperf
- 가중치
- httpress
- 공성
- J미터
- 투어버스