nginx 쉽게 comet 서버 푸 시 실현

얼마 전에 nginx 에서 서버 푸 시 를 실현 하 는 모듈 NGiNX 를 가끔 발 견 했 습 니 다.HTTP_Push_모듈 은 서버 추 가 를 쉽게 실현 할 수 있 고 nginx 서버 자체 가 스 레 드 모델 이 아 닌 이벤트 구동 으로 서 비 스 를 제공 하기 때문에 높 은 병행 과 낮은 지연 의 특징 을 확보 할 수 있 습 니 다.
먼저 nginx 다운로드http_push_모듈 모듈 설치
./configure –add-module=path/to/nginx_http_push_module … make make install
nginx. conf 설정 파일 을 수정 합 니 다. 모듈 명령 의 설정 을 최대한 간소화 하 겠 습 니 다.

location /publish {
        set $push_channel_id $arg_id;
        push_publisher;                   #   
}
 
location /activity {
        push_subscriber;                  #   
        set $push_channel_id $arg_id;
}

그리고 nginx 를 시작 합 니 다. 모든 작업 이 끝 났 습 니 다. nginx 의 '게시 - 구독' 기능 을 테스트 해 보 세 요.
브 라 우 저 접근 열기http://localhost/activity?id=10000서버 쪽 에서 이 긴 연결 을 유지 하고 내용 이나 4xx, 5xx 의 http 상태 코드 를 되 돌려 주지 않 는 것 을 볼 수 있 습 니 다.
(그 중에서 id = 10000 은 채널 번 호 를 표시 합 니 다. "id" 는 $arg id 변수 로 접 두 사 를 지 운 후의 이름 입 니 다)
perl 스 크 립 트 편집

#!/usr/bin/perl
 
use LWP::UserAgent;
use HTTP::Request::Common;
my $ua = new LWP::UserAgent;
my $response = $ua->request(
        POST 'http://127.0.0.1//publish?id=10000',
        Content_Type => 'text/html',
        Content => 'hi,i posted a message'
);
my $content = $response->content;
print $content;

perl 스 크 립 트 를 저장 하고 실행 하여 지정 한 채널 에 메 시 지 를 발표 한 후에 우 리 는 브 라 우 저가 구독 채널 의 메 시 지 를 받 는 것 을 볼 수 있 습 니 다 'hi, i posted a message'.
위의 실험 을 마치 고 모듈 의 구체 적 인 명령 을 살 펴 보 자.
우선 pushsubscriber [long - poll | interval - poll] 구독 자 역할 을 지정 합 니 다. 기본적으로 긴 폴 링 long - poll 을 선택 합 니 다. interval - poll 을 지정 하면 서버 측은 구독 채널 에 메시지 가 없 을 때 304 Not Modified 상 태 를 즉시 되 돌려 줍 니 다.
push 설정 을 통 해subscriber_concurrency [ last | first | broadcast ] 구독 자가 채널 정 보 를 가 져 오 는 순 서 를 제어 합 니 다. 기본 값 은 '방송' 방식 입 니 다. last 는 채널 이 마지막 긴 연결 을 유지 하고 다른 긴 연결 은 409 충돌 오 류 를 되 돌려 줍 니 다.
채널 정 보 를 제어 하 는 다른 명령 도 있 습 니 다.
    push_store_messages [on | off], 발 표 된 메시지 저장 여부     push_max_reserved_memory [ size ] ，메시지 저장 공간 크기     push_message_timeout [ time ]，메시지 만 료 시간     기타 명령 은 모듈 의 사용 매 뉴 얼 을 참조 할 수 있다.

테스트 1: 간단 한 압력 테스트 병행 효 과 를 만 들 겠 습 니 다. 10000 채널 에 메시지 큐 가 없 을 때 apache 자체 테이프 도구 로 500 개의 테스트 를 모 의 한 다음 에 vmstat 를 보면 시스템 메모리 와 cpu 가 모두 점용 되 지 않 았 음 을 볼 수 있 습 니 다. 다만 디스크 IO 에 변화 가 있 고 쓰기 디스크 가 존재 하 며 즉시 정상 으로 회복 되 었 습 니 다.

vm6245:/usr/sbin # ab2 -c 500 -n 10000 http://localhost/activity?id=10000

vm6245:~/penjin # vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0  12312 317364  19056  17480    0    0     0     3    8    5  0  0 100  0  0
 0  0  12312 317364  19116  17420    0    0     0    60   38   14  0  0 99  1  0
 0  0  12312 317372  19116  17420    0    0     0     0   17    9  0  0 100  0  0
 0  0  12312 317372  19116  17420    0    0     0     0   19    7  0  0 100  0  0

테스트 2: 채널 에 소식 이 발표 되면 ab 테스트 결 과 는 다음 과 같 습 니 다.

vm6245:/usr/sbin # ab2 -c 500 -n 10000 http://localhost/activity?id=10000
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests


Server Software:        nginx/1.1.13
Server Hostname:        localhost
Server Port:            80

Document Path:          /activity?id=10001
Document Length:        21 bytes

Concurrency Level:      500
Time taken for tests:   1.191773 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2580000 bytes
HTML transferred:       210000 bytes
Requests per second:    8390.86 [#/sec] (mean)
Time per request:       59.589 [ms] (mean)
Time per request:       0.119 [ms] (mean, across all concurrent requests)
Transfer rate:          2113.66 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   24  22.4     18      74
Processing:     6   30  11.8     36      46
Waiting:        0   13   8.8     11      34
Total:          8   54  32.5     53     117

Percentage of the requests served within a certain time (ms)
  50%     53
  66%     71
  75%     82
  80%     88
  90%    101
  95%    107
  98%    112
  99%    113
 100%    117 (longest request)

500 이 동시에 발생 하 는 상황 에서 응답 속도 가 좋 은 것 을 알 수 있 습 니 다. 또한 vmstat 디 스 플레이 는 프로그램 메모리 의 영향 이 크 지 않 고 cpu 의 점용 도 빠르게 회복 되 었 음 을 알 수 있 습 니 다.

vm6245:~/penjin # vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0  12312 319588  20696  20000    0    0     0     3    8    5  0  0 100  0  0
 3  0  12312 310776  20700  20516    0    0     0     0  198 23935 10 20 70  0  0
 0  0  12312 314864  20820  21176    0    0     0  1244  524 15876 11 31 56  4  0
 0  0  12312 315484  20820  21176    0    0     0     0   28   15  0  0 100  0  0
 0  0  12312 315484  20820  21176    0    0     0     0   20    6  0  0 100  0  0
 0  0  12312 315656  20820  21176    0    0     0     0   19   12  0  0 100  0  0

테스트 1 의 결과 에 주목 합 니 다. 시스템 이 긴 연결 을 유지 할 때 cpu, 메모리, 디스크 IO 의 압력 이 크 지 않 습 니 다. 인터넷 에 서 는 NGiNX HTTP Push Module 모듈 에 메모리 문제 가 있다 고 합 니 다. 긴 연결 을 유지 하 는 메모리 가 적시에 방출 되 지 않 았 기 때 문 입 니 다. 하지만 제 테스트 에 서 는 이러한 주장 이 사실 인지 알 수 없습니다.