소개

I/O 리액터 (단일 스레드 이벤트 루프)는 많은 인기 있는 솔루션에 사용되는 고부하 소프트웨어 작성을 위한 패턴입니다.

이 기사에서는 I/O 리액터의 모든 면과 작동 방식을 살펴보고, 200줄 미만의 코드로 구현을 작성하고, 분당 40천만 개가 넘는 요청을 처리하는 간단한 HTTP 서버 프로세스를 만들 것입니다.

머리말

이 기사는 I/O 리액터의 기능을 이해하고 이를 사용할 때의 위험을 이해하는 데 도움을 주기 위해 작성되었습니다.
기사를 이해하려면 기본 지식이 필요합니다. C 언어 그리고 네트워크 애플리케이션 개발 경험이 있습니다.
모든 코드는 (주의: 긴 PDF) C11 표준에 Linux용이며 다음에서 사용 가능 GitHub의.

왜합니까?

인터넷의 인기가 높아짐에 따라 웹 서버는 많은 수의 연결을 동시에 처리해야 하므로 두 가지 접근 방식이 시도되었습니다. 즉, 다수의 OS 스레드에서 I/O를 차단하는 방법과 "시스템 선택기"라고도 하는 이벤트 알림 시스템(Epoll/큐/IOCP/기타).

첫 번째 접근 방식은 들어오는 연결마다 새로운 OS 스레드를 생성하는 것이었습니다. 단점은 확장성이 좋지 않다는 것입니다. 운영 체제는 많은 것을 구현해야 합니다. 컨텍스트 전환 и 시스템 호출. 이는 비용이 많이 드는 작업이며 연결 수가 많아 여유 RAM이 부족할 수 있습니다.

수정된 버전이 강조 표시됩니다. 고정된 스레드 수 (스레드 풀) 이를 통해 시스템 충돌을 방지하지만 동시에 새로운 문제가 발생합니다. 스레드 풀이 현재 긴 읽기 작업으로 차단된 경우 이미 데이터를 수신할 수 있는 다른 소켓은 이를 수행할 수 없습니다. 그래서.

두 번째 접근 방식은 이벤트 알림 시스템 (시스템 선택기)는 OS에서 제공합니다. 이 문서에서는 I/O 작업 준비 상태에 대한 경고(이벤트, 알림)를 기반으로 하는 가장 일반적인 유형의 시스템 선택기에 대해 설명합니다. 완료에 대한 알림. 그 사용의 간단한 예는 다음 블록 다이어그램으로 표현될 수 있습니다:

이러한 접근 방식의 차이점은 다음과 같습니다.

I/O 작업 차단 유예하다 사용자 흐름 그때까지OS가 제대로 작동할 때까지 조각 모음 들어오는 IP 패킷 바이트 스트림으로(TCP, 데이터 수신) 또는 다음을 통한 후속 전송을 위해 내부 쓰기 버퍼에 사용 가능한 공간이 충분하지 않습니다. NIC (데이터 전송).
시스템 선택기 시간이 지남에 따라 OS가 프로그램에 알립니다. 이미 조각 모음된 IP 패킷(TCP, 데이터 수신) 또는 내부 쓰기 버퍼에 충분한 공간 이미 가능합니다(데이터 전송).

요약하자면, 각 I/O에 대해 OS 스레드를 예약하는 것은 컴퓨팅 성능을 낭비하는 것입니다. 실제로 스레드는 유용한 작업을 수행하지 않기 때문입니다. "소프트웨어 인터럽트"). 시스템 선택기는 이 문제를 해결하여 사용자 프로그램이 CPU 리소스를 훨씬 더 경제적으로 사용할 수 있도록 합니다.

I/O 리액터 모델

I/O 리액터는 시스템 선택기와 사용자 코드 사이의 계층 역할을 합니다. 작동 원리는 다음 블록 다이어그램으로 설명됩니다.

이벤트는 특정 소켓이 비차단 I/O 작업을 수행할 수 있다는 알림이라는 점을 상기시켜 드리겠습니다.
이벤트 핸들러는 이벤트가 수신될 때 I/O 리액터에 의해 호출되어 비차단 I/O 작업을 수행하는 함수입니다.

I/O 리액터는 정의상 단일 스레드이지만 이 개념이 1 스레드: 1 리액터 비율로 멀티 스레드 환경에서 사용되어 모든 CPU 코어를 재활용하는 것을 막을 방법이 없다는 점에 유의하는 것이 중요합니다.

