'Server/Ubuntu'에 해당하는 글 21건

이제 앱들과 SDK 통신할 Parse 서버를 구축한다.

아래 문서들을 참조하는데, 오픈 소스이다 보니 버그도 간혹 있으므로 참고한다. (현재 v2.1.6은 문제 없었음.)


https://github.com/ParsePlatform/parse-server

https://github.com/ParsePlatform/parse-server/wiki

https://www.npmjs.com/package/parse-server



1. nodejs & npm 설치


Node.js 버전 4.3 이상을 요구하므로 4.x 로 설치한다.

함께 설치되는 npm 도 최신버전으로 업데이트한다.

Python 2.x 도 필요하지만 기본적으로 2.7 버전대가 설치되므로 -v 로 버전 확인만 한다.


# curl -sL https://deb.nodesource.com/setup_4.x | bash -
# apt-get install -y nodejs
# apt-get install -y build-essential
 
# npm install npm -g
# nodejs -v
v4.4.0
# npm -v
3.8.1
cs



2. parse-server 설치


$ npm install -g parse-server mongodb-runner
$ mongodb-runner start
cs


(mongodb-runner 는 머하는지 모르겠음; 없어도 정상적으로 동작함)

위와 같이 npm 글로벌 설치를 하면 /usr/lib/node_modules/parse-server 가 홈디렉토리가 된다.

파스 서버의 설정 파일은 parse-server 디렉토리 밖의 특정 장소에 저장하는 것이 좋다. (npm update 시 삭제될 수 있음.)

아래 설정 파일 항목의 appId 와 masterKey 값은 https://dashboard.parse.com/apps 대시보드의 [App Settings - Security & Keys] 메뉴를 참고한다.

push 설정의 경우, 기존 푸시 사용자는 https://dashboard.parse.com/apps 대시보드의 [Push] 메뉴를 참고하고, 신규 사용자는 해당 디바이스 개발자에게 문의ㅎ


$ vi /usr/lib/node_modules/config-parse.json
{
  "databaseURI""mongodb://username:password@mongodb-ip/database-name",
  "appId""XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "masterKey""XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "push": {
    "android": {
      "senderId""1111111111111",
      "apiKey""XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
    },
    "ios": {
      "pfx""/file/path/to/development_XXX.p12",
      "bundleId""com.oops4u.parse",
      "production"false
    },
    {
      "pfx""/file/path/to/product_XXX.p12",
      "bundleId""com.oops4u.parse",
      "production"true
    },
    {
      "pfx""/file/path/to/proudct_enterprise_XXX.p12",
      "bundleId""com.oops4u.enterprise.parse",
      "production"true
    }
  }
});
cs



3. parse-server 실행


$ parse-server --appId APPLICATION_ID --masterKey MASTER_KEY --databaseURI DATABASE_URI ...
cs


이런 식으로 실행을 해야 하지만 설정 파일을 미리 만들어 놓았으므로, 아래와 같이 설정 파일만 호출하면 된다.


# parse-server /usr/lib/node_modules/config-parse.json
Configuation loaded from /usr/lib/node_modules/config-parse.json
databaseURI: mongodb://username:password@your_domain/database_name
appId: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
masterKey: ***REDACTED***
push: [object Object]
port: 1337
mountPath: /parse
maxUploadSize: 20mb
serverURL: http://parse-server-domain:1337/parse
 
parse-server running on http://parse-server-domain:1337/parse
cs


기본적으로 parse-server 는 1337 포트를 사용한다.

변경하고 싶다면 parse-server 실행시 --port 1338 등의 매개변수를 추가할 수 있으며, 해당 포트는 방화벽 등에서 허용한다.

