Nginx 설정 명령 의 실행 순서 (4)
11242 단어 nginx
access 요청 처리 단계 에 사용자 Lua 코드 를 삽입 합 니 다.이 명령 은 access 단계 의 끝 allow 화해시키다 deny 이런 명령 은 같은 소속 이지 만 실행 된다. access 단계보통 우 리 는 통과 한다. access_by_lua ... 에 있다 ngx_access 이러한 모듈 은 클 라 이언 트 IP 주 소 를 검사 한 후에 Lua 코드 를 통 해 더욱 복잡 한 요청 검증 작업 을 수행 합 니 다. 예 를 들 어 실시 간 으로 데이터베이스 나 다른 백 엔 드 서 비 스 를 조회 하여 현재 사용자 의 신분 이나 권한 을 검증 합 니 다.우 리 는 간단 한 예 를 보고 이용 하 자. access_by_lua 실현 하 다 ngx_access 모듈 의 IP 주소 필터 기능:
location /hello {
access_by_lua '
if ngx.var.remote_addr == "127.0.0.1" then
return
end
ngx.exit(403)
';
echo "hello world";
}Lua 코드 에서 Nginx 표준 내장 변 수 를 참조 합 니 다. $remote_addr 문자열 형식의 클 라 이언 트 IP 주 소 를 가 져 오고 Lua 의
if 문 구 는 이 컴퓨터 의 주소 인지, 즉 같 는 지 여 부 를 판단 한다. 127.0.0.1. 본 기기 의 주소 라면 Lua 의 return 를 직접 이용 합 니 다. 문 구 를 되 돌려 줍 니 다. Nginx 가 후속 요청 처리 단 계 를 계속 수행 하도록 합 니 다. (포함) echo 지령 소 content 단계이 컴퓨터 주소 가 아니라면, ngx_lua 모듈 에서 제공 하 는 Lua 함수 ngx.exit 현재 요청 처리 프로 세 스 를 중단 하고 바로 되 돌려 줍 니 다. 403 클 라 이언 트 에 게 오류 페이지 를 보 냅 니 다.이 예 는 기능 적 으로 이전 과 완전히 같다. (3) 소개 ngx_access 모듈 의 예:
location /hello {
allow 127.0.0.1;
deny all;
echo "hello world";
}비록 이 두 가지 예 는 기능 적 으로 완전히 같 지만 성능 적 으로 는 차이 가 있다. ngx_access 순수 C 로 구현 되 는 전문 화 된 Nginx 모듈 입 니 다.
다음은 이 두 사례 의 성능 차 이 를 실제 적 으로 측정 해 보 자.우리 가 Nginx 를 사용 하 는 것 은 성능 을 추구 하기 위해 양 적 성능 을 비교 하 는 것 이기 때문에 공사 에 있어 서 매우 현실 적 인 의 미 를 가지 기 때문에 중요 한 측량 기술 도 소개 합 니 다.아무리 ngx_access 역시 ngx_lua IP 주소 검증 을 진행 하 는 데 있어 서 성능 이 매우 높 기 때문에 측정 오 차 를 줄 이기 위해 서 우 리 는
access 단계 의 사용 시 직접 측정 을 한다.이 를 위해 전통 적 인 방법 은 일반적으로 Nginx 소스 코드 를 수정 하고 자신 이 전문 적 인 시간 계산 코드 와 통계 출력 코드 를 삽입 하거나 Nginx 를 다시 컴 파일 하여 사용 하 는 것 과 관련된다. GNU gprof 이런 전문 적 인 성능 모니터링 도구.다행히도 새로운 Solaris, Mac OS X, FreeBSD 등 시스템 에
dtrace 의 도 구 는 임의의 사용자 프로그램 에 대해 미시적 성능 분석 (및 행위 분석) 을 할 수 있 으 며, 사용자 프로그램의 소스 코드 를 수정 하거나 사용자 프로그램 을 재 컴 파일 할 필요 가 없다.왜냐하면 Mac OS X 10.5 이후 에 자체 가 져 왔어요. dtrace 그래서 편 의 를 위해 제 MacBook Air 노트북 에서 이곳 의 측정 과정 을 보 여 드 리 겠 습 니 다.우선, Mac OS X 시스템 에서 명령 행 터미널 을 열 고 파일 디 렉 터 리 아래 에 이름 을 만 듭 니 다.
nginx-access-time.d 다음 과 같은 내용 의 파일 을 편집 합 니 다. #!/usr/bin/env dtrace -s
pid$1::ngx_http_handler:entry
{
elapsed = 0;
}
pid$1::ngx_http_core_access_phase:entry
{
begin = timestamp;
}
pid$1::ngx_http_core_access_phase:return
/begin > 0/
{
elapsed += timestamp - begin;
begin = 0;
}
pid$1::ngx_http_finalize_request:return
/elapsed > 0/
{
@elapsed = avg(elapsed);
elapsed = 0;
}이 파일 을 저장 한 후 실행 가능 한 권한 을 부여 합 니 다:
$ chmod +x ./nginx-access-time.d이것 / 이것
.d 파일 의 코드 는 dtrace 도구 D 언어 로 작 성 된 것 입 니 다. D 언어 는 Walter Bright 가 다른 '더 좋 은 C + +' 로 디자인 한 것 과 같 지 않다. D 언어본 시리즈 의 튜 토리 얼 은 어떻게 작성 하 는 지 소개 할 계획 이 없 기 때문이다. dtrace 의 D 스 크 립 트 를 이해 하 는 동시에 이 스 크 립 트 를 이해 하려 면 Nginx 내부 소스 코드 구현 에 관 한 세부 사항 이 필요 하기 때문에 소 개 를 하지 않 습 니 다.이 스 크 립 트 의 기능 은 다음 과 같 습 니 다. 지정 한 Nginx worker 프로 세 스 를 통계 하여 모든 요청 을 처리 할 때 평균 적 으로 사용 합 니 다. access 단계 적 시간.이제 이 걸 보 여 드릴 게 요.
D 스 크 립 트 의 실행 방법.이 스 크 립 트 는 감시 할 Nginx worker 프로 세 스 의 프로 세 스 번호 (pid) 를 지정 하 는 명령 행 인 자 를 받 습 니 다.Nginx 는 다 중 워 커 프로 세 스 를 지원 하기 때문에 테스트 할 때 시작 하 는 HTTP 요청 은 임의의 워 커 프로 세 스 서비스 일 수 있 습 니 다.모든 테스트 요청 이 고정된 워 커 프로 세 스 로 처리 되 는 지 확인 하기 위해 서 는 nginx.conf 설정 파일 에서 워 커 프로 세 스 만 사용 할 것 을 지정 합 니 다: worker_processes 1;Nginx 서버 를 다시 시작 하면 사용 할 수 있 습 니 다.
ps 명령 은 현재 worker 프로 세 스 의 프로 세 스 번 호 를 가 져 옵 니 다: $ ps ax|grep nginx|grep worker|grep -v grep내 기계 에서 의 전형 적 인 수출 은?
10975 ?? S 0:34.28 nginx: worker process그 중에서 첫 번 째 열의 수 치 는 바로 나의 nginx worker 프로 세 스 의 프로 세 스 번호 입 니 다.
10975출력 이 한 줄 이 아니라면 시스템 에서 여러 개의 Nginx 서버 인 스 턴 스 를 동시에 실행 하거나 현재 Nginx 인 스 턴 스 가 여러 개의 worker 프로 세 스 를 사용 하고 있 음 을 의미 합 니 다.다음은 방금 받 은 워 커 프로 세 스 번호 와 루트 신분 으로 실 행 됩 니 다.
nginx-access-time.d 스 크 립 트: $ sudo ./nginx-access-time.d 10975모든 것 이 정상 이면 다음 줄 의 출력 을 볼 수 있 습 니 다.
dtrace: script './nginx-access-time.d' matched 4 probes이 줄 의 출력 은 우리 의
D 스 크 립 트 가 대상 프로 세 스 에 4 개 동적 으로 삽입 되 었 습 니 다. dtrace 프로 브 (probe).이어서 이 스 크 립 트 가 끊 겼 습 니 다. dtrace 도구 가 프로 세 스 를 10975 지속 적 인 감 시 를 하 다.그런 후에 우 리 는 새로운 단말 기 를 다시 열 어 거기에서 사용한다.
curl 이런 도 구 는 우리 가 감시 하고 있 는 인 터 페 이 스 를 여러 번 요청 했다. $ curl 'http://localhost:8080/hello'
hello world
$ curl 'http://localhost:8080/hello'
hello world마지막 으로 저희 가 원래 있 던 걸 로 돌아 가서 계속 돌아 가 고 있어 요.
D 스 크 립 트 의 터미널, 누 르 기 Ctrl-C 조합 키 중지 dtrace 의 운행.이 스 크 립 트 는 종료 할 때 최종 통계 결 과 를 터미널 에 출력 합 니 다.예 를 들 어 나의 단말 기 는 이때 이 모양 이다. $ sudo ./nginx-access-time.d 10975
dtrace: script './nginx-access-time.d' matched 4 probes
^C
19219마지막 줄 출력
19219 바로 그 몇 번 curl 요청 access 단계 의 평균 사용 시간 (나 초, 즉 10 의 마이너스 9 제곱 초 단위).위 에서 소개 한 절 차 를 통 해 통과 할 수 있다.
nginx-access-time.d 스 크 립 트 는 각각 다른 Nginx 설정 을 집계 합 니 다. access 단계 의 평균 사용 시.우리 가 관심 이 있 는 세 가지 상황 에 대해 세 조 의 평행 시험, 즉 사용 할 수 있다. ngx_access IP 주소 필터 사용 access_by_lua IP 주 소 를 걸 러 내 는 경우 및 없 음 access 단계 에서 모든 설정 명령 을 사용 하 는 경우.마지막 상황 은 '공백 대조 팀' 에 속 하 며 테스트 과정 에서 인 한 dtrace 프로 브 등 다른 요소 로 도 입 된 '시스템 오차'.또 각종 통제 불가능 한 '랜 덤 오차' 를 최소 화하 기 위해 사용 할 수 있다 ab 이러한 대량 테스트 도 구 를 대체 하 다. curl 10 만 번 이상 의 요청 을 하 다. $ ab -k -c1 -n100000 'http://127.0.0.1:8080/hello'이렇게 우리
D 스 크 립 트 가 집계 한 평균 값 은 '실제 값' 에 더욱 가 까 워 집 니 다.나의 애플 시스템 에서 전형 적 인 테스트 결 과 는 다음 과 같다.
ngx_access 18146
access_by_lua 35011
15887앞의 두 조 의 결 과 를 각각 '공백 대조 조' 의 결 과 를 빼 면 얻 을 수 있다.
ngx_access 2259
access_by_lua 19124볼 수 있 습 니 다. ngx_access 그룹 비 access_by_lua 팀 이 대략 한 개의 수량 급 이 빨 라 졌 는데, 이것 이 바로 우리 가 예상 한 것 이다.그러나 절대적 인 시간 차 는 극히 작다.
Intel Core2Duo 1.86 GHz CPU 의 경우 고작 십 몇 초, 혹은 10 만 분 의 1 초의 헤비급 에 불과 하 다.물론 access_by_lua 예 를 바꾸다. $binary_remote_addr 내부 건설 변 수 를 최적화 합 니 다. 왜냐하면 $binary_remote_addr 바 이 너 리 형식의 IP 주 소 를 읽 습 니 다. $remote_addr 더 긴 문자열 형식의 주 소 를 되 돌려 줍 니 다.더 짧 은 주 소 는 Lua 로 문자열 을 비교 할 때 더 빠 를 수 있다 는 것 을 의미한다.
하면, 만약, 만약... (1) 에서 소개 한 방법 은 Nginx 에 '디 버 깅 로그' 를 열 면 위 에서 통계 한 시간 이 현저히 증가 할 것 이다. 왜냐하면 '디 버 깅 로그' 자체 의 비용 이 매우 많 기 때문이다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
간단! Certbot을 사용하여 웹 사이트를 SSL(HTTPS)화하는 방법초보자가 인프라 주위를 정돈하는 것은 매우 어렵습니다. 이번은 사이트를 간단하게 SSL화(HTTP에서 HTTPS통신)로 변경하는 방법을 소개합니다! 이번에는 소프트웨어 시스템 Nginx CentOS7 의 환경에서 S...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