Реализация

공개 인터페이스를 파일에 배치하겠습니다. reactor.h및 구현 - reactor.c. reactor.h 다음 공지사항으로 구성됩니다.

Reactor.h에 선언 표시

typedef struct reactor Reactor;

/*
 * Указатель на функцию, которая будет вызываться I/O реактором при поступлении
 * события от системного селектора.
 */
typedef void (*Callback)(void *arg, int fd, uint32_t events);

/*
 * Возвращает `NULL` в случае ошибки, не-`NULL` указатель на `Reactor` в
 * противном случае.
 */
Reactor *reactor_new(void);

/*
 * Освобождает системный селектор, все зарегистрированные сокеты в данный момент
 * времени и сам I/O реактор.
 *
 * Следующие функции возвращают -1 в случае ошибки, 0 в случае успеха.
 */
int reactor_destroy(Reactor *reactor);

int reactor_register(const Reactor *reactor, int fd, uint32_t interest,
                     Callback callback, void *callback_arg);
int reactor_deregister(const Reactor *reactor, int fd);
int reactor_reregister(const Reactor *reactor, int fd, uint32_t interest,
                       Callback callback, void *callback_arg);

/*
 * Запускает цикл событий с тайм-аутом `timeout`.
 *
 * Эта функция передаст управление вызывающему коду если отведённое время вышло
 * или/и при отсутствии зарегистрированных сокетов.
 */
int reactor_run(const Reactor *reactor, time_t timeout);

I/O 리액터 구조는 다음과 같이 구성됩니다. 파일 설명자 선택자 Epoll и 해시 테이블 GHashTable, 각 소켓을 다음으로 매핑합니다. CallbackData (이벤트 핸들러의 구조 및 이에 대한 사용자 인수)

Reactor 및 CallbackData 표시

struct reactor {
    int epoll_fd;
    GHashTable *table; // (int, CallbackData)
};

typedef struct {
    Callback callback;
    void *arg;
} CallbackData;

처리할 수 있는 기능을 활성화했습니다. 불완전한 유형 지수에 따르면. 안에 reactor.h 우리는 구조를 선언 reactor, 및 c reactor.c 이를 정의하여 사용자가 해당 필드를 명시적으로 변경하는 것을 방지합니다. 패턴중 하나에요 데이터 숨기기, 이는 C 의미론에 간결하게 맞습니다.

기능 reactor_register, reactor_deregister и reactor_reregister 시스템 선택기와 해시 테이블에서 관심 있는 소켓 목록과 해당 이벤트 핸들러를 업데이트합니다.

등록 기능 표시

#define REACTOR_CTL(reactor, op, fd, interest)                                 
    if (epoll_ctl(reactor->epoll_fd, op, fd,                                   
                  &(struct epoll_event){.events = interest,                    
                                        .data = {.fd = fd}}) == -1) {          
        perror("epoll_ctl");                                                   
        return -1;                                                             
    }

int reactor_register(const Reactor *reactor, int fd, uint32_t interest,
                     Callback callback, void *callback_arg) {
    REACTOR_CTL(reactor, EPOLL_CTL_ADD, fd, interest)
    g_hash_table_insert(reactor->table, int_in_heap(fd),
                        callback_data_new(callback, callback_arg));
    return 0;
}

int reactor_deregister(const Reactor *reactor, int fd) {
    REACTOR_CTL(reactor, EPOLL_CTL_DEL, fd, 0)
    g_hash_table_remove(reactor->table, &fd);
    return 0;
}

int reactor_reregister(const Reactor *reactor, int fd, uint32_t interest,
                       Callback callback, void *callback_arg) {
    REACTOR_CTL(reactor, EPOLL_CTL_MOD, fd, interest)
    g_hash_table_insert(reactor->table, int_in_heap(fd),
                        callback_data_new(callback, callback_arg));
    return 0;
}

I/O 리액터가 설명자를 사용하여 이벤트를 차단한 후 fd, 해당 이벤트 핸들러를 호출하고 이를 전달합니다. fd, 비트 마스크 생성된 이벤트 및 사용자 포인터 void.

Reactor_run() 함수 표시