더 많은 옵션은 parse-server -h 로 확인.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  2개가 달렸습니다.
  1. 슬슬 저도 마이그레이션을 해야하는데 영문 문서 꼼꼼하게 읽기가 귀찮아서(...) 미루던 참이었는데 잘 봤습니다. DB 마이그레이션은 마쳤고 대시보드도 설치 후 forever로 백그라운드에서 돌아가게 설정하고 nginx 프록시로 도메인까지 물려줬는데 서버 부분에서 궁금한 점이 있어서 댓글 남깁니다.

    Parse Server 저장소 위키에서는 앱을 express를 통해 설정하도록 안내하고 있는데 글에서는 json config로 설정하셨는데 혹시 양쪽의 차이점이라거나 json config 파일 이용시 2개 이상의 앱을 한 서버에서 굴릴때도 따로 처리할 부분이 있는지 궁금합니다.
    • 음... 그사이에 버전업이 되었네요. 이 글을 쓸 당시에 express 얘기가 있었나 가물가물하네요 ^^; 오픈소스치고 파스서버가 유난히 버전업이 심한듯 합니다. 그만큼 관심갖는 분들이 많은듯! 차이라면 아마도 웹서버에 파스서버를 마운트 시키는게 아닐까 싶네요. 2개 이상의 앱은 포트만 추가만 잘 해주시면 될것 같구요~
secret

MongoDB warning

Server/Ubuntu 2016. 3. 23. 21:55

1. mongod stop/waiting


mongoDB 를 설치하고 나서 설정 등을 변경하고 restart 를 하려고 하면 start 가 성공했는데도 status 를 확인하면 멈춰있는 것을 볼 수 있다.


# service mongod start
mongod start/running, process 27576
# service mongod status
mongod stop/waiting
cs


로그를 확인하면...


# vi /var/log/mongodb/mongod.log
2016-03-21T11:48:41.326+0000 E NETWORK  [initandlisten] Failed to unlink socket file /tmp/mongodb-27017.sock errno:1 Operation not permitted
cs


소켓에 권한이 없다고... 


# ls -al /tmp/mongodb-27017.sock
srwx------ 1 root root 0 Mar 21 11:54 /tmp/mongodb-27017.sock
cs


삭제 시켜버린다 ㅋ


# rm /tmp/mongodb-27017.sock
 
# service mongod start
mongod start/running, process 27666
# service mongod status
mongod start/running, process 27666
 
# ls -al /tmp/mongodb-27017.sock
srwx------ 1 mongodb mongodb 0 Mar 21 11:54 /tmp/mongodb-27017.sock
cs


mongodb 계정으로 잘 생성되었다.



2. THP warning


# mongo
MongoDB shell version: 3.0.10
connecting to: test
Server has startup warnings:
2016-03-21T11:54:46.627+0000 I CONTROL  [initandlisten]
2016-03-21T11:54:46.627+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2016-03-21T11:54:46.627+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2016-03-21T11:54:46.627+0000 I CONTROL  [initandlisten]
2016-03-21T11:54:46.627+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2016-03-21T11:54:46.627+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2016-03-21T11:54:46.627+0000 I CONTROL  [initandlisten]
cs


MongoDB 를 실행할 때 다음과 같이 THP (Transparent Huge Pages) 경고가 나타날 수 있다.

THP 는 대용량 메모리 페이지로부터 대용량 메모리를 가진 시스템에 대한 TLB (Translation Lookaside Buffer) 의 오버헤드를 줄이는 리눅스 메모리 관리 시스템이다.

잘 이해는 안되지만, THP 가 활성화된 데이터베이스에서는 과부하를 일으키기도 하기 때문에, MongoDB 에서는 THP 를 사용하지 않는 것을 추천한다.


시스템 시작시 THP 설정을 끄기 위해 다음과 같은 스크립트를 작성한다.


# vi /etc/init.d/disable-transparent-hugepages

#!/bin/sh
### BEGIN INIT INFO
# Provides:          disable-transparent-hugepages
# Required-Start:    $local_fs
# Required-Stop:
# X-Start-Before:    mongod mongodb-mms-automation-agent
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Disable Linux transparent huge pages
# Description:       Disable Linux transparent huge pages, to improve
#                    database performance.
### END INIT INFO
 
case $1 in
  start)
    if [ -/sys/kernel/mm/transparent_hugepage ]; then
      thp_path=/sys/kernel/mm/transparent_hugepage
    elif [ -/sys/kernel/mm/redhat_transparent_hugepage ]; then
      thp_path=/sys/kernel/mm/redhat_transparent_hugepage
    else
      return 0
    fi
 
    echo 'never' > ${thp_path}/enabled
    echo 'never' > ${thp_path}/defrag
 
    unset thp_path
    ;;
esac
cs


# chmod 755 /etc/init.d/disable-transparent-hugepages
update-rc.d disable-transparent-hugepages defaults
# /etc/init.d/disable-transparent-hugepages
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

