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

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

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

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

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

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

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

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

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

जीरोएचटीटीपीडी होम पेज। यह छवियों सहित विभिन्न फ़ाइल प्रकारों को आउटपुट कर सकता है

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

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

वेब एप्लिकेशन "अतिथि पुस्तक" ZeroHTTPd

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

निम्न चित्र दिखाता है कि क्लाइंट (ब्राउज़र) के अनुरोध करने पर एप्लिकेशन क्या करता है /guestbookURL.

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

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

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

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

चलने का
फोर्क सर्वर (प्रति अनुरोध एक चाइल्ड प्रक्रिया)
प्री-फोर्किंग सर्वर (प्रक्रियाओं का प्री-फोर्किंग)
निष्पादन थ्रेड वाला सर्वर (प्रति अनुरोध एक थ्रेड)
प्री-थ्रेड निर्माण वाला सर्वर
वास्तुकला आधारित poll()
वास्तुकला आधारित epoll

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

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

ZeroHTTPd लोड परीक्षण सेटअप

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

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

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

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

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

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

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

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

नीचे परिणामों वाली एक तालिका है.

प्रति सेकंड अनुरोध

समानता
चलने का
काँटा
पूर्व कांटा
स्ट्रीमिंग
प्री-स्ट्रीमिंग
अंदर
एपोल

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

10 000
-
-
बड़ा प्रसार
-
2200
-
2200

11 000
-
-
-
-
2200
-
2122

12 000
-
-
-
-
970
-
1958

13 000
-
-
-
-
730
-
1897

14 000
-
-
-
-
590
-
1466

15 000
-
-
-
-
532
-
1281

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

ZeroHTTPd स्रोत कोड

ZeroHTTPd स्रोत कोड यहां. प्रत्येक आर्किटेक्चर के लिए एक अलग निर्देशिका है।

ZeroHTTPd │ ├── 01_पुनरावृत्त │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking │ ├── main.c ├── 04 _ थ्रेडिंग │ ├── main.c ├── 05_प्रीथ्रेडिंग │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └── main.c ├── मेकफ़ाइल ├── सार्वजनिक │ ├ ── अनुक्रमणिका .html │ └── टक्स . पीएनजी └── टेम्पलेट्स └── गेस्टबुक └── 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 द्वारा सीमित होते हैं, और प्रोसेसर का पूरी क्षमता पर शायद ही कभी उपयोग किया जाता है। जब आप देखते हैं कि कोई I/O कार्य बहुत अधिक CPU का उपयोग कर रहा है, तो यह संभवतः खराब एप्लिकेशन आर्किटेक्चर का संकेत है। इसका मतलब यह हो सकता है कि सीपीयू संसाधन प्रक्रिया प्रबंधन और संदर्भ स्विचिंग पर बर्बाद हो जाते हैं - और यह पूरी तरह से उपयोगी नहीं है। यदि आप इमेज प्रोसेसिंग, ऑडियो फ़ाइल रूपांतरण, या मशीन लर्निंग जैसा कुछ कर रहे हैं, तो एप्लिकेशन को शक्तिशाली सीपीयू संसाधनों की आवश्यकता होती है। लेकिन अधिकांश अनुप्रयोगों के लिए यह मामला नहीं है।

सर्वर आर्किटेक्चर के बारे में और जानें

स्रोत: www.habr.com

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