int reactor_run(const Reactor *reactor, time_t timeout) {
    int result;
    struct epoll_event *events;
    if ((events = calloc(MAX_EVENTS, sizeof(*events))) == NULL)
        abort();

    time_t start = time(NULL);

    while (true) {
        time_t passed = time(NULL) - start;
        int nfds =
            epoll_wait(reactor->epoll_fd, events, MAX_EVENTS, timeout - passed);

        switch (nfds) {
        // Ошибка
        case -1:
            perror("epoll_wait");
            result = -1;
            goto cleanup;
        // Время вышло
        case 0:
            result = 0;
            goto cleanup;
        // Успешная операция
        default:
            // Вызвать обработчиков событий
            for (int i = 0; i < nfds; i++) {
                int fd = events[i].data.fd;

                CallbackData *callback =
                    g_hash_table_lookup(reactor->table, &fd);
                callback->callback(callback->arg, fd, events[i].events);
            }
        }
    }

cleanup:
    free(events);
    return result;
}

요약하자면, 사용자 코드의 함수 호출 체인은 다음과 같은 형식을 취합니다.

단일 스레드 서버

높은 부하에서 I/O 리액터를 테스트하기 위해 이미지로 모든 요청에 응답하는 간단한 HTTP 웹 서버를 작성하겠습니다.

HTTP 프로토콜에 대한 빠른 참조

HTTP - 이것이 프로토콜이다 응용 수준, 주로 서버-브라우저 상호 작용에 사용됩니다.

HTTP를 통해 쉽게 사용할 수 있습니다. 수송 규약 TCP, 지정된 형식으로 메시지를 보내고 받습니다. 사양.

요청 형식

<КОМАНДА> <URI> <ВЕРСИЯ HTTP>CRLF
<ЗАГОЛОВОК 1>CRLF
<ЗАГОЛОВОК 2>CRLF
<ЗАГОЛОВОК N>CRLF CRLF
<ДАННЫЕ>

CRLF 두 문자의 시퀀스입니다. r и n, 요청의 첫 번째 줄, 헤더 및 데이터를 구분합니다.
<КОМАНДА> - 중 하나 CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, TRACE. 브라우저가 서버에 명령을 보냅니다. GET, "파일 내용을 보내주세요."를 의미합니다.
<URI> - 균일 자원 식별자. 예를 들어 URI =인 경우 /index.html, 클라이언트는 사이트의 메인 페이지를 요청합니다.
<ВЕРСИЯ HTTP> — 형식의 HTTP 프로토콜 버전 HTTP/X.Y. 오늘날 가장 일반적으로 사용되는 버전은 HTTP/1.1.
<ЗАГОЛОВОК N> 형식의 키-값 쌍입니다. <КЛЮЧ>: <ЗНАЧЕНИЕ>, 추가 분석을 위해 서버로 전송됩니다.
<ДАННЫЕ> — 작업을 수행하기 위해 서버에 필요한 데이터입니다. 간단한 경우가 많습니다 JSON 또는 다른 형식.

응답 형식

<ВЕРСИЯ HTTP> <КОД СТАТУСА> <ОПИСАНИЕ СТАТУСА>CRLF
<ЗАГОЛОВОК 1>CRLF
<ЗАГОЛОВОК 2>CRLF
<ЗАГОЛОВОК N>CRLF CRLF
<ДАННЫЕ>

<КОД СТАТУСА> 연산 결과를 나타내는 숫자입니다. 우리 서버는 항상 상태 200(성공적인 작업)을 반환합니다.
<ОПИСАНИЕ СТАТУСА> — 상태 코드의 문자열 표현입니다. 상태 코드 200의 경우 이는 다음과 같습니다. OK.
<ЗАГОЛОВОК N> — 요청과 동일한 형식의 헤더입니다. 우리는 제목을 반환합니다 Content-Length (파일 크기) 및 Content-Type: text/html (반환 데이터 유형).
<ДАННЫЕ> — 사용자가 요청한 데이터. 우리의 경우 이것은 이미지의 경로입니다. HTML.

파일 http_server.c (단일 스레드 서버) 파일 포함 common.h에는 다음 함수 프로토타입이 포함되어 있습니다.

common.h에 함수 프로토타입 표시

/*
 * Обработчик событий, который вызовется после того, как сокет будет
 * готов принять новое соединение.
 */
static void on_accept(void *arg, int fd, uint32_t events);