자체 Parse 서버 구축을 위해 일단 parse.com 사이트를 방문한다.

메인 페이지의 parse-server Github 링크로 이동하면, Wiki 메뉴의 Parse 서버 구축과 마이그레이션 가이드에 구축 내용이 상세히 설명되어 있다.


전체적인 순서는 대충 이러하다:


    1. Parse.com DB 를 마이그레이션 하기 위한 MongoDB 구축 (Parse 사용 DB 가 MongoDB 이다.)
    2. DB 마이그레이션
    3. Parse 대시보드 구축
    4. 푸시 서비스할 parse-server 구축
    5. Web / Android / ios - parse-server 세팅
    6. 푸시 테스트



Database specifications


- MongoDB version 2.6.X / 3.0.X : 현재 최신버전은 3.2 이지만 권장사양인 3.0.x 를 설치했다.

- failIndexKeyTooLong 파라미터 값 false 지정

- SSL 접속 추천(권장 아님)



MongoDB install


Ubuntu 14.04 저장소에는 MongoDB 가 2.4 버전이므로 3.0 버전에 대한 저장소를 추가하여 설치한다.

문서 참고 - https://docs.mongodb.org/v3.0/


# apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10
# echo "deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.0 multiverse" | tee /etc/apt/sources.list.d/mongodb-org-3.0.list
# apt-get update
# apt-get install -y mongodb-org
# mongo -version
MongoDB shell version: 3.0.10
cs



MongoDB Setting


마이그레이션에 필요한 Database connection string 을 만들기 위해 DB 와 username/password 를 세팅한다.

/etc/mongod.conf 파일에서 외부 접속이 가능하도록 bindIp: 127.0.0.1 를 0.0.0.0 으로 변경한다.

1024 byte 가 넘는 Index key 를 허용하기 위해 failIndexKeyTooLong=false 도 설정한다.

MongoDB 는 기본적으로 27017 포트를 사용하므로 방화벽 등에서 허용해 준다.


# mongod --setParameter failIndexKeyTooLong=false
# vi /etc/mongod.conf
net:
  port: 27017
  bindIp: 0.0.0.0
# service mongod restart
# mongo
> use database_name
> db.createUser({ user: "username", pwd: "password", roles: [ "readWrite""dbAdmin" ] })
cs



MongoDB Migration


MongoDB 세팅을 마쳤으면 Parse 대시보드의 [App Setting - General] 메뉴에서 마이그레이션을 진행한다.

DB Connection 문자열은 mongodb://username:password@your_domain/database_name 가 될 것이며 ssl 을 사용한다면 뒤에 ?ssl=true 를 붙인다.

문제가 없다면 몇 분 뒤 마이그레이션이 완료된다.


마이그레이션을 마치고 데이터가 MongoDB 에 정상적으로 등록이 되었는지 확인한다.


# mongo
> use database_name
> show collections
> db.getCollection("_Installation").count()
> exit
 
# mongod --setParameter failIndexKeyTooLong=true
cs



WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  2개가 달렸습니다.
  1. Parse-server까지는 마이그레이션을 못해서 Parse.com API + 자체 MongoDB 조합으로 쓰느라 bindip가 고대로 0.0.0.0으로 두고 있었는데 요 며칠사이에 랜섬이 날뛰어서 제대로 당했네요. 무작위로 때리는 느낌인데 마이그레이션 도중이라도 잠깐 bindip 열어두는것도 조심해야 할 것 같습니다.
    • 별일없으셔서 다행이네요~ 모든 ip 를 허용하는것 보다는 필요한 ip 를 지정해 주는게 더 좋겠습니다~ 각자의 환경에 맞게 잘 구축하시길~
secret

PHP-FPM

Server/Ubuntu 2016. 2. 15. 21:56

PHP-FPM (PHP FastCGI Process Manager)은 대규모 사이트에서 유용한 추가 기능들을 이용해 PHP 를 fastCGI 모드로 동작하게 한다.


  1. 웹서버와 프로세스를 분리하여 독립적으로 사용
  2. 별도의 포트와 php.ini 파일을 사용하여 다른 uid/gid/chroot/환경으로 프로세스 시작
  3. 에러 로깅 출력
  4. 빠른 업로드
  5. slowlog - 비정상적으로 느린 스크립트 기록
  6. fastcgi_finish_request() 함수 제공 - 오래 걸리는 작업은 계속 진행하고, 현재 위치에서 즉시 응답을 보냄 (비디오 변환, 상태 처리 등)
  7. 동적/정적 자식 프로세스 생성 가능
  8. Apache mod_status 같은 기본 SAPI 상태 정보 제공


대략적인 구동방식은 해당 도메인으로 들어오는 모든 php 요청을 php-fpm 데몬으로 넘기는 식이다.

기본 php.ini 파일 대신 /etc/php5/fpm/php.ini 파일로 php 파일을 처리하게 되며,

php-fpm 데몬 설정은 /etc/php5/fpm/pool.d/www.conf 파일에서 한다.



1. PHP-FPM 설치


# apt-get install php5-fpm
cs



2. 가상 디렉토리 수정


# vi /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    ProxyPassMatch ^/(.*.php(/.*)?)$ fcgi://127.0.0.1:9000/var/www/html/$1
...
cs



3. php-fpm 설정


# vi /etc/php5/fpm/pool.d/www.conf
listen = 127.0.0.1:9000
cs



4. 모듈 적재 / 데몬 재구동


# a2enmod proxy_fcgi
# service apache2 restart
# service php5-fpm restart
cs


9000 포트로 연결하였으므로 9000 포트가 열려 있어야 한다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

NGINX vs MPM-PREFORK vs MPM-EVENT


Ubuntu 14.04 에서 apache 2.4 MPM prefork 를 사용중이다.

prefork 방식은 안정적이고 다른 소프트웨어와 호환성이 좋다고 알려져 있다.

동시 접속에 대해서는 쓰레드 방식의 worker / event / nginx 가 좋다고 알려져 있다.

그리고 나는 이것들이 실제 지금 우리 서버에도 해당되는지 테스트를 해봤다.

더불어 현재 설치된 prefork 방식의 한계도 알아보려고 한다.

현재 서버는 AWS r1.large 이다.



Prefork setting


# vi /etc/apache2/mods-enabled/mpm_prefork.conf
<IfModule mpm_prefork_module>
        StartServers              5
        MinSpareServers           5
        MaxSpareServers          10
        MaxRequestWorkers       150
        MaxConnectionsPerChild    0
</IfModule>
cs


최초 서버 시작시 프로세스는 5개로 시작하고, 여분의 프로세스 범위는 5~10 이고 요청을 처리할 수 있는 최대 프로세스 수는 150 개로 설정되어 있다.

하나의 프로세스당 하나의 요청을 받으니까 150개의 요청을 한번에 받고나면 150개가 클라이언트에 응답을 돌려줄 때까지는 더 이상의 요청을 받을 수 없다.

응답을 빨리 한 프로세스는 또 다른 요청을 받을 수 있을 것이고... 그것은 페이지의 용량 등 여러가지 리소스에 따라 달라질 것이다.


프로세스 확인


웹서버를 시작하고 나서 apache2 프로세스를 검색하면 


18625 ?        Ss     0:01 /usr/sbin/apache2 -k start
18630 ?        S      0:01 /usr/sbin/apache2 -k start
18642 ?        S      0:01 /usr/sbin/apache2 -k start
18652 ?        S      0:01 /usr/sbin/apache2 -k start
18673 ?        S      0:00 /usr/sbin/apache2 -k start
18711 ?        S      0:00 /usr/sbin/apache2 -k start
cs


부모 프로세스인 Ss 를 제외하면 프로세스가 5개 맞다. 



Prefork 과부하 테스트


Request page size : 52kb

Number of Threads : 최대 500

Ramp-Up Period : 1

Loop Count : 1


웹 서비스 성능 테스트 툴은 JMeter 를 사용하였다. (Apache Bench 도 결과적으로는 거의 흡사했다.)

테스트 PC 의 CPU 가 100% 가 되면 요청 Thread 가 동시에 전달될 수 없으므로, 요청 Thread(동시접속)는 500 정도까지 테스트 해보았다.

요청 페이지는 DB 연결도 필요하고 CDN 으로부터 적지 않은 이미지들도 불러오는 일반 쇼핑몰 메인 페이지 수준의 페이지이다.


Thread 1~10 은 응답속도가 0.4 초 나왔다. (전혀 문제 없음)

