वेब एप्लिकेशन अब व्यापक रूप से उपयोग किए जाते हैं, और HTTP सभी परिवहन प्रोटोकॉल का शेर हिस्सा है। वेब अनुप्रयोगों के विकास की बारीकियों का अध्ययन करते हुए, उनमें से अधिकांश ऑपरेटिंग सिस्टम पर बहुत कम ध्यान देते हैं जहां ये अनुप्रयोग वास्तव में चलते हैं। विकास (देव) और ऑपरेशन (ऑप्स) के अलगाव ने ही मामलों को और बदतर बना दिया। लेकिन देवओप्स संस्कृति के प्रसार के साथ, डेवलपर्स क्लाउड में अपने एप्लिकेशन लॉन्च करने की जिम्मेदारी लेना शुरू करते हैं, इसलिए ऑपरेटिंग सिस्टम बैकएंड के साथ अच्छी तरह से परिचित होना उनके लिए बहुत उपयोगी है। यह विशेष रूप से उपयोगी है यदि आप हजारों समवर्ती कनेक्शनों के हजारों या दसियों के लिए एक सिस्टम को तैनात करने की कोशिश कर रहे हैं।

वेब सेवाओं में सीमाएं अन्य अनुप्रयोगों में सीमाओं के समान हैं। चाहे वह बैलेंसर या डेटाबेस सर्वर लोड हो, इन सभी अनुप्रयोगों में उच्च-प्रदर्शन वाले वातावरण में समान समस्याएं हैं। इन मूलभूत सीमाओं को समझना और उन्हें सामान्य रूप से कैसे दूर किया जाए इससे आपको अपने वेब अनुप्रयोगों के प्रदर्शन और मापनीयता का मूल्यांकन करने में मदद मिलेगी।

मैं उन युवा डेवलपर्स के सवालों के जवाब में लेखों की इस श्रृंखला को लिख रहा हूं जो अच्छी तरह से सूचित सिस्टम आर्किटेक्ट बनना चाहते हैं। ऑपरेटिंग सिस्टम स्तर पर वे कैसे काम करते हैं, इसके मूल में गोताखोरी के बिना लिनक्स अनुप्रयोगों के अनुकूलन के तरीकों को स्पष्ट रूप से समझना असंभव है। यद्यपि कई प्रकार के अनुप्रयोग हैं, इस श्रृंखला में मैं नेटवर्क अनुप्रयोगों का पता लगाना चाहता हूं, न कि डेस्कटॉप जैसे कि ब्राउज़र या पाठ संपादक। यह सामग्री उन डेवलपर्स और वास्तुकारों के लिए है जो यह समझना चाहते हैं कि लिनक्स या यूनिक्स कार्यक्रम कैसे काम करते हैं और उच्च प्रदर्शन के लिए उन्हें कैसे तैयार किया जाता है।

लिनक्स एक सर्वर ऑपरेटिंग सिस्टम है, और अक्सर आपके अनुप्रयोग इस विशेष OS पर चलते हैं। यद्यपि मैं कहता हूं कि "लिनक्स", ज्यादातर समय आप सुरक्षित रूप से मान सकते हैं कि सामान्य रूप से सभी यूनिक्स जैसे ऑपरेटिंग सिस्टम हैं। हालाँकि, मैंने अन्य प्रणालियों पर साथ वाले कोड का परीक्षण नहीं किया है। इसलिए, यदि आप FreeBSD या OpenBSD में रुचि रखते हैं, तो परिणाम भिन्न हो सकते हैं। जब मैं कुछ लिनक्स-विशिष्ट कोशिश करता हूं, तो मैं इसे इंगित करता हूं।

यद्यपि आप इस ज्ञान का उपयोग खरोंच से एक एप्लिकेशन बनाने के लिए कर सकते हैं, और यह पूरी तरह से अनुकूलित किया जाएगा, यह बेहतर नहीं है। यदि आप अपने संगठन के व्यावसायिक अनुप्रयोग के लिए C या C ++ में एक नया वेब सर्वर लिखते हैं, तो यह आपके काम का अंतिम दिन हो सकता है। हालांकि, इन अनुप्रयोगों की संरचना का ज्ञान मौजूदा कार्यक्रमों के चयन में मदद करेगा। आप थ्रेड-आधारित और इवेंट-आधारित सिस्टम के साथ प्रक्रिया-आधारित सिस्टम की तुलना कर सकते हैं। आप समझेंगे और सराहना करेंगे कि नग्नेक्स अपाचे httpd से बेहतर क्यों काम करता है, क्यों एक टोरनेडो-आधारित पायथन एप्लिकेशन एक Django- आधारित पायथन एप्लिकेशन की तुलना में अधिक उपयोगकर्ताओं की सेवा कर सकता है।

ZeroHTTPd: लर्निंग टूल

ZeroHTTPd एक वेब सर्वर है जिसे मैंने C से एक प्रशिक्षण उपकरण के रूप में लिखा है। इसमें कोई बाहरी निर्भरता नहीं है, जिसमें रेडिस तक पहुंच शामिल है। हम अपना Redis रूटीन चलाते हैं। अधिक जानकारी के लिए नीचे देखें।

यद्यपि हम लंबे समय तक सिद्धांत पर चर्चा कर सकते थे, लेकिन कोड लिखना, इसे चलाना और सभी सर्वर आर्किटेक्चर की एक साथ तुलना करने से बेहतर कुछ नहीं है। यह सबसे स्पष्ट विधि है। इसलिए, हम प्रत्येक मॉडल का उपयोग करते हुए एक सरल ज़ीरो टीटीपी वेब सर्वर लिखेंगे: प्रक्रियाओं, थ्रेड्स और घटनाओं के आधार पर। आइए इनमें से प्रत्येक सर्वर की जांच करें और देखें कि वे एक-दूसरे की तुलना में कैसे काम करते हैं। ZeroHTTPd को एकल C फ़ाइल में लागू किया गया है। ईवेंट-आधारित सर्वर में uthash , एक उत्कृष्ट हैश तालिका कार्यान्वयन शामिल है जो एकल शीर्ष लेख फ़ाइल में जहाज करता है। अन्य मामलों में, कोई निर्भरता नहीं है, इसलिए परियोजना को जटिल नहीं करना है।

इसे छांटने में मदद करने के लिए कोड में बहुत सारी टिप्पणियाँ हैं। कोड की कुछ लाइनों में एक साधारण वेब सर्वर होने के नाते, ZeroHTTPd भी एक न्यूनतम वेब डेवलपमेंट फ्रेमवर्क है। इसकी सीमित कार्यक्षमता है, लेकिन यह स्थिर फ़ाइलों और बहुत ही सरल "गतिशील" पृष्ठों का उत्पादन करने में सक्षम है। मुझे कहना होगा कि ZeroHTTPd उच्च-प्रदर्शन लिनक्स अनुप्रयोग बनाने के तरीके सीखने के लिए अच्छी तरह से अनुकूल है। द्वारा और बड़ी, अधिकांश वेब सेवाएँ अनुरोधों की प्रतीक्षा करती हैं, उन्हें जाँचती हैं और उन्हें संसाधित करती हैं। यह वास्तव में ZeroHTTPd क्या करेगा। यह एक लर्निंग टूल है, प्रोडक्शन टूल नहीं। वह त्रुटियों को संभालने में अच्छा नहीं है और सर्वोत्तम सुरक्षा प्रथाओं (ओह हाँ, मैंने strcpy उपयोग किया है) या C के घिनौनी चालों पर गर्व करने की संभावना नहीं है। लेकिन मुझे आशा है कि वह अपना काम अच्छी तरह से करता है।

ZeroHTTPd होमपेज। यह छवियों सहित विभिन्न प्रकार की फ़ाइलों का उत्पादन कर सकता है

अतिथि पुस्तक आवेदन