/*
 * Обработчик событий, который вызовется после того, как сокет будет
 * готов отправить HTTP ответ.
 */
static void on_send(void *arg, int fd, uint32_t events);

/*
 * Обработчик событий, который вызовется после того, как сокет будет
 * готов принять часть HTTP запроса.
 */
static void on_recv(void *arg, int fd, uint32_t events);

/*
 * Переводит входящее соединение в неблокирующий режим.
 */
static void set_nonblocking(int fd);

/*
 * Печатает переданные аргументы в stderr и выходит из процесса с
 * кодом `EXIT_FAILURE`.
 */
static noreturn void fail(const char *format, ...);

/*
 * Возвращает файловый дескриптор сокета, способного принимать новые
 * TCP соединения.
 */
static int new_server(bool reuse_port);

기능 매크로도 설명되어 있습니다. SAFE_CALL() 그리고 함수가 정의되었습니다 fail(). 매크로는 표현식의 값을 오류와 비교하고 조건이 true인 경우 함수를 호출합니다. fail():

#define SAFE_CALL(call, error)                                                 
    do {                                                                       
        if ((call) == error) {                                                   
            fail("%s", #call);                                                 
        }                                                                      
    } while (false)

기능 fail() 전달된 인수를 터미널에 인쇄합니다(예: printf()) 코드로 프로그램을 종료합니다. EXIT_FAILURE:

static noreturn void fail(const char *format, ...) {
    va_list args;
    va_start(args, format);
    vfprintf(stderr, format, args);
    va_end(args);
    fprintf(stderr, ": %sn", strerror(errno));
    exit(EXIT_FAILURE);
}

기능 new_server() 시스템 호출에 의해 생성된 "서버" 소켓의 파일 설명자를 반환합니다. socket(), bind() и listen() 비차단 모드에서 들어오는 연결을 수락할 수 있습니다.

new_server() 함수 표시

static int new_server(bool reuse_port) {
    int fd;
    SAFE_CALL((fd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, IPPROTO_TCP)),
              -1);

    if (reuse_port) {
        SAFE_CALL(
            setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, &(int){1}, sizeof(int)),
            -1);
    }

    struct sockaddr_in addr = {.sin_family = AF_INET,
                               .sin_port = htons(SERVER_PORT),
                               .sin_addr = {.s_addr = inet_addr(SERVER_IPV4)},
                               .sin_zero = {0}};

    SAFE_CALL(bind(fd, (struct sockaddr *)&addr, sizeof(addr)), -1);
    SAFE_CALL(listen(fd, SERVER_BACKLOG), -1);
    return fd;
}

소켓은 처음에 플래그를 사용하여 비차단 모드로 생성됩니다. SOCK_NONBLOCK그래서 함수에서 on_accept() (자세히 보기) 시스템 호출 accept() 스레드 실행을 중지하지 않았습니다.
면 reuse_port 같음 true, 이 함수는 옵션을 사용하여 소켓을 구성합니다. SO_REUSEPORT 를 통해 setsockopt()멀티스레드 환경에서 동일한 포트를 사용하려면("멀티스레드 서버" 섹션 참조)

이벤트 핸들러 on_accept() OS가 이벤트를 생성한 후에 호출됩니다. EPOLLIN, 이 경우 새 연결이 허용될 수 있음을 의미합니다. on_accept() 새로운 연결을 수락하고 이를 비차단 모드로 전환한 후 이벤트 핸들러에 등록합니다. on_recv() I/O 리액터에서.

on_accept() 함수 표시

static void on_accept(void *arg, int fd, uint32_t events) {
    int incoming_conn;
    SAFE_CALL((incoming_conn = accept(fd, NULL, NULL)), -1);
    set_nonblocking(incoming_conn);
    SAFE_CALL(reactor_register(reactor, incoming_conn, EPOLLIN, on_recv,
                               request_buffer_new()),
              -1);
}

이벤트 핸들러 on_recv() OS가 이벤트를 생성한 후에 호출됩니다. EPOLLIN, 이 경우 연결이 등록되었음을 의미합니다. on_accept(), 데이터를 수신할 준비가 되었습니다.

on_recv() HTTP 요청이 완전히 수신될 때까지 연결에서 데이터를 읽은 다음 핸들러를 등록합니다. on_send() HTTP 응답을 보냅니다. 클라이언트가 연결을 끊으면 소켓은 등록 취소되고 다음을 사용하여 닫힙니다. close().

