NGINX 타이머

앞 에 쓰다
NGINX 시리즈 의 에 세 이 를 쓰 는 것 은 첫째, 배 운 것 을 정리 하고, 둘 째 는 의 심 스 러 운 점 을 기록 해 다음 학습 과정 에서 의혹 을 해결한다.
또한 NGINX 에 관심 이 있 는 친구 들 도 제 의혹 을 풀 어 주거 나 연 구 를 함께 했 으 면 좋 겠 습 니 다.
NGINX 시리즈 전체 글 에 서 는 제 의혹 을 빨간색 으로 표시 하 며 선배 님 을 만 나 댓 글 에서 잘못된 방향 을 풀 어 줬 으 면 좋 겠 다 고 말 했다.
타이머
타 이 머 를 소개 하기 전에 먼저 nginx 가 사건 을 처리 하 는 절차 와 방식 을 간략하게 말 합 니 다.
Worker 프로 세 스 의 주요 프로 세 스:
 

 1 static void

 2 ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data){

 3 　　for(;;) {

 4 　　if(ngx_exiting) {}

 5 　　ngx_process_events_and_timers(cycle);

 6 　　if (ngx_terminate) {}

 7 　　if (ngx_quit) {}

 8 　　if (ngx_reopen) {}

 9 }

10 

11 void

12 ngx_process_events_and_timers(ngx_cycle_t *cycle) {

13 　　(void) ngx_process_events(cycle, timer, flags);

14 }

 
ngx_process_이벤트 가 epoll (linux 에서) 을 호출 하여 이벤트 처 리 를 실현 합 니 다.
ngx process events 처리 이 벤트 는 두 가지 방식 이 있 습 니 다. 하 나 는 처리 함 수 를 직접 호출 하여 처리 하 는 것 이 고, 다른 하 나 는 이 벤트 를 post 대기 열 에 두 고 함수 가 돌아 온 후에 대기 열 에 있 는 이 벤트 를 처리 하 는 것 입 니 다.
사용 중 입 니 다. NGX POST EVENTS 가 표 시 될 때, ngx process events 는 이 벤트 를 직접 처리 하지 않 고, 이 벤트 를 Post 대기 열 에 넣 고 함수 가 되 돌아 오 면 대기 열 에서 이 벤트 를 꺼 내 처리 합 니 다.
ngx process events 를 호출 하면 자 물 쇠 를 추가 하기 때 문 입 니 다. (왜 자 물 쇠 를 추가 합 니까?) 함수 가 돌아 온 후에 자 물 쇠 를 풀 고 이 벤트 를 처리 하면 자물쇠 의 점용 시간 을 줄 일 수 있 습 니 다.
 
이상 은 nginx 가 사건 을 처리 하 는 대체 적 인 방식 입 니 다. 다음은 nginx 에서 타이머 의 실현 을 소개 합 니 다.
Nginx 타 이 머 는 빨 간 검 은 나무 조직 을 사용 합 니 다.
Nginx 타이머 의 트리거 는 두 가지 방식 이 있 는데 첫 번 째 는 시간 신 호 를 설정 하 는 것 이다.
ngx event process init 함수 중 ，시간 신 호 를 설정 하고 고정 시간 마다 촉발 하 며 시간 신호 의 처리 함 수 는 ngx event timer alarm 만 설정 합 니 다. = 1. 그러나 그 는 ngx process events 에서 epoll wait 의 처 리 를 중단 하고 epoll wait 가 돌아 온 후에 ngx time update 업데이트 시간 을 호출 한 다음 함수 ngx process events and timers 로 돌아 가 처리 합 니 다. ngx process events and timers 에 서 는 ngx event expire timers 를 호출 하여 시간 초과 사건 을 조회 하고 처리 합 니 다.
그러나 이러한 방식 에 문제 가 있 습 니 다. 만약 에 이벤트 신호 가 IO 사건 을 처리 할 때 (epoll wait 호출 후) 발생 한다 면 타이머 의 조회 가 옮 겨 다 니 고 다음 epoll wait 호출 때 만 처리 할 수 있 습 니 다. 이때 IO 사건 이 발생 하면 epoll wait 는 즉시 돌아 갈 수 있 습 니 다. 그리고 지난번 신호 가 발생 했 기 때문에 ngx event timer alarm 이 설치 되 어 있 습 니 다. = 1. 즉시 시간 을 업데이트 할 수 있 습 니 다. ngx process events 가 돌아 온 후에 타이머 이 벤트 를 처리 할 수 있 습 니 다. 그러나 IO 이벤트 가 발생 하지 않 으 면 epoll wait 는 다음 시간 신호 가 올 때 까지 차단 하고 타이머 이 벤트 를 처리 합 니 다. 그러면 타이머 의 정확 도 를 크게 낮 추 지 않 습 니까? 이 ngix 는 어떻게 처리 합 니까?
 
또한 고정 시간 (구체 적 으로 설 정 된 시간 신호 의 시간) 마다 시간 값 을 업데이트 하고 심지어 두 배 시간 신호 의 시간 에 야 시간 값 을 업데이트 할 수 있 습 니 다. 그러면 코드 에 삽 입 된 타이머 에 실제 트리거 시간 과 이론 시간 에 이렇게 큰 오차 가 있 을 수 있 습 니 다. 그 렇 죠?
 
Nginx 타이머 의 두 번 째 트리거 방식 은 epoll wait 를 이용 한 시간 초과 입 니 다.
epoll wait 를 호출 하기 전에 nginx 는 다음 최소 (최초 로 트리거 할) 타이머 의 시간 값 을 가 져 온 다음 에 이 값 을 epoll wait 의 시간 초과 시간 으로 사용 합 니 다. 그러면 epoll wait 는 돌아 온 후에 시간 초과 사건 을 처리 할 수 있 습 니 다. 잦 은 IO 상황 에서 시간 초 과 를 처리 할 수도 있 고 IO 소량 에서 시간 초 과 를 처리 할 수도 있 습 니 다.
이 방식 은 epoll wait 가 돌아 온 후에 시간 을 먼저 업데이트 합 니 다. 이렇게 epoll wait 가 돌아 온 후에 IO 이벤트 의 처리 코드 에 타 이 머 를 추가 하면 오차 가 크 지 않 습 니 다. 시간 이 방금 업데이트 되 었 기 때 문 입 니 다.
그러나 이 방법의 문 제 는 IO 가 잦 은 경우 에 도 업데이트 시간 이 잦 아 성능 에 영향 을 미 칠 수 있 느 냐 는 것 이다.
이 두 가지 방식 은 각자 의 장단 점 이 무엇 입 니까?