מבוא

כור I/O (הברגה בודדת לולאת אירועים) הוא דפוס לכתיבת תוכנה בעומס גבוה, בשימוש בפתרונות פופולריים רבים:

במאמר זה, נבחן את הפרטים הקטנים של כור I/O וכיצד הוא פועל, נכתוב מימוש בפחות מ-200 שורות קוד, ונבצע תהליך פשוט של שרת HTTP מעל 40 מיליון בקשות לדקה.

פְּתִיחַ

המאמר נכתב כדי לעזור להבין את תפקוד כור ה-I/O, ולכן להבין את הסיכונים בעת השימוש בו.
נדרש ידע ביסודות כדי להבין את המאמר. שפת ג וניסיון מסוים בפיתוח אפליקציות רשת.
כל הקוד כתוב בשפת C אך ורק לפי (זהירות: PDF ארוך) לתקן C11 עבור לינוקס וזמין ב GitHub.

למה לעשות את זה?

עם הפופולריות הגוברת של האינטרנט, שרתי אינטרנט החלו לטפל במספר רב של חיבורים בו-זמנית, ולכן נוסו שתי גישות: חסימת I/O במספר רב של שרשורי מערכת הפעלה ו-I/O לא חוסם בשילוב עם מערכת התראות על אירועים, הנקראת גם "בורר מערכת" (אפול/kqueue/IOCP/וכו).

הגישה הראשונה כללה יצירת שרשור מערכת הפעלה חדש עבור כל חיבור נכנס. החיסרון שלו הוא מדרגיות גרועה: מערכת ההפעלה תצטרך ליישם רבים מעברי הקשר и שיחות מערכת. מדובר בפעולות יקרות ויכולות להוביל למחסור ב-RAM פנוי עם מספר מרשים של חיבורים.

הגרסה ששונתה מדגישה מספר קבוע של חוטים (מאגר שרשורים), ובכך מונע מהמערכת לבטל את הביצוע, אך בו-זמנית מציגה בעיה חדשה: אם מאגר אשכולות נחסם כעת על ידי פעולות קריאה ארוכות, אז שקעים אחרים שכבר מסוגלים לקבל נתונים לא יוכלו עשה כך.

הגישה השנייה משתמשת מערכת הודעות על אירועים (בורר מערכת) מסופק על ידי מערכת ההפעלה. מאמר זה דן בסוג הנפוץ ביותר של בורר מערכת, בהתבסס על התראות (אירועים, התראות) על מוכנות לפעולות קלט/פלט, ולא על הודעות על השלמתם. דוגמה פשוטה לשימוש בו יכולה להיות מיוצגת על ידי תרשים הבלוק הבא:

ההבדל בין הגישות הללו הוא כדלקמן:

חסימת פעולות קלט/פלט לְהַשְׁעוֹת זרימת משתמשים עדעד שמערכת ההפעלה תהיה תקינה איחוי נִכנָס מנות IP לזרם בתים (TCP, מקבל נתונים) או שלא יהיה מספיק מקום פנוי במאגרי הכתיבה הפנימיים לשליחה שלאחר מכן באמצעות NIC (שליחת נתונים).
בורר מערכת אחרי זמן מה מודיע לתוכנית שמערכת ההפעלה כבר מנות IP מאוחות (TCP, קליטת נתונים) או מספיק מקום במאגרי כתיבה פנימיים כבר זמין (שליחת נתונים).

לסיכום, שמירת שרשור של מערכת הפעלה לכל I/O היא בזבוז של כוח מחשוב, מכיוון שבמציאות, השרשורים לא עושים עבודה מועילה (מכאן מגיע המונח "הפסקת תוכנה"). בורר המערכת פותר בעיה זו, ומאפשר לתוכנית המשתמש להשתמש במשאבי CPU בצורה הרבה יותר חסכונית.

דגם כור I/O

כור ה-I/O פועל כשכבה בין בורר המערכת לקוד המשתמש. עקרון פעולתו מתואר על ידי תרשים הבלוק הבא:

הרשו לי להזכיר לכם שאירוע הוא הודעה על כך ששקע מסוים מסוגל לבצע פעולת I/O לא חוסמת.
מטפל באירועים הוא פונקציה הנקראת על ידי כור ה-I/O כאשר אירוע מתקבל, אשר לאחר מכן מבצע פעולת I/O לא חוסמת.

חשוב לציין כי כור ה-I/O הוא בהגדרה חד-הברגה, אך אין דבר שמפריע למושג להשתמש בסביבה מרובת-הברגה ביחס של 1 חוט: כור 1, ובכך למחזר את כל ליבות ה-CPU.

Реализация

נמקם את הממשק הציבורי בקובץ reactor.h, ויישום - ב reactor.c. 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 מורכב מ מתאר קובץ בוחר אפול и טבלאות חשיש 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(). המאקרו משווה את הערך של הביטוי עם השגיאה, ואם התנאי נכון, קורא לפונקציה 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() נקרא לאחר שמערכת ההפעלה יוצרת אירוע 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() נקרא לאחר שמערכת ההפעלה יוצרת אירוע 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() נקרא לאחר שמערכת ההפעלה יוצרת אירוע 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 בשורש הפרויקט) והפעל את השרת שנכתב בעצמו, פתח 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. לאחר דקה, הנתונים הסטטיסטיים הבאים יוצגו בטרמינל השני:

$ 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 בשרשורים נפרדים, ובכך לנצל את כל ליבות המעבד. בואו ליישם את הגישה הזו בפועל:

הצג את 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 מיליון מהמספר העגול, אז בואו ננסה לתקן את זה.

ראשית בואו נסתכל על הסטטיסטיקה שנוצרה 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

התקבלה התוצאה הרצויה, ואיתה גרף מעניין המראה את התלות של מספר הבקשות המעובדות בדקה אחת במספר החיבורים:

אנו רואים שאחרי כמה מאות חיבורים, מספר הבקשות המעובדות עבור שני השרתים יורד בחדות (בגרסת ריבוי ההליכים זה בולט יותר). האם זה קשור למימוש מחסנית TCP/IP של Linux? אל תהסס לכתוב את ההנחות שלך לגבי התנהגות זו של הגרף ואופטימיזציות לאפשרויות מרובי חוטים ושרשור בודד בהערות.

כמו ציינתי בהערות, מבחן ביצועים זה אינו מראה את ההתנהגות של כור ה-I/O תחת עומסים אמיתיים, מכיוון שכמעט תמיד השרת מקיים אינטראקציה עם מסד הנתונים, מוציא יומנים, משתמש בקריפטוגרפיה עם TLS וכו', כתוצאה מכך העומס הופך לא אחיד (דינמי). בדיקות יחד עם רכיבי צד שלישי יבוצעו במאמר על פרואקטור ה-I/O.

חסרונות של כור I/O

אתה צריך להבין שכור ה-I/O אינו חף מחסרונותיו, כלומר:

השימוש בכור קלט/פלט בסביבה מרובת פתילים הוא קצת יותר קשה, מכיוון תצטרך לנהל את הזרימות באופן ידני.
התרגול מראה שברוב המקרים העומס אינו אחיד, מה שיכול להוביל לרישום שרשור אחד בעוד אחר עסוק בעבודה.
אם מטפל אחד באירועים חוסם שרשור, אז גם בורר המערכת עצמו יחסום, מה שעלול להוביל לבאגים שקשה למצוא אותם.

פותר את הבעיות הללו פרואקטור I/O, שלעיתים קרובות יש לו מתזמן שמחלק את העומס באופן שווה למאגר של שרשורים, ויש לו גם API נוח יותר. נדבר על זה מאוחר יותר, במאמר אחר שלי.

מסקנה

כאן הגיע לסיומו המסע שלנו מהתיאוריה היישר אל אגזוז הפרופילים.

אתה לא צריך להתעכב על זה, כי יש עוד הרבה גישות מעניינות לא פחות לכתיבת תוכנות רשת ברמות שונות של נוחות ומהירות. מעניין, לדעתי, קישורים מובאים למטה.

להתראות שוב!

פרויקטים מעניינים

סי
- חביב
- ליבב
- ליבוב
- libevhtp
- משחרר
- DPDK
- מפת רשת
- PF_RING
חלודה
- Mio
- טוקיו
- smoltcp

מה עוד כדאי לי לקרוא?

מקור: www.habr.com

כור I/O חשוף עם תכונות מלאות