परिचय

I / O रिएक्टर (एकल-थ्रेडेड इवेंट लूप ) अत्यधिक लोड किए गए सॉफ़्टवेयर को लिखने के लिए एक पैटर्न है, जिसका उपयोग कई लोकप्रिय समाधानों में किया जाता है:

• Node.js
• टो
• हस्तांतरण
• क्रोमियम
• memcached
• ...

इस लेख में, हम I / O रिएक्टर के इन्स और बहिष्कार और इसके संचालन के सिद्धांत पर विचार करेंगे, कोड की 200 से कम लाइनों के लिए एक कार्यान्वयन लिखें और एक साधारण HTTP सर्वर को 40 मिलियन से अधिक अनुरोधों / मिनट पर संसाधित करने के लिए बाध्य करें।

प्रस्तावना

• लेख I / O रिएक्टर के कामकाज को समझने में मदद करने के उद्देश्य से लिखा गया था, और इसलिए इसका उपयोग करते समय जोखिमों का एहसास करने के लिए।
• लेख में महारत हासिल करने के लिए, सी भाषा की मूल बातों का ज्ञान और नेटवर्क अनुप्रयोगों को विकसित करने में थोड़ा अनुभव आवश्यक है।
• सभी कोड सी में सख्ती से ( सावधानी से: लंबे पीडीएफ ) लिनक्स के लिए C11 मानक के अनुसार लिखे गए हैं और GitHub पर उपलब्ध है ।

इसकी आवश्यकता क्यों है?

इंटरनेट की बढ़ती लोकप्रियता के साथ, वेब सर्वर को एक ही समय में बड़ी संख्या में कनेक्शन की आवश्यकता होती है, और इसलिए दो दृष्टिकोणों की कोशिश की गई थी: एक बड़ी संख्या में ओएस थ्रेड्स पर अवरुद्ध I / O और एक इवेंट नोटिफिकेशन सिस्टम के साथ संयोजन में गैर-अवरुद्ध I / O, जिसे "सिस्टम" भी कहा जाता है। चयनकर्ता "( epoll / kqueue / IOCP / etc)।

प्रत्येक आने वाले कनेक्शन के लिए एक नया ओएस थ्रेड बनाने में शामिल पहला दृष्टिकोण। इसका नुकसान खराब स्केलेबिलिटी है: ऑपरेटिंग सिस्टम को कई संदर्भ परिवर्तन और सिस्टम कॉल करना होगा । वे महंगे ऑपरेशन हैं और कनेक्शन की प्रभावशाली संख्या के साथ मुफ्त रैम की कमी हो सकती है।

संशोधित संस्करण थ्रेड्स (थ्रेड पूल) की एक निश्चित संख्या आवंटित करता है , जिससे सिस्टम को असामान्य रूप से निष्पादन को रोकना बंद हो जाता है, लेकिन साथ ही साथ एक नई समस्या भी पेश करता है: यदि दिए गए समय पर थ्रेड पूल लंबे समय तक पढ़ने के संचालन से अवरुद्ध हो जाता है, तो अन्य पॉकेट जो पहले से ही डेटा प्राप्त करने में सक्षम हैं। ऐसा करने में सक्षम नहीं होगा।

दूसरा दृष्टिकोण इवेंट सूचना प्रणाली (सिस्टम चयनकर्ता) का उपयोग करता है जो ओएस प्रदान करता है। यह लेख आई / ओ संचालन के लिए तत्परता के बारे में अलर्ट (घटनाओं, सूचनाओं) के आधार पर सबसे सामान्य प्रकार के सिस्टम चयनकर्ता की चर्चा करता है, बजाय उनके पूरा होने के बारे में अलर्ट के । इसके उपयोग का एक सरल उदाहरण निम्नलिखित फ़्लोचार्ट द्वारा दर्शाया जा सकता है:

इन तरीकों के बीच अंतर इस प्रकार है:

• I / O संचालन को अवरुद्ध करना तब तक उपयोगकर्ता स्ट्रीम को निलंबित करता है जब तक OS आने वाली IP पैकेट को बाइट स्ट्रीम ( TCP , डेटा प्राप्त करना) में ठीक से डीफ़्रेग्मेंट नहीं करता है या एनआईसी (डेटा भेजना) के माध्यम से आंतरिक राइट बफ़र्स में पर्याप्त स्थान खाली कर देता है।
• थोड़ी देर बाद, सिस्टम चयनकर्ता उस प्रोग्राम को सूचित करता है कि ओएस ने पहले से ही आईपी ​​पैकेट (टीसीपी, डेटा प्राप्त करना) को डीफ़्रैग्मेन्ट कर दिया है या आंतरिक रिकॉर्डिंग बफ़र्स में पर्याप्त जगह पहले से ही उपलब्ध है (डेटा भेज रहा है)।

संक्षेप में, प्रत्येक I / O के लिए OS थ्रेड को जमा करना कंप्यूटिंग शक्ति की बर्बादी है, क्योंकि वास्तव में, थ्रेड्स उपयोगी कार्य के साथ व्यस्त नहीं हैं (शब्द "सॉफ्टवेयर रुकावट" में इसकी जड़ें हैं )। सिस्टम चयनकर्ता इस समस्या को हल करता है उपयोगकर्ता प्रोग्राम को सीपीयू संसाधनों का अधिक आर्थिक रूप से उपभोग करने की अनुमति देता है।

रिएक्टर I / O मॉडल

I / O रिएक्टर सिस्टम चयनकर्ता और उपयोगकर्ता कोड के बीच एक परत के रूप में कार्य करता है। इसके संचालन का सिद्धांत निम्नलिखित फ्लोचार्ट द्वारा वर्णित है:

• आपको याद दिलाता हूं कि एक घटना एक अधिसूचना है कि एक निश्चित सॉकेट एक गैर-अवरुद्ध I / O ऑपरेशन करने में सक्षम है।
• एक इवेंट हैंडलर एक फ़ंक्शन है जिसे I / O रिएक्टर द्वारा बुलाया जाता है जब कोई ईवेंट प्राप्त होता है, जो तब एक नॉन-ब्लॉकिंग I / O ऑपरेशन करता है।

यह ध्यान रखना महत्वपूर्ण है कि I / O रिएक्टर परिभाषा एकल-थ्रेडेड है, लेकिन 1 स्ट्रीम: 1 रिएक्टर के संबंध में बहु-थ्रेडेड वातावरण में अवधारणा का उपयोग करने से कुछ भी नहीं रोकता है, जिससे सभी सीपीयू कोर का उपयोग होता है।

कार्यान्वयन

हमने सार्वजनिक इंटरफ़ेस को reactor.h फ़ाइल, और reactor.c में कार्यान्वयन में 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 हैश तालिका है , जो प्रत्येक सॉकेट मैप्स GHashTable (एक ईवेंट हैंडलर से एक संरचना और इसके लिए एक उपयोगकर्ता तर्क) के होते हैं।

 struct reactor { int epoll_fd; GHashTable *table; // (int, CallbackData) }; typedef struct { Callback callback; void *arg; } CallbackData; 

कृपया ध्यान दें कि हमने सूचक द्वारा अपूर्ण प्रकार को संभालने की क्षमता का उपयोग किया है। reactor.h हम reactor की संरचना की घोषणा करते हैं, और reactor.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 करने के लिए यूजर पॉइंटर।

 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 वेब सर्वर लिखेंगे।

 <> <URI> < HTTP>CRLF < 1>CRLF < 2>CRLF < N>CRLF CRLF <> 

 < HTTP> < > < >CRLF < 1>CRLF < 2>CRLF < N>CRLF CRLF <> 

http_server.c (एकल-थ्रेडेड सर्वर) फ़ाइल में एक 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() फ़ंक्शन परिभाषित है। मैक्रो त्रुटि के साथ अभिव्यक्ति के मूल्य की तुलना करता है, और यदि शर्त पूरी हो जाती है, तो यह fail() फ़ंक्शन को कॉल करता है:

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

fail() फंक्शन, पास किए गए तर्कों को टर्मिनल (जैसे EXIT_FAILURE fail() प्रिंट करता है और 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, ": %s\n", strerror(errno)); exit(EXIT_FAILURE); } 

new_server() फ़ंक्शन सिस्टम कॉल socket() , bind() और listen() द्वारा बनाई गई "सर्वर" सॉकेट की फ़ाइल डिस्क्रिप्टर को लौटाता है और गैर-अवरोधक मोड में आने वाले कनेक्शन को स्वीकार करने में सक्षम है।

 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 , तो यह फ़ंक्शन सॉकेट को एक बहु-थ्रेडेड वातावरण में समान पोर्ट का उपयोग करने के लिए setsockopt() का उपयोग करके SO_REUSEPORT विकल्प के साथ कॉन्फ़िगर करेगा (अनुभाग "मल्टी-थ्रेडेड सर्वर" देखें)।

on_accept() ईवेंट हैंडलर को तब बुलाया जाता है जब OS EPOLLIN ईवेंट उत्पन्न करता है, इस मामले में इसका अर्थ है कि एक नया कनेक्शन स्वीकार किया जा सकता है। on_accept() एक नए कनेक्शन को स्वीकार करता है, इसे गैर-अवरोधक मोड पर स्विच करता है और on_recv() O रिएक्टर में on_recv() ईवेंट हैंडलर के साथ रजिस्टर करता है।

 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); } 

OS को EPOLLIN बनाने के बाद on_recv() ईवेंट हैंडलर को कॉल किया जाता है, इस मामले में इसका अर्थ है कि on_accept() द्वारा पंजीकृत कनेक्शन डेटा स्वीकार करने के लिए तैयार है।

on_recv() पूर्ण HTTP अनुरोध प्राप्त होने तक कनेक्शन से डेटा पढ़ता है, फिर वह HTTP प्रतिक्रिया भेजने के लिए on_send() हैंडलर को पंजीकृत करता है। यदि ग्राहक डिस्कनेक्ट करता है, तो सॉकेट डेरेगिस्ट्स और close() साथ close() हो जाता है।

 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 प्रतिक्रिया भेजता है, और फिर इवेंट हैंडलर को on_recv() ।

 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() फ़ंक्शन में, हम reactor_new() का उपयोग करके एक I / O रिएक्टर बनाते हैं, एक सर्वर सॉकेट बनाते हैं और इसे पंजीकृत करते हैं, रिएक्टर को reactor_run() ठीक एक मिनट के reactor_run() शुरू करते हैं, और फिर संसाधनों को छोड़ देते हैं और बाहर निकलते हैं कार्यक्रम से।

 #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 रिएक्टर को अलग-अलग धाराओं में बनाया जा सकता है, जिससे सभी CPU कोर का उपयोग किया जा सकता है। आइए इस दृष्टिकोण को व्यवहार में लागू करें:

 #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 

सीपीयू आत्मीयता का उपयोग करना , -march=native , -march=native साथ संकलित करना, कैश में हिट की संख्या 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 मिनट में संसाधित अनुरोधों की संख्या पर निर्भरता दिखाने वाला एक दिलचस्प ग्राफ:

हम देखते हैं कि सैकड़ों कनेक्शनों के बाद, दोनों सर्वरों से संसाधित अनुरोधों की संख्या तेजी से गिरती है (एक बहु-थ्रेडेड संस्करण में, यह अधिक ध्यान देने योग्य है)। क्या यह लिनक्स टीसीपी / आईपी स्टैक कार्यान्वयन से संबंधित है? इस तरह के ग्राफ व्यवहार और टिप्पणियों में बहुस्तरीय और एकल-थ्रेडेड विकल्पों के अनुकूलन के बारे में अपनी मान्यताओं को लिखने के लिए स्वतंत्र महसूस करें।

जैसा कि टिप्पणियों में उल्लेख किया गया है, यह प्रदर्शन परीक्षण वास्तविक भार पर आई / ओ रिएक्टर के व्यवहार को नहीं दिखाता है, क्योंकि लगभग हमेशा सर्वर डेटाबेस के साथ बातचीत करता है, लॉग प्रदर्शित करता है, टीएलएस के साथ क्रिप्टोग्राफी का उपयोग करता है, आदि, जिसके परिणामस्वरूप लोड विषम (गतिशील) है। तृतीय-पक्ष घटकों के साथ परीक्षण I / O प्रोक्टर के बारे में एक लेख में आयोजित किया जाएगा।

आई / ओ रिएक्टर के नुकसान

आपको यह समझने की आवश्यकता है कि I / O रिएक्टर कमियां के बिना नहीं है, अर्थात्:

• बहु-थ्रेडेड वातावरण में I / O रिएक्टर का उपयोग करना कुछ अधिक कठिन है, क्योंकि आपको मैन्युअल रूप से प्रवाह का प्रबंधन करना होगा।
• अभ्यास से पता चलता है कि ज्यादातर मामलों में भार विषम है, जो इस तथ्य को जन्म दे सकता है कि एक धागा नीचे रखा जाएगा जबकि दूसरा काम से भरा हुआ है।
• यदि कोई ईवेंट हैंडलर स्ट्रीम को ब्लॉक करता है, तो सिस्टम सिलेक्टर खुद भी ब्लॉक हो जाएगा, जिससे हार्ड-टू-कैच बग हो सकते हैं।

इन समस्याओं को I / O प्रॉक्टर द्वारा हल किया जाता है, अक्सर एक अनुसूचक के साथ जो समान रूप से थ्रेड पूल को लोड वितरित करता है, और इसमें एक अधिक सुविधाजनक एपीआई भी है। इसकी चर्चा बाद में मेरे दूसरे लेख में की जाएगी।

निष्कर्ष

इस पर, थ्योरी प्रोफाइलर में सीधे सिद्धांत से हमारी यात्रा समाप्त हो गई।

इस पर ध्यान न दें, क्योंकि नेटवर्क सॉफ़्टवेयर को सुविधा और गति के विभिन्न स्तरों के साथ लिखने के लिए कई अन्य समान रूप से दिलचस्प दृष्टिकोण हैं। दिलचस्प है, मेरी राय में, लिंक नीचे दिए गए हैं।

जल्द मिलते हैं!

दिलचस्प परियोजनाएं

• बी
  
  • libevent
  • libev
  • libuv
  • libevhtp
  • liburing
  • DPDK
  • netmap
  • PF_RING
• रतुआ
  
  • Mio
  • टोकियो
  • smoltcp

और क्या पढ़ना है?

• https://linux.die.net/man/7/socket
• https://stackoverflow.com/questions/1050222/what-is-the-difference-between-concurrency-and-parallelism
• http://www.kegel.com/c10k.html
• https://kernel.dk/io_uring.pdf
• https://aturon.imtqy.com/blog/2016/09/07/futures-design/
• https://tokio.rs/blog/2019-10-scheduler/
• https://www.artima.com/articles/io_design_patterns.html
• https://habr.com/en/post/183832/