Thread 20 은 응답속도가 0.4~0.8 초 나왔다. 평균 0.6 (거의 문제 없음)

Thread 30 은 응답속도가 0.4~1.4 초 나왔다. 평균 1.0 (이정도는 문제 없음)

Thread 40 은 응답속도가 0.4~3.0 초 나왔다. 평균 1.6 (벌써 이러면 좀 걱정 됨)

Thread 50 은 응답속도가 0.4~3.0 초 나왔다. 평균 1.9 (최대 응답 속도는 이전과 동일)

Thread 60 은 응답속도가 0.6~3.9 초 나왔다. 평균 2.4 (벌어지기 시작함)

Thread 70 은 응답속도가 0.6~4.7 초 나왔다. 평균 2.8 (...)

Thread 80 은 응답속도가 0.6~5.8 초 나왔다. 평균 3.3

Thread 90 은 응답속도가 0.9~6.4 초 나왔다. 평균 3.9

Thread 100 은 응답속도가 0.8~7.4 초 나왔다. 평균 4.4

Thread 110 은 응답속도가 0.5~7.9 초 나왔다. 평균 4.6

Thread 120 은 응답속도가 0.5~8.9 초 나왔다. 평균 5.2

Thread 130 은 응답속도가 0.5~9.9 초 나왔다. 평균 5.8

Thread 140 은 응답속도가 0.6~10.4 초 나왔다. 평균 6.3

Thread 150 은 응답속도가 0.6~11.2 초 나왔다. 평균 6.9 


