შესავალი

I/O რეაქტორი (ერთ ძაფიანი ღონისძიების ციკლი) არის მაღალი დატვირთვის პროგრამული უზრუნველყოფის ჩაწერის ნიმუში, რომელიც გამოიყენება ბევრ პოპულარულ გადაწყვეტაში:

ამ სტატიაში ჩვენ გადავხედავთ I/O რეაქტორის წვდომას და წვდომას და როგორ მუშაობს იგი, დავწერთ იმპლემენტაციას კოდის 200 სტრიქონზე ნაკლებ ხაზში და დავამუშავებთ მარტივ HTTP სერვერს 40 მილიონ მოთხოვნაზე/წთ.

წინასიტყვაობა

სტატია დაიწერა იმისთვის, რომ გავიგოთ I/O რეაქტორის ფუნქციონირება და, შესაბამისად, გავიგოთ რისკები მისი გამოყენებისას.
სტატიის გასაგებად საჭიროა საფუძვლების ცოდნა. C ენა და გარკვეული გამოცდილება ქსელის აპლიკაციების შემუშავებაში.
ყველა კოდი დაწერილია C ენაზე მკაცრად (სიფრთხილე: გრძელი PDF) C11 სტანდარტით Linux-ისთვის და ხელმისაწვდომია GitHub.

რატომ აკეთებენ ამას?

ინტერნეტის მზარდი პოპულარობით, ვებ სერვერებს სჭირდებოდათ ერთდროულად დიდი რაოდენობით კავშირების დამუშავება და, შესაბამისად, სცადეს ორი მიდგომა: I/O-ს დაბლოკვა ოპერაციული სისტემის დიდ რაოდენობაზე და I/O-ს დაუბლოკავი კომბინაციით. მოვლენის შეტყობინებების სისტემა, რომელსაც ასევე უწოდებენ "სისტემის ამომრჩეველს" (ეპოლი/რიგში/IOCP/ და ა.შ.).

პირველი მიდგომა მოიცავდა ახალი OS ძაფის შექმნას ყოველი შემომავალი კავშირისთვის. მისი მინუსი არის ცუდი მასშტაბირება: ოპერაციულ სისტემას მოუწევს ბევრის დანერგვა კონტექსტური გადასვლები и სისტემური ზარები. ისინი ძვირადღირებული ოპერაციებია და შეიძლება გამოიწვიოს თავისუფალი RAM-ის ნაკლებობა კავშირების შთამბეჭდავი რაოდენობით.

შეცვლილი ვერსია ხაზს უსვამს ძაფების ფიქსირებული რაოდენობა (thread pool), რითაც ხელს უშლის სისტემის შესრულების შეწყვეტას, მაგრამ ამავდროულად შემოაქვს ახალი პრობლემა: თუ thread pool ამჟამად დაბლოკილია ხანგრძლივი წაკითხვის ოპერაციებით, მაშინ სხვა სოკეტები, რომლებსაც უკვე შეუძლიათ მონაცემების მიღება, ვერ შეძლებენ. ასე გააკეთე.

მეორე მიდგომა იყენებს ღონისძიების შეტყობინებების სისტემა (სისტემის სელექტორი) მოწოდებული OS-ის მიერ. ეს სტატია განიხილავს სისტემის ამორჩევის ყველაზე გავრცელებულ ტიპს, რომელიც დაფუძნებულია გაფრთხილებებზე (მოვლენებზე, შეტყობინებებზე) I/O ოპერაციებისთვის მზადყოფნის შესახებ და არა შეტყობინებები მათი დასრულების შესახებ. მისი გამოყენების გამარტივებული მაგალითი შეიძლება წარმოდგენილი იყოს შემდეგი ბლოკ-სქემით:

განსხვავება ამ მიდგომებს შორის შემდეგია:

I/O ოპერაციების ბლოკირება შეაჩეროს მომხმარებლის ნაკადი მანამდესანამ OS გამართულია დეფრაგმენტები შემომავალი IP პაკეტები ბაიტის ნაკადად (TCP, მონაცემების მიღება) ან არ იქნება საკმარისი ადგილი ჩაწერის შიდა ბუფერებში შემდგომი გაგზავნისთვის NIC (მონაცემების გაგზავნა).
სისტემის ამომრჩევი დროის განმავლობაში აცნობებს პროგრამას, რომ OS უკვე დეფრაგმენტირებული IP პაკეტები (TCP, მონაცემთა მიღება) ან საკმარისი ადგილი ჩაწერის შიდა ბუფერებში უკვე ხელმისაწვდომი (მონაცემების გაგზავნა).

რომ შევაჯამოთ, OS-ის ძაფების დაჯავშნა თითოეული I/O-სთვის არის გამოთვლითი სიმძლავრის დაკარგვა, რადგან სინამდვილეში, ძაფები არ ასრულებენ სასარგებლო სამუშაოს (აქედან მოდის ეს ტერმინი "პროგრამული შეფერხება"). სისტემის სელექტორი წყვეტს ამ პრობლემას, რაც საშუალებას აძლევს მომხმარებლის პროგრამას გამოიყენოს CPU რესურსები ბევრად უფრო ეკონომიურად.

I/O რეაქტორის მოდელი

I/O რეაქტორი მოქმედებს როგორც ფენა სისტემის ამომრჩეველსა და მომხმარებლის კოდს შორის. მისი მოქმედების პრინციპი აღწერილია შემდეგი ბლოკ-სქემით:

შეგახსენებთ, რომ მოვლენა არის შეტყობინება იმის შესახებ, რომ გარკვეულ სოკეტს შეუძლია შეასრულოს არადაბლოკვის I/O ოპერაცია.
მოვლენის დამმუშავებელი არის ფუნქცია, რომელსაც იძახის I/O რეაქტორი მოვლენის მიღებისას, რომელიც შემდეგ ასრულებს არადაბლოკვის I/O ოპერაციას.

მნიშვნელოვანია აღინიშნოს, რომ I/O რეაქტორი, განსაზღვრებით, არის ერთძაფის, მაგრამ არაფერი უშლის ხელს კონცეფციის გამოყენებას მრავალ ძაფიან გარემოში 1 ძაფის: 1 რეაქტორის თანაფარდობით, რითაც გადამუშავდება ყველა CPU ბირთვი.

Реализация

ჩვენ განვათავსებთ საჯარო ინტერფეისს ფაილში reactor.h, და განხორციელება - შემოსული reactor.c. reactor.h შედგება შემდეგი განცხადებებისაგან:

დეკლარაციების ჩვენება რეაქტორში.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 რეაქტორის სტრუქტურა შედგება ფაილის აღმწერი სელექტორი ეპოლი и ჰეშის ცხრილები GHashTable, რომელიც ასახავს თითოეულ სოკეტს CallbackData (მოვლენის დამმუშავებლის სტრუქტურა და მომხმარებლის არგუმენტი ამისთვის).

Reactor-ისა და CallbackData-ის ჩვენება

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

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

გთხოვთ გაითვალისწინოთ, რომ ჩვენ გავააქტიურეთ დამუშავების შესაძლებლობა არასრული ტიპი ინდექსის მიხედვით. IN reactor.h ჩვენ ვაცხადებთ სტრუქტურას reactorდა 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, რომელიც შეიცავს შემდეგ ფუნქციების პროტოტიპებს:

ფუნქციის პროტოტიპების ჩვენება საერთო.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(), მზად არის მონაცემების გასაგზავნად. ეს ფუნქცია კლიენტს უგზავნის HTTP პასუხს, რომელიც შეიცავს HTML გამოსახულებას და შემდეგ ცვლის მოვლენის დამმუშავებელს. 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() ზუსტად ერთი წუთის განმავლობაში, შემდეგ კი რესურსებს ვათავისუფლებთ და გამოვდივართ პროგრამიდან.

აჩვენე 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 პროექტის root-ში) და გაუშვით თვითნაწერი სერვერი, გახსენით 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 მილიონი გვაკლდა მრგვალი რიცხვისთვის, ამიტომ ვცადოთ ამის გამოსწორება.

ჯერ შევხედოთ გამომუშავებულ სტატისტიკას perf:

$ 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 Affinity-ის გამოყენება, კომპილაციასთან ერთად -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 პროაქტორის შესახებ.

I/O რეაქტორის ნაკლოვანებები

თქვენ უნდა გესმოდეთ, რომ I/O რეაქტორი არ არის ნაკლოვანებების გარეშე, კერძოდ:

I/O რეაქტორის გამოყენება მრავალძაფიან გარემოში გარკვეულწილად უფრო რთულია, რადგან თქვენ მოგიწევთ ნაკადების ხელით მართვა.
პრაქტიკა გვიჩვენებს, რომ უმეტეს შემთხვევაში დატვირთვა არაერთგვაროვანია, რამაც შეიძლება გამოიწვიოს ერთი ძაფის ჭრა, ხოლო მეორე დაკავებულია სამუშაოთი.
თუ ერთი მოვლენის დამმუშავებელი დაბლოკავს თემას, თავად სისტემის ამომრჩეველიც დაბლოკავს, რამაც შეიძლება გამოიწვიოს ძნელად საპოვნელი შეცდომები.

წყვეტს ამ პრობლემებს I/O პროაქტორი, რომელსაც ხშირად აქვს გრაფიკი, რომელიც თანაბრად ანაწილებს დატვირთვას ძაფების აუზზე და ასევე აქვს უფრო მოსახერხებელი API. ამაზე მოგვიანებით, ჩემს სხვა სტატიაში ვისაუბრებთ.

დასკვნა

სწორედ აქ დასრულდა ჩვენი მოგზაურობა თეორიიდან პირდაპირ პროფილერის გამონაბოლქვში.

თქვენ არ უნდა შეჩერდეთ ამაზე, რადგან არსებობს მრავალი სხვა, თანაბრად საინტერესო მიდგომა ქსელური პროგრამული უზრუნველყოფის დაწერისთვის სხვადასხვა დონის მოხერხებულობითა და სიჩქარით. საინტერესოა, ჩემი აზრით, ქვემოთ მოცემულია ბმულები.

შემდეგ ჯერზე!

საინტერესო პროექტები

თავი
Rust

კიდევ რა წავიკითხო?

წყარო: www.habr.com

სრულფასოვანი შიშველი-C I/O რეაქტორი

შესავალი

წინასიტყვაობა

რატომ აკეთებენ ამას?

I/O რეაქტორის მოდელი

Реализация

ერთი ხრახნიანი სერვერი

მოთხოვნის ფორმატი

პასუხის ფორმატი

შესრულების გაზომვა

მრავალძაფიანი სერვერი

მეორე გაშვება

I/O რეაქტორის ნაკლოვანებები

დასკვნა

საინტერესო პროექტები

კიდევ რა წავიკითხო?

ახალი კომენტარის დამატება

სრულფასოვანი შიშველი-C I/O რეაქტორი

შესავალი

წინასიტყვაობა

რატომ აკეთებენ ამას?

I/O რეაქტორის მოდელი

Реализация

ერთი ხრახნიანი სერვერი

მოთხოვნის ფორმატი

პასუხის ფორმატი

შესრულების გაზომვა

მრავალძაფიანი სერვერი

მეორე გაშვება

I/O რეაქტორის ნაკლოვანებები

დასკვნა

საინტერესო პროექტები

კიდევ რა წავიკითხო?

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება