वेब सर्वर की लड़ाई. भाग 2 - यथार्थवादी HTTPS परिदृश्य:

हमने तकनीक के बारे में बात की पहले भाग लेख, इस लेख में हम HTTPS का परीक्षण करते हैं, लेकिन अधिक यथार्थवादी परिदृश्यों में। परीक्षण के लिए, हमने लेट्स एनक्रिप्ट प्रमाणपत्र प्राप्त किया और ब्रॉटली संपीड़न को 11 पर सक्षम किया।

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

• 25% - जो ~ 1350 मेगाहर्ट्ज की आवृत्ति के बराबर है
• 35% -1890 मेगाहर्ट्ज
• 41% - 2214 मेगाहर्ट्ज
• 65% - 3510 मेगाहर्ट्ज

एकमुश्त कनेक्शन की संख्या 500 से घटाकर 1, 3, 5, 7 और 9 कर दी गई है।

परिणाम:

देरी:

टीटीएफबी को विशेष रूप से एक अलग परीक्षण के रूप में शामिल किया गया था, क्योंकि HTTPD टूल्स प्रत्येक व्यक्तिगत अनुरोध के लिए एक नया उपयोगकर्ता बनाता है। यह परीक्षण अभी भी वास्तविकता से काफी अलग है, क्योंकि उपयोगकर्ता अभी भी कुछ पृष्ठों पर क्लिक करेगा, और वास्तव में टीटीएफपी मुख्य भूमिका निभाएगा।

पहला, आम तौर पर आईआईएस वर्चुअल मशीन की पहली शुरुआत के बाद पहला अनुरोध औसतन 120 एमएस लेता है।

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

प्रति ग्राहक बिताया गया समय

प्रदर्शन का मूल्यांकन करने के लिए, 1 एकल कनेक्शन वाला परीक्षण पर्याप्त है।
उदाहरण के लिए, IIS ने 5000 सेकंड में 40 उपयोगकर्ताओं का परीक्षण पूरा किया, जो प्रति सेकंड 123 अनुरोध है।

नीचे दिए गए ग्राफ़ साइट की सामग्री पूरी तरह से स्थानांतरित होने तक का समय दिखाते हैं। यह एक निश्चित समय में पूर्ण किए गए अनुरोधों का अनुपात है। हमारे मामले में, सभी अनुरोधों में से 80% को IIS पर 8ms में और Apache और Nginx पर 4.5ms में संसाधित किया गया था, और Apache और Nginx पर सभी अनुरोधों में से 8% को 98 मिलीसेकंड तक के अंतराल के भीतर पूरा किया गया था।

वह समय जिसके दौरान 5000 अनुरोध संसाधित किए गए:

वह समय जिसके दौरान 5000 अनुरोध संसाधित किए गए:

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

जब थोड़ी अधिक यथार्थवादी स्थिति की बात आती है, तो सभी वेब सर्वर आमने-सामने हो जाते हैं।

प्रवाह क्षमता:

विलंब का ग्राफ़ बनाम एक साथ कनेक्शन की संख्या। चिकना और निचला बेहतर है. अंतिम 2% को चार्ट से हटा दिया गया क्योंकि वे उन्हें अपठनीय बना देंगे।

अब आइए उस विकल्प पर विचार करें जहां सर्वर वर्चुअल होस्टिंग पर होस्ट किया गया है। आइए 4 गीगाहर्ट्ज़ पर 2.2 कोर और 1.8 गीगाहर्ट्ज़ पर एक कोर लें।

स्केल कैसे करें

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

पहले, पूरी चुनौती सभी अनुरोधों के लिए सबसे कम विलंबता के साथ 98% अनुरोधों को संसाधित करने की थी, ताकि वक्र को यथासंभव सपाट रखा जा सके। अब, एक और वक्र का निर्माण करके, हम प्रत्येक सर्वर के लिए इष्टतम ऑपरेटिंग बिंदु पाएंगे।

ऐसा करने के लिए, आइए अनुरोध प्रति सेकंड (RPR) संकेतक लें। क्षैतिज आवृत्ति है, लंबवत प्रति सेकंड संसाधित अनुरोधों की संख्या है, रेखाएं कोर की संख्या हैं।

यह सहसंबंध दिखाता है कि Nginx एक के बाद एक अनुरोधों को कितनी अच्छी तरह संसाधित करता है। इस परीक्षण में 8 कोर बेहतर प्रदर्शन करते हैं।

यह ग्राफ स्पष्ट रूप से दिखाता है कि Nginx एक कोर पर कितना बेहतर (ज्यादा नहीं) काम करता है। यदि आपके पास Nginx है, तो आपको केवल स्थिर कोर की मेजबानी करते समय कोर की संख्या को घटाकर एक करने पर विचार करना चाहिए।

IIS, हालांकि Chrome में DevTools के अनुसार इसका TTFB सबसे कम है, Apache फाउंडेशन के तनाव परीक्षण के साथ एक गंभीर लड़ाई में Nginx और Apache दोनों से हारने का प्रबंधन करता है।

ग्राफ़ की सभी वक्रताएं लोहे से ढकी हुई पुन: प्रस्तुत की गई हैं।

किसी प्रकार का निष्कर्ष:

हां, अपाचे 1 और 8 कोर पर खराब काम करता है, लेकिन 4 पर थोड़ा बेहतर काम करता है।

हां, 8 कोर प्रक्रियाओं पर Nginx 1 और 4 कोर पर एक के बाद एक बेहतर अनुरोध करता है, और कई कनेक्शन होने पर बदतर काम करता है।

हाँ, IIS मल्टी-थ्रेडेड वर्कलोड के लिए 4 कोर को प्राथमिकता देता है और सिंगल-थ्रेडेड वर्कलोड के लिए 8 कोर को प्राथमिकता देता है। अंततः, उच्च लोड के तहत 8 कोर पर IIS बाकी सभी की तुलना में थोड़ा तेज़ था, हालाँकि सभी सर्वर बराबर थे।

यह कोई माप त्रुटि नहीं है, यहां त्रुटि +-1ms से अधिक नहीं है। देरी में और आरपीआर के लिए प्रति सेकंड +- 2-3 अनुरोध से अधिक नहीं।

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

स्रोत: www.habr.com