--(MaxRequestWorkers 설정값이 150 이라서 그런건지 뭔지 여기까지는 에러가 없다.


Thread 160 은 응답속도가 0.6~12.2 초 나왔다. 평균 7.2

Thread 200 은 응답속도가 0.9~15.6 초 나왔다. 평균 9.3

Thread 250 은 응답속도가 0.9~19.6 초 나왔다. 평균 11.4

Thread 300 은 응답속도가 0.6~22.8 초 나왔다. 평균 13.6

Thread 350 은 응답속도가 0.8~26.2 초 나왔다. 평균 15.4 (error 5.14%)

Thread 400 은 응답속도가 0.6~29.0 초 나왔다. 평균 16.9 (error 8.50%)

Thread 500 은 응답속도가 5.4~24.2 초 나왔다. 평균 17.5 (error 35.8%)


각 테스트는 프로세스가 안정화 되고나서 테스트를 하였다.

MaxRequestWorkers 설정 값이 150 인 상태에서 52kb 짜리 테스트 페이지는 동시 요청을 300 개 정도까지는 에러 없이 응답하였다.

발생한 에러는 콘솔에 툴 에러로 나왔는데 어찌됐든 응답 받지 못했으니 대충 에러로 인식.

RAM 사용량은 thread 500 요청시 8GB 중 apahce 에서 최대 1GB 정도만을 사용했다. CPU 도 25% 정도까지만 올라갔다. (서버 리소스는 완전 널널하다는...)

사실 3초 이상 브라우저의 로딩 화면을 바라보고 있는 사람은 거의 없다.

최대 3초 까지 방문 유저가 참아 준다고 치면 현재 상태에서의 동접은 50 정도까지가 안정적인 것으로 보인다.

매우 실망스러운 수치이다.

성능 테스트를 직접 해본것은 처음이였지만 내가 알고 있던 성능 테스트 결과와는 사뭇 달랐다.

이때까지만 해도 일단 페이지 자체가 가볍지 않고, 튜닝도 전혀 하지 않은 기본 설정 상태라서 그럴것이라고 생각했다.


그렇다면 MaxRequestWorkers 값을 늘리면 응답 속도가 늘어날까? (150->256)


Thread 50 은 응답속도가 0.7~3.2 초 나왔다. 평균 2.0 (비슷)

Thread 80 은 응답속도가 0.8~6.0 초 나왔다. 평균 3.4 (비슷)

Thread 100 은 응답속도가 0.9~7.5 초 나왔다. 평균 4.3 (비슷)

Thread 120 은 응답속도가 0.9~8.9 초 나왔다. 평균 5.0 (비슷)

Thread 150 은 응답속도가 1.0~11.4 초 나왔다. 평균 6.6 (비슷)

Thread 200 은 응답속도가 0.8~15.0 초 나왔다. 평균 8.5 (비슷)

Thread 300 은 응답속도가 0.9~22.5 초 나왔다. 평균 13.3 (비슷)

Thread 350 은 응답속도가 0.9~26.1 초 나왔다. 평균 15.8 (error 11.11%)


프로세스를 150 에서 256 으로 올려도 속도면에서는 거의 차이가 없었고 에러도 동일한 구간에서 발생하기 시작했다.

그렇다면 현재 상황에서는 프로세스 수를 1024 정도로 올리더라도 응답속도나 에러는 동일할 것으로 판단되었다.

그래도 확실하게 테스트.


MaxRequestWorkers 구성은 ServerLimit 에서 지정한 값보다 클 수 없는데, serverLimit 의 기본값은 256 이다.

MaxRequestWorkers 를 256 보다 크게 설정하려면 ServerLimit 값을 256보다 크게 설정해야 한다.

ServerLimit 는 여분의 메모리에 할당되므로 이 값을 너무 크게 설정하면 시스템이나 apache 가 불안정해 질 수 있다고 한다.

ServerLimit 는 200000 까지 설정할 수 있으며, 이 보다 더 큰 값을 적용시키려면 MPM 소스 파일에 MAX_SERVER_LIMIT 값을 수정하고 apache 를 재컴파일해야 한다.


MaxRequestWorkers 256->1024


<IfModule mpm_prefork_module>
        ServerLimit            1024
        StartServers              5
        MinSpareServers           5
        MaxSpareServers          10
        MaxRequestWorkers      1024
        MaxConnectionsPerChild    0
</IfModule>
cs


Thread 50 은 응답속도가 0.5~3.4 초 나왔다. 평균 2.1 (비슷)

Thread 100 은 응답속도가 0.9~7.7 초 나왔다. 평균 4.4 (비슷)

Thread 200 은 응답속도가 0.9~15.7 초 나왔다. 평균 9.0 (비슷)

Thread 300 은 응답속도가 1.0~23.5 초 나왔다. 평균 13.6 (비슷)

Thread 350 은 응답속도가 0.9~25.3 초 나왔다. 평균 15.3 (error 6.00%)


달라진게 없다. 하하~ ...prefork...

포기할 수 없다. 마지막으로 1024->100000 까지 올려봤다.


Thread 350 은 응답속도가 1.7~26.6 초 나왔다. 평균 16.0 (error 1.43%)


확실히 알게 되었다. prefork 튜닝은 다 부질 없음을...ㅋ

어짜피 첫 페이지에 대한 동시접속만 알아보려는 것이므로 Timeout, KeepAlive 등의 테스트는 하지 않았다.



Multi threads


NGINX vs MPM-WORKER vs MPM-EVENT


프로세스 방식의 mpm-prefork, 멀티 스레드 방식의 nginx / mpm-worker / mpm-event.

prefork 의 실망감을 감추지 못한채 큰 기대감을 갖고 위 3가지에 대해 prefork 와 동일하게 테스트 해보았다.

prefork 와 동일한 환경에서의 결과는...


...

...

...

...

...


따로 적기도 짜증날 정도로 prefork / nginx / mpm-worker / mpm-event 의 결과는 비슷했다. 스레드 수를 늘려도 마찬가지.

순간 네트워크의 속도가 약간씩 영향을 주는 것을 감안할 때 무엇이 더 좋다고 딱히 말할 수 없을 정도로 큰 차이가 없었다.

또한 AWS 에서 가장 낮은 사양의 t2.micro 에서도 동일했다. 하하.

(phpinfo 정도의 가벼운 페이지는 모두 1000 개의 동시접속을 1,2 초 내에 처리했다.)



나의 결론은 이렇다.


1. Apache 를 쓰던 Nginx 를 쓰던 속도나 처리 상에 큰 속도 차이는 없다.

2. 웹서버의 사양도 속도에 큰 차이를 보이지 않는다. (서버 사양을 늘리느니 서버를 한 대 더 추가하는게 나을듯...)

3. 튜닝한다고 프로세스, 쓰레드 수를 늘려도 처리 속도는 차이가 없다.


난 결국 이미 깔려 있는, 그리고 이 중 가장 안정적이라는 prefork 를 유지하기로 마음 먹었다.


끝!



WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret