“@Cloudflare टीम ने अभी-अभी परिवर्तन किए हैं जिससे हमारे नेटवर्क के प्रदर्शन में काफी सुधार हुआ है, विशेष रूप से सबसे धीमी अनुरोधों के लिए। कितना तेज है? हम अनुमान लगाते हैं कि हम प्रति दिन लगभग 54 वर्षों के लिए इंटरनेट की बचत कर रहे हैं जो अन्यथा साइटों को लोड करने के लिए इंतजार कर रहे हैं । ” - मैथ्यू प्रिंस ट्वीट , 28 जून 2018

10 मिलियन साइट, एप्लिकेशन और एपीआई उपयोगकर्ताओं के लिए सामग्री डाउनलोड को गति देने के लिए क्लाउडफेयर का उपयोग करते हैं। चरम पर, हम 151 डेटा केंद्रों में प्रति सेकंड 10 मिलियन से अधिक अनुरोध संसाधित करते हैं। पिछले कुछ वर्षों में, हमने विकास के साथ सामना करने के लिए Nginx के अपने संस्करण में कई बदलाव किए हैं। यह लेख इन परिवर्तनों में से एक है।

कैसे काम करता है

Nginx उन कार्यक्रमों में से एक है जो C10K समस्या को हल करने के लिए इवेंट प्रोसेसिंग लूप का उपयोग करता है । जब भी कोई नेटवर्क ईवेंट आता है (बड़ी संख्या में डेटा भेजने के लिए एक नया कनेक्शन, अनुरोध या अधिसूचना), नग्नेक्स उठता है, ईवेंट को संसाधित करता है, और फिर दूसरी नौकरी पर लौटता है (यह अन्य ईवेंट को संसाधित कर सकता है)। जब कोई घटना आती है, तो इसके लिए डेटा तैयार है, जो आपको डाउनटाइम के बिना एक साथ कई अनुरोधों को कुशलतापूर्वक संसाधित करने की अनुमति देता है।

num_events = epoll_wait(epfd, /*returned=*/events, events_len, /*timeout=*/-1); // events is list of active events // handle event[0]: incoming request GET http://example.com/ // handle event[1]: send out response to GET http://cloudflare.com/ 

उदाहरण के लिए, यहाँ एक फ़ाइल कोड से डेटा पढ़ने के लिए कोड का एक टुकड़ा कैसा दिख सकता है:

 // we got a read event on fd while (buf_len > 0) { ssize_t n = read(fd, buf, buf_len); if (n < 0) { if (errno == EWOULDBLOCK || errno == EAGAIN) { // try later when we get a read event again } if (errno == EINTR) { continue; } return total; } buf_len -= n; buf += n; total += n; } 

यदि fd एक नेटवर्क सॉकेट है, तो पहले से प्राप्त बाइट्स वापस आ जाएंगे। आखिरी कॉल EWOULDBLOCK । इसका मतलब है कि स्थानीय रीड बफर समाप्त हो गया है और आपको इस सॉकेट से डेटा पढ़ने तक दिखाई नहीं देना चाहिए।

डिस्क I / O नेटवर्क से अलग है

यदि fd लिनक्स पर एक नियमित फ़ाइल है, तो EWOULDBLOCK और EAGAIN कभी नहीं दिखाई देते हैं, और रीड ऑपरेशन हमेशा पूरे बफर को पढ़ने के लिए इंतजार करता है, भले ही फ़ाइल O_NONBLOCK का उपयोग करके खोली O_NONBLOCK । जैसा कि खुले में लिखा गया है (2) मैनुअल:

कृपया ध्यान दें कि यह ध्वज नियमित फ़ाइलों और ब्लॉक उपकरणों के लिए मान्य नहीं है।

दूसरे शब्दों में, उपरोक्त कोड अनिवार्य रूप से इसके लिए कम किया गया है:

 if (read(fd, buf, buf_len) > 0) { return buf_len; } 

यदि हैंडलर को डिस्क से पढ़ने की आवश्यकता है, तो यह इवेंट लूप को तब तक ब्लॉक करता है जब तक रीड पूरा नहीं हो जाता है, और बाद में ईवेंट हैंडलर प्रतीक्षा करते हैं।

यह अधिकांश कार्यों के लिए सामान्य है, क्योंकि डिस्क से पढ़ना आमतौर पर नेटवर्क से एक पैकेट की प्रतीक्षा करने की तुलना में काफी तेज और बहुत अधिक अनुमानित है। विशेष रूप से अब जब सभी के पास एसएसडी है, और हमारे सभी कैश एसएसडी पर हैं। आधुनिक एसएसडी में, बहुत कम देरी, आमतौर पर दसियों माइक्रोसेकंड में। इसके अलावा, आप Nginx को कई वर्कफ़्लोज़ के साथ चला सकते हैं ताकि एक धीमा ईवेंट हैंडलर अन्य प्रक्रियाओं में अनुरोधों को अवरुद्ध न करे। अधिकांश समय आप Nginx पर जल्दी और कुशलतापूर्वक प्रक्रिया अनुरोधों पर भरोसा कर सकते हैं।

एसएसडी प्रदर्शन: हमेशा के रूप में वादा नहीं किया

जैसा कि आपने अनुमान लगाया होगा, ये रसीली धारणाएं हमेशा सच नहीं होती हैं। यदि प्रत्येक रीडिंग में हमेशा 50 μs लगते हैं, तो 4 केबी के ब्लॉक में 0.19 एमबी (और हम बड़े ब्लॉकों में भी पढ़ते हैं) को पढ़ने में 2 एमएस लगेगा। लेकिन परीक्षणों से पता चला कि पहली बाइट के लिए समय कभी-कभी बहुत खराब होता है, खासकर 99 वें और 999 वें प्रतिशत में। दूसरे शब्दों में, प्रत्येक 100 (या 1000) रीडिंग में से सबसे धीमा पढ़ने में अक्सर अधिक समय लगता है।

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

SO_REUSEPORT साथ समान लोड वितरण

प्रति 1000 अनुरोधों पर एक धीमी प्रतिक्रिया से बचना मुश्किल है, लेकिन जो हम वास्तव में नहीं चाहते हैं वह शेष 1000 अनुरोधों को एक दूसरे के लिए रोकना है। वैचारिक रूप से, Nginx समानांतर में कई अनुरोधों को संसाधित करने में सक्षम है, लेकिन यह केवल एक समय में 1 ईवेंट हैंडलर शुरू करता है। इसलिए मैंने एक विशेष मीट्रिक जोड़ी:

 gettimeofday(&start, NULL); num_events = epoll_wait(epfd, /*returned=*/events, events_len, /*timeout=*/-1); // events is list of active events // handle event[0]: incoming request GET http://example.com/ gettimeofday(&event_start_handle, NULL); // handle event[1]: send out response to GET http://cloudflare.com/ timersub(&event_start_handle, &start, &event_loop_blocked); 

99 वाँ प्रतिशतक (p99) event_loop_blocked हमारे TTFB के 50% से अधिक है। दूसरे शब्दों में, अनुरोध की सेवा करते समय आधा समय अन्य अनुरोधों द्वारा घटना प्रसंस्करण चक्र को अवरुद्ध करने का परिणाम है। event_loop_blocked केवल आधे लॉक को मापता है (क्योंकि लंबित कॉल epoll_wait() मापा नहीं जाता है), इसलिए अवरुद्ध समय का वास्तविक अनुपात बहुत अधिक है।

हमारी प्रत्येक मशीन 15 वर्कफ़्लोज़ के साथ नग्नेक्स चलाती है, यानी एक धीमा I / O अनुरोधों के 6% से अधिक को अवरुद्ध नहीं करेगा। लेकिन घटनाओं को समान रूप से वितरित नहीं किया जाता है: मुख्य कार्यकर्ता अनुरोधों का 11% प्राप्त करता है।

SO_REUSEPORT असमान वितरण की समस्या को हल कर सकता है। मारेक मायकोवस्की ने पहले इस दृष्टिकोण को अन्य नग्नेक्स उदाहरणों के संदर्भ में कमियां के बारे में लिखा था, लेकिन यहां आप मुख्य रूप से इसे अनदेखा कर सकते हैं: कैश में अपस्ट्रीम कनेक्शन टिकाऊ होते हैं, इसलिए आप कनेक्शन खोलते समय देरी में थोड़ी वृद्धि की उपेक्षा कर सकते हैं। यह कॉन्फ़िगरेशन SO_REUSEPORT सुधार के साथ अकेले परिवर्तित हो गया है, जिससे p99 33% बेहतर हो गया है।

थ्रेड पूल के लिए पढ़ना () चलना: चांदी की गोली नहीं

समाधान को गैर-अवरुद्ध बनाना है। वास्तव में यह फ़ंक्शन सामान्य नग्नेक्स में लागू किया गया है ! निम्न कॉन्फ़िगरेशन का उपयोग करते हुए, थ्रेड पूल में पढ़ें () और लिखें () निष्पादित होते हैं और ईवेंट लूप को ब्लॉक नहीं करते हैं:

 aio threads; aio_write on; 

लेकिन हमने इस कॉन्फ़िगरेशन का परीक्षण किया और 33 बार प्रतिक्रिया समय में सुधार करने के बजाय, हमने p99 में केवल एक छोटे से बदलाव पर ध्यान दिया, अंतर त्रुटि के मार्जिन के भीतर है। परिणाम बहुत हतोत्साहित करने वाला था, इसलिए हमने अस्थायी रूप से इस विकल्प को स्थगित कर दिया।

ऐसे कई कारण हैं कि हमने Nginx डेवलपर्स की तरह महत्वपूर्ण सुधार नहीं किए हैं। परीक्षण में उन्होंने एचडीडी के लिए 4 एमबी की फ़ाइलों का अनुरोध करने के लिए 200 एक साथ कनेक्शन का उपयोग किया। Winchesters में I / O विलंबता अधिक होती है, इसलिए अनुकूलन का अधिक प्रभाव पड़ता है।

इसके अलावा, हम मुख्य रूप से p99 (और p999) के प्रदर्शन के बारे में चिंतित हैं। औसत देरी का अनुकूलन जरूरी नहीं कि चोटी के उत्सर्जन की समस्या का समाधान हो।

अंत में, हमारे वातावरण में, विशिष्ट फ़ाइल आकार बहुत छोटे हैं। हमारे कैश हिट का 90% 60KB से कम है। फ़ाइलें जितनी छोटी होंगी, अवरुद्ध होने के कम मामले (आमतौर पर हम पूरी फाइल को दो रीड में पढ़ते हैं)।

आइए कैश में हिट होने पर डिस्क I / O देखें:

 //     https://example.com    0xCAFEBEEF fd = open("/cache/prefix/dir/EF/BE/CAFEBEEF", O_RDONLY); //    32    //    ,  "aio threads"  read(fd, buf, 32*1024); 

32K हमेशा पढ़ा नहीं जाता है। यदि हेडर छोटे हैं, तो आपको केवल 4 केबी पढ़ने की जरूरत है (हम सीधे आई / ओ का उपयोग नहीं करते हैं, इसलिए कर्नेल 4 केबी के चक्कर लगाता है)। open() हानिरहित लगता है, लेकिन यह वास्तव में संसाधन लेता है। कम से कम, कर्नेल को जांचना चाहिए कि क्या फ़ाइल मौजूद है और क्या कॉलिंग प्रक्रिया को इसे खोलने की अनुमति है या नहीं। उसे /cache/prefix/dir/EF/BE/CAFEBEEF लिए /cache/prefix/dir/EF/BE/CAFEBEEF , और इसके लिए उसे CAFEBEEF /cache/prefix/dir/EF/BE/ में देखना होगा। संक्षेप में, सबसे बुरे मामले में, कर्नेल इस खोज को करता है:

 /cache /cache/prefix /cache/prefix/dir /cache/prefix/dir/EF /cache/prefix/dir/EF/BE /cache/prefix/dir/EF/BE/CAFEBEEF 

ये 6 अलग-अलग रीड हैं जो 1 read() की तुलना में open() उत्पन्न करते read() ! सौभाग्य से, ज्यादातर मामलों में खोज डेंट्री कैश में गिर जाती है और एसएसडी तक नहीं पहुंचती है। लेकिन यह स्पष्ट है कि एक थ्रेड पूल में read() प्रसंस्करण read() केवल आधी तस्वीर है।

अंतिम राग: थ्रेड पूल में नॉन-ब्लॉकिंग ओपन ()

इसलिए, हमने Nginx में एक बदलाव किया ताकि open() ज्यादातर थ्रेड पूल के अंदर निष्पादित हो और इवेंट लूप को ब्लॉक न करें। और यहाँ एक ही समय में गैर-अवरुद्ध खुला () और पढ़ने () से परिणाम है:



26 जून को, हमने 5 व्यस्ततम डेटा केंद्रों में परिवर्तन किया, और अगले दिन - दुनिया भर के अन्य सभी 146 डेटा केंद्रों पर। कुल शिखर p99 TTFB 6 गुना घट गया। वास्तव में, यदि हम प्रति सेकंड 8 मिलियन अनुरोधों को संसाधित करने से हर समय सारांशित करते हैं, तो हम हर दिन इंटरनेट के 54 वर्षों के इंतजार को बचाते हैं।

घटनाओं की हमारी श्रृंखला को अभी तक पूरी तरह से ताले से छुटकारा नहीं मिला है। विशेष रूप से, ब्लॉकिंग तब भी होती है जब फ़ाइल कैश्ड होती है (दोनों open(O_CREAT) और rename() ) या open(O_CREAT) अपडेट करते समय। लेकिन ऐसे मामले कैश एक्सेस की तुलना में दुर्लभ हैं। भविष्य में, हम इन कारकों को इवेंट प्रोसेसिंग लूप के बाहर ले जाने की संभावना पर विचार करेंगे ताकि विलंब कारक p99 को और बेहतर बनाया जा सके।

निष्कर्ष

Nginx एक शक्तिशाली प्लेटफ़ॉर्म है, लेकिन अत्यधिक उच्च लिनक्स I / O भार को स्केल करना एक कठिन काम हो सकता है। स्टैंडर्ड नग्नेक्स अलग थ्रेड्स में पढ़ना बंद कर देता है, लेकिन हमारे पैमाने पर हमें अक्सर एक कदम आगे जाने की आवश्यकता होती है।