on_recv() 함수 표시

static void on_recv(void *arg, int fd, uint32_t events) {
    RequestBuffer *buffer = arg;

    // Принимаем входные данные до тех пор, что recv возвратит 0 или ошибку
    ssize_t nread;
    while ((nread = recv(fd, buffer->data + buffer->size,
                         REQUEST_BUFFER_CAPACITY - buffer->size, 0)) > 0)
        buffer->size += nread;

    // Клиент оборвал соединение
    if (nread == 0) {
        SAFE_CALL(reactor_deregister(reactor, fd), -1);
        SAFE_CALL(close(fd), -1);
        request_buffer_destroy(buffer);
        return;
    }

    // read вернул ошибку, отличную от ошибки, при которой вызов заблокирует
    // поток
    if (errno != EAGAIN && errno != EWOULDBLOCK) {
        request_buffer_destroy(buffer);
        fail("read");
    }

    // Получен полный HTTP запрос от клиента. Теперь регистрируем обработчика
    // событий для отправки данных
    if (request_buffer_is_complete(buffer)) {
        request_buffer_clear(buffer);
        SAFE_CALL(reactor_reregister(reactor, fd, EPOLLOUT, on_send, buffer),
                  -1);
    }
}

이벤트 핸들러 on_send() OS가 이벤트를 생성한 후에 호출됩니다. EPOLLOUT, 이는 연결이 등록되었음을 의미합니다. on_recv(), 데이터를 보낼 준비가 되었습니다. 이 함수는 이미지와 함께 HTML이 포함된 HTTP 응답을 클라이언트에 보낸 다음 이벤트 핸들러를 다시 다음으로 변경합니다. on_recv().

on_send() 함수 표시

static void on_send(void *arg, int fd, uint32_t events) {
    const char *content = "<img "
                          "src="https://habrastorage.org/webt/oh/wl/23/"
                          "ohwl23va3b-dioerobq_mbx4xaw.jpeg">";
    char response[1024];
    sprintf(response,
            "HTTP/1.1 200 OK" CRLF "Content-Length: %zd" CRLF "Content-Type: "
            "text/html" DOUBLE_CRLF "%s",
            strlen(content), content);

    SAFE_CALL(send(fd, response, strlen(response), 0), -1);
    SAFE_CALL(reactor_reregister(reactor, fd, EPOLLIN, on_recv, arg), -1);
}

그리고 마지막으로 파일에서 http_server.c, 기능 중 main() 우리는 다음을 사용하여 I/O 리액터를 만듭니다. reactor_new(), 서버 소켓을 생성하고 등록하고 다음을 사용하여 리액터를 시작하십시오. reactor_run() 정확히 XNUMX분 동안 리소스를 해제하고 프로그램을 종료합니다.

http_server.c 표시

#include "reactor.h"

static Reactor *reactor;

#include "common.h"

int main(void) {
    SAFE_CALL((reactor = reactor_new()), NULL);
    SAFE_CALL(
        reactor_register(reactor, new_server(false), EPOLLIN, on_accept, NULL),
        -1);
    SAFE_CALL(reactor_run(reactor, SERVER_TIMEOUT_MILLIS), -1);
    SAFE_CALL(reactor_destroy(reactor), -1);
}

모든 것이 예상대로 작동하는지 확인해 보겠습니다. 컴파일(chmod a+x compile.sh && ./compile.sh 프로젝트 루트에서) 자체 작성된 서버를 시작하고 http://127.0.0.1:18470 브라우저에서 우리가 기대했던 것을 확인하세요:

성능 측정

내 차 사양을 보여주세요