आधुनिक वेब एप्लिकेशन आमतौर पर स्थिर फ़ाइलों तक सीमित नहीं होते हैं। उनके पास विभिन्न डेटाबेस, कैश आदि के साथ जटिल बातचीत है, इसलिए, हम "गेस्टबुक" नामक एक सरल वेब एप्लिकेशन बनाएंगे, जहां आगंतुक अपने नामों के तहत प्रविष्टियां छोड़ते हैं। गेस्टबुक पहले बची हुई प्रविष्टियों को सहेजती है। पृष्ठ के नीचे एक आगंतुक काउंटर भी है।

अतिथि पुस्तक वेब अनुप्रयोग ZeroHTTPd

आगंतुक काउंटर और अतिथि पुस्तक प्रविष्टियां रेडिस में संग्रहीत की जाती हैं। रेडिस के साथ संचार के लिए, खुद की प्रक्रियाएं लागू की जाती हैं, वे एक बाहरी पुस्तकालय से स्वतंत्र हैं। जब सार्वजनिक रूप से उपलब्ध और अच्छी तरह से परीक्षण किए गए समाधान होते हैं तो मैं घर में रहने वाले कोड को रोल करने का बड़ा प्रशंसक नहीं हूं। लेकिन ZeroHTTPd का लक्ष्य लिनक्स प्रदर्शन और बाहरी सेवाओं तक पहुंच का अध्ययन करना है, जबकि HTTP अनुरोधों की सेवा प्रदर्शन को गंभीरता से प्रभावित करती है। हमें अपने प्रत्येक सर्वर आर्किटेक्चर में रेडिस के साथ संचार को पूरी तरह से नियंत्रित करना चाहिए। एक आर्किटेक्चर में, हम ब्लॉकिंग कॉल का उपयोग करते हैं, अन्य में हम इवेंट-आधारित प्रक्रियाओं का उपयोग करते हैं। बाहरी Redis क्लाइंट लाइब्रेरी का उपयोग इस तरह के नियंत्रण को नहीं देगा। इसके अलावा, हमारा छोटा रेडिस क्लाइंट केवल कुछ कार्य करता है (एक कुंजी प्राप्त करना, स्थापित करना और बढ़ाना; एक सरणी में प्राप्त करना और जोड़ना)। इसके अलावा, रेडिस प्रोटोकॉल असाधारण रूप से सुरुचिपूर्ण और सरल है। उसे विशेष रूप से पढ़ाने की भी आवश्यकता नहीं है। तथ्य यह है कि प्रोटोकॉल कोड की लगभग सौ लाइनों में सभी काम करता है, यह बताता है कि यह कितना अच्छा है।

क्लाइंट (ब्राउज़र) अनुरोधों /guestbookURL बाद निम्न आंकड़ा आवेदन दिखाता है।

गेस्टबुक एप्लिकेशन का तंत्र

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

ZeroHTTPd सर्वर आर्किटेक्चर

हम एक ही कार्यक्षमता के साथ ZeroHTTPd के सात संस्करणों का निर्माण कर रहे हैं, लेकिन विभिन्न आर्किटेक्चर:

चलने का
कांटा सर्वर (अनुरोध के अनुसार एक बच्चा प्रक्रिया)
प्री-फोर्क सर्वर (प्री-फोर्किंग प्रोसेस)
सर्वर थ्रेड्स (अनुरोध के अनुसार एक धागा)
पूर्व थ्रेडिंग के साथ सर्वर
poll() आधारित वास्तुकला
एपोल वास्तुकला

हम HTTP अनुरोधों के साथ सर्वर को लोड करके प्रत्येक आर्किटेक्चर के प्रदर्शन को मापते हैं। लेकिन जब उच्च स्तर की समानता के साथ आर्किटेक्चर की तुलना करते हैं, तो अनुरोधों की संख्या बढ़ जाती है। हम तीन बार परीक्षण करते हैं और औसत पर विचार करते हैं।

परीक्षण पद्धति

तनाव परीक्षण के लिए स्थापना ZeroHTTPd

यह महत्वपूर्ण है कि परीक्षण करते समय सभी घटक एक ही मशीन पर काम न करें। इस मामले में, ओएस अतिरिक्त नियोजन उपरि वहन करता है, क्योंकि घटक सीपीयू के लिए प्रतिस्पर्धा करते हैं। चयनित सर्वर आर्किटेक्चर में से प्रत्येक से ऑपरेटिंग सिस्टम ओवरहेड को मापना इस अभ्यास के सबसे महत्वपूर्ण लक्ष्यों में से एक है। अधिक चर जोड़ना प्रक्रिया के लिए हानिकारक होगा। इसलिए, ऊपर की आकृति में सेटिंग सबसे अच्छा काम करती है।

इनमें से प्रत्येक सर्वर क्या करता है

load.unixism.net: यहां हम ab , Apache बेंचमार्क यूटिलिटी चलाते हैं। यह हमारे सर्वर आर्किटेक्चर का परीक्षण करने के लिए आवश्यक लोड उत्पन्न करता है।
nginx.unixism.net: कभी-कभी हम सर्वर प्रोग्राम के एक से अधिक उदाहरण चलाना चाहते हैं। इसके लिए, उपयुक्त सेटिंग्स वाला नग्नेक्स सर्वर हमारे सर्वर प्रक्रियाओं के लिए ab से आने वाले लोड बैलेंसर के रूप में काम करता है।
zerohttpd.unixism.net: यहां हम सात अलग-अलग आर्किटेक्चर पर अपना सर्वर प्रोग्राम चलाते हैं, एक बार में।
redis.unixism.net: इस सर्वर पर रेडिस डेमॉन चल रहा है, जहाँ अतिथिबुक में प्रविष्टियाँ संग्रहीत हैं और आगंतुक काउंटर हैं।

सभी सर्वर एकल प्रोसेसर कोर पर चलते हैं। विचार प्रत्येक वास्तुकला के अधिकतम प्रदर्शन का मूल्यांकन करना है। चूंकि सभी सर्वर प्रोग्राम एक ही हार्डवेयर पर टेस्ट किए जाते हैं, इसलिए उनकी तुलना करने के लिए यह मूल स्तर है। मेरे परीक्षण सेटअप में डिजिटल महासागर से किराए पर वर्चुअल सर्वर हैं।

हम क्या माप रहे हैं?

आप विभिन्न संकेतकों को माप सकते हैं। हम इस कॉन्फ़िगरेशन में प्रत्येक आर्किटेक्चर के प्रदर्शन का मूल्यांकन करते हैं, विभिन्न स्तरों पर अनुरोधों के साथ सर्वर लोड करते हैं: लोड 20 से 15,000 समवर्ती उपयोगकर्ताओं तक बढ़ता है।

परीक्षण के परिणाम

निम्न आरेख विभिन्न आर्किटेक्चर पर सर्वरों के प्रदर्शन को विभिन्न स्तरों के विभिन्न स्तरों पर दिखाता है। Y- अक्ष प्रति सेकंड अनुरोधों की संख्या है, x- अक्ष समानांतर कनेक्शन है।

नीचे परिणामों के साथ एक तालिका है।

	प्रति सेकंड अनुरोध
समानता	चलने का	कांटा	पूर्व का कांटा	स्ट्रीम किया	पूर्व स्ट्रीमिंग	मतदान	epoll
20	7	112	2100	1800	2250	1900	2050
50	7	190	2200	1700	2200	2000	2000
100	7	245	2200	1700	2200	2150	2100
200	7	330	2300	1750	2300	2200	2100
300	-	380	2200	1800	2400	2250	2150
400	-	410	2200	1750	2600	2000	2000
500	-	440	2300	1850	2700	1900	2212
600	-	460	2400	1800	2500	1700	2519
700	-	460	2400	1600	2490	1550	2607
800	-	460	2400	1600	2540	1400	2553
900	-	460	2300	1600	2472	1200	2567
1000	-	475	2300	1700	2485	1150	2439
1500	-	490	2400	1550	2620	900	2479
2000	-	350	2400	1400	2396	550	2200
2500	-	280	2100	1300	2453	490	2262
3000	-	280	1900	1250	2502	व्यापक प्रसार	2138
5000	-	व्यापक प्रसार	1600	1100	2519	-	2235
8000	-	-	1200	व्यापक प्रसार	2451	-	2100
10000	-	-	व्यापक प्रसार	-	2200	-	2200
11000	-	-	-	-	2200	-	2122
12000	-	-	-	-	970	-	1958
13000	-	-	-	-	730	-	1897
14000	-	-	-	-	590	-	1466
15000	-	-	-	-	532	-	1281

यह ग्राफ और टेबल से देखा जा सकता है कि 8000 एक साथ अनुरोधों के ऊपर, हमारे पास केवल दो खिलाड़ी बचे हैं: प्री-फोर्क और एपोल। जैसे ही लोड बढ़ता है, पोल-आधारित सर्वर स्ट्रीमिंग की तुलना में खराब प्रदर्शन करता है। प्री-थ्रेडिंग आर्किटेक्चर एपोल के साथ प्रतिस्पर्धा करता है: यह इस बात का सबूत है कि लिनक्स कर्नेल कितनी बड़ी संख्या में थ्रेड की योजना बनाता है।

स्रोत कोड ZeroHTTPd

ZeroHTTPd के लिए स्रोत कोड यहाँ है । प्रत्येक वास्तुकला की एक अलग निर्देशिका है।

  ZeroHTTPd
 │
 Ative 01_कारात्मक
 .C ├── main.c
 Ork 02_forking
 .C ├── main.c
 F 03_preforking
 .C ├── main.c
 Reading 04_थ्रेडिंग
 .C ├── main.c
 Th 05_प्रणाली
 .C ├── main.c
 Oll 06_poll
 .C ├── main.c
 Oll 07_epoll
 .C └── main.c
 Ile मेकफाइल
 ├── जनता
 .Html .html index.html
 Ux └── tux.png
 └── टेम्प्लेट
     └── अतिथि पुस्तिका
         └── index.html

सभी आर्किटेक्चर के लिए सात निर्देशिकाओं के अलावा, शीर्ष-स्तरीय निर्देशिका में दो और हैं: सार्वजनिक और टेम्पलेट। पहले वाले में index.html फ़ाइल और पहले स्क्रीनशॉट से छवि शामिल है। अन्य फ़ाइलों और फ़ोल्डरों को वहां रखा जा सकता है, और ZeroHTTPd को समस्याओं के बिना इन स्थिर फ़ाइलों को जारी करना चाहिए। यदि ब्राउज़र में पथ सार्वजनिक फ़ोल्डर में पथ से मेल खाता है, तो ZeroHTTPd इस निर्देशिका में index.html फ़ाइल की तलाश करता है। गेस्टबुक सामग्री गतिशील रूप से उत्पन्न होती है। इसमें केवल मुख्य पृष्ठ है, और इसकी सामग्री फ़ाइल 'टेम्प्लेट / गेस्टबुक / इंडेक्स। Html' पर आधारित है। ZeroHTTPd आसानी से विस्तार के लिए गतिशील पृष्ठ जोड़ता है। विचार यह है कि उपयोगकर्ता इस निर्देशिका में टेम्पलेट जोड़ सकते हैं और आवश्यकतानुसार ZeroHTTPd का विस्तार कर सकते हैं।

सभी सात सर्वरों को बनाने के लिए, make all को शीर्ष-स्तरीय निर्देशिका से चलाएं - और सभी बिल्ड इस निर्देशिका में दिखाई देंगे। निष्पादनयोग्य उस निर्देशिका में सार्वजनिक और टेम्प्लेट निर्देशिकाओं के लिए खोजते हैं जहाँ से वे चलते हैं।

लिनक्स एपीआई

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

प्रदर्शन और मापनीयता

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

सीपीयू और आई / ओ टास्क

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

लिनक्स नेटवर्क अनुप्रयोग प्रदर्शन। परिचय