$ screenfetch
 MMMMMMMMMMMMMMMMMMMMMMMMMmds+.        OS: Mint 19.1 tessa
 MMm----::-://////////////oymNMd+`     Kernel: x86_64 Linux 4.15.0-20-generic
 MMd      /++                -sNMd:    Uptime: 2h 34m
 MMNso/`  dMM    `.::-. .-::.` .hMN:   Packages: 2217
 ddddMMh  dMM   :hNMNMNhNMNMNh: `NMm   Shell: bash 4.4.20
     NMm  dMM  .NMN/-+MMM+-/NMN` dMM   Resolution: 1920x1080
     NMm  dMM  -MMm  `MMM   dMM. dMM   DE: Cinnamon 4.0.10
     NMm  dMM  -MMm  `MMM   dMM. dMM   WM: Muffin
     NMm  dMM  .mmd  `mmm   yMM. dMM   WM Theme: Mint-Y-Dark (Mint-Y)
     NMm  dMM`  ..`   ...   ydm. dMM   GTK Theme: Mint-Y [GTK2/3]
     hMM- +MMd/-------...-:sdds  dMM   Icon Theme: Mint-Y
     -NMm- :hNMNNNmdddddddddy/`  dMM   Font: Noto Sans 9
      -dMNs-``-::::-------.``    dMM   CPU: Intel Core i7-6700 @ 8x 4GHz [52.0°C]
       `/dMNmy+/:-------------:/yMMM   GPU: NV136
          ./ydNMMMMMMMMMMMMMMMMMMMMM   RAM: 2544MiB / 7926MiB
             .MMMMMMMMMMMMMMMMMMM

단일 스레드 서버의 성능을 측정해 보겠습니다. 두 개의 터미널을 열어 보겠습니다. 하나에서는 다음을 실행하겠습니다. ./http_server, 다른 - 일하다. 잠시 후 두 번째 터미널에 다음 통계가 표시됩니다.

$ wrk -c100 -d1m -t8 http://127.0.0.1:18470 -H "Host: 127.0.0.1:18470" -H "Accept-Language: en-US,en;q=0.5" -H "Connection: keep-alive"
Running 1m test @ http://127.0.0.1:18470
  8 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   493.52us   76.70us  17.31ms   89.57%
    Req/Sec    24.37k     1.81k   29.34k    68.13%
  11657769 requests in 1.00m, 1.60GB read
Requests/sec: 193974.70
Transfer/sec:     27.19MB

우리의 단일 스레드 서버는 11개의 연결에서 발생하는 분당 100만 개 이상의 요청을 처리할 수 있었습니다. 나쁘지 않은 결과인데 개선될 수 있을까요?

다중 스레드 서버

위에서 언급했듯이 I/O 리액터는 별도의 스레드로 생성될 수 있으므로 모든 CPU 코어를 활용할 수 있습니다. 이 접근 방식을 실제로 적용해 보겠습니다.

http_server_multithreaded.c 표시

#include "reactor.h"

static Reactor *reactor;
#pragma omp threadprivate(reactor)

#include "common.h"

int main(void) {
#pragma omp parallel
    {
        SAFE_CALL((reactor = reactor_new()), NULL);
        SAFE_CALL(reactor_register(reactor, new_server(true), EPOLLIN,
                                   on_accept, NULL),
                  -1);
        SAFE_CALL(reactor_run(reactor, SERVER_TIMEOUT_MILLIS), -1);
        SAFE_CALL(reactor_destroy(reactor), -1);
    }
}

이제 모든 스레드 자신의 소유 반응기:

static Reactor *reactor;
#pragma omp threadprivate(reactor)

함수 인수에 유의하세요. new_server() 옹호자 true. 이는 서버 소켓에 옵션을 할당한다는 의미입니다. SO_REUSEPORT멀티 스레드 환경에서 사용하려면 자세한 내용을 읽을 수 있습니다. 여기에.

두 번째 실행

이제 다중 스레드 서버의 성능을 측정해 보겠습니다.

$ wrk -c100 -d1m -t8 http://127.0.0.1:18470 -H "Host: 127.0.0.1:18470" -H "Accept-Language: en-US,en;q=0.5" -H "Connection: keep-alive"
Running 1m test @ http://127.0.0.1:18470
  8 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.14ms    2.53ms  40.73ms   89.98%
    Req/Sec    79.98k    18.07k  154.64k    78.65%
  38208400 requests in 1.00m, 5.23GB read
Requests/sec: 635876.41
Transfer/sec:     89.14MB

1분 동안 처리되는 요청 수가 ~3.28배 증가했습니다! 하지만 우리는 라운드 수보다 XNUMX만 정도 부족했으므로 이를 고치도록 노력해 보겠습니다.

먼저 생성된 통계를 살펴보겠습니다. 반환 한:

$ sudo perf stat -B -e task-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,branches,branch-misses,cache-misses ./http_server_multithreaded

 Performance counter stats for './http_server_multithreaded':

     242446,314933      task-clock (msec)         #    4,000 CPUs utilized          
         1 813 074      context-switches          #    0,007 M/sec                  
             4 689      cpu-migrations            #    0,019 K/sec                  
               254      page-faults               #    0,001 K/sec                  
   895 324 830 170      cycles                    #    3,693 GHz                    
   621 378 066 808      instructions              #    0,69  insn per cycle         
   119 926 709 370      branches                  #  494,653 M/sec                  
     3 227 095 669      branch-misses             #    2,69% of all branches        
           808 664      cache-misses                                                

      60,604330670 seconds time elapsed

CPU 선호도 사용, 다음으로 컴파일 -march=native, PGO, 적중 횟수 증가 캐시, 증가하다 MAX_EVENTS 사용하다 EPOLLET 성능이 크게 향상되지 않았습니다. 그런데 동시 연결 수를 늘리면 어떻게 될까요?

352개의 동시 연결에 대한 통계:

$ wrk -c352 -d1m -t8 http://127.0.0.1:18470 -H "Host: 127.0.0.1:18470" -H "Accept-Language: en-US,en;q=0.5" -H "Connection: keep-alive"
Running 1m test @ http://127.0.0.1:18470
  8 threads and 352 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.12ms    3.79ms  68.23ms   87.49%
    Req/Sec    83.78k    12.69k  169.81k    83.59%
  40006142 requests in 1.00m, 5.48GB read
Requests/sec: 665789.26
Transfer/sec:     93.34MB

원하는 결과를 얻었으며 1분 동안 처리된 요청 수가 연결 수에 따라 달라지는 것을 보여주는 흥미로운 그래프가 표시됩니다.

수백 개의 연결 후에 두 서버 모두에 대해 처리된 요청 수가 급격히 감소하는 것을 볼 수 있습니다(멀티 스레드 버전에서는 이것이 더 눈에 띕니다). 이것이 Linux TCP/IP 스택 구현과 관련이 있습니까? 그래프의 이러한 동작과 다중 스레드 및 단일 스레드 옵션에 대한 최적화에 대한 가정을 댓글에 자유롭게 적어주세요.

방법 유명한 설명에서 이 성능 테스트는 실제 로드 하에서 I/O 리액터의 동작을 보여주지 않습니다. 왜냐하면 거의 항상 서버가 데이터베이스와 상호 작용하고, 로그를 출력하고, 암호화를 사용하기 때문입니다. TLS 등으로 인해 하중이 불균일하게 됩니다(동적). 타사 구성 요소와 함께 테스트하는 것은 I/O proactor에 대한 문서에서 수행됩니다.

I/O 리액터의 단점

I/O 리액터에는 다음과 같은 단점이 있다는 점을 이해해야 합니다.

멀티 스레드 환경에서 I/O 리액터를 사용하는 것은 다소 어렵습니다. 흐름을 수동으로 관리해야 합니다.
실습에 따르면 대부분의 경우 로드가 균일하지 않아 한 스레드가 작업에 바쁜 동안 다른 스레드가 로깅될 수 있습니다.
하나의 이벤트 핸들러가 스레드를 차단하면 시스템 선택기 자체도 차단되므로 찾기 어려운 버그가 발생할 수 있습니다.

이러한 문제를 해결합니다. I/O 프로액터, 스레드 풀에 로드를 균등하게 분배하는 스케줄러가 있는 경우가 많으며 더 편리한 API도 있습니다. 나중에 다른 기사에서 이에 대해 이야기하겠습니다.

결론

이론에서 바로 프로파일러 배기 장치로의 여정이 끝나는 곳입니다.

다양한 수준의 편리함과 속도를 갖춘 네트워크 소프트웨어를 작성하는 데 있어 똑같이 흥미로운 접근 방식이 많이 있기 때문에 이것에 대해 너무 깊이 생각해서는 안 됩니다. 제 생각에는 흥미로운 링크가 아래에 제공됩니다.

때까지 우리는 다시 만날!

흥미로운 프로젝트

그들 자신
- 리벤트
- 리베프
- 리브
- libevhtp
- 해방하다
- DPDK
- 넷맵
- PF_RING
녹
- 미오
- 토키오
- smoltcp

또 무엇을 읽어야 하나요?

출처 : habr.com

모든 기능을 갖춘 베어 C I/O 리액터

소개

머리말