हमने लेख के
पहले भाग में तकनीक के बारे में बात की, इसमें हम HTTPS का परीक्षण करते हैं, लेकिन अधिक यथार्थवादी परिदृश्यों में। परीक्षण के लिए, लेट्स एनक्रिप्ट का प्रमाण पत्र प्राप्त किया गया था, 11 द्वारा ब्रेटली संपीड़न को सक्षम किया गया था।
इस बार हम वीडीएस पर या एक विशिष्ट प्रोसेसर के साथ एक मेजबान पर वर्चुअल मशीन के रूप में सर्वर परिनियोजन परिदृश्य को पुन: पेश करने का प्रयास करेंगे। ऐसा करने के लिए, सीमा निर्धारित करें:
- 25% - आवृत्ति के संदर्भ में ~ 1350 मेगाहर्ट्ज
- 35% -1890 मेगाहर्ट्ज
- 41% - 2214 मेगाहर्ट्ज
- 65% - 3510 मेगाहर्ट्ज
एक बार के कनेक्शनों की संख्या 500 से घटकर 1, 3, 5, 7 और 9 हो गई।
परिणाम:
देरी:
TTFB को विशेष रूप से एक अलग परीक्षण के रूप में बनाया गया था, क्योंकि HTTPD टूल्स प्रत्येक व्यक्ति के अनुरोध के लिए एक नया उपयोगकर्ता बनाता है। यह परीक्षण वास्तविकता से अभी भी काफी तलाकशुदा है, क्योंकि उपयोगकर्ता वैसे भी कुछ पृष्ठों पर क्लिक करता है, और वास्तव में TTFP मुख्य भूमिका निभाएगा।
वर्चुअल मशीन की पहली शुरुआत के बाद, आमतौर पर बहुत पहले अनुरोध, आईआईएस औसतन 120 एमएस की प्रक्रिया करता है।
बाद के सभी अनुरोध टीटीएफ को 1.5 एमएस दर्शाते हैं। अपाचे और नेग्नेक्स पिछड़ रहे हैं। व्यक्तिगत रूप से, लेखक इस परीक्षण को सबसे अधिक खुलासा मानता है और इस पर केवल एक विजेता का चयन करेगा।
परिणाम आश्चर्यजनक नहीं है, क्योंकि IIS कैश पहले से ही स्थिर सामग्री को संकुचित करता है और हर बार इसे एक्सेस करने पर चुटकी नहीं लेता है।
एक ग्राहक पर समय बिताया
प्रदर्शन का मूल्यांकन करने के लिए, 1 एक-बार कनेक्शन के साथ एक परीक्षण पर्याप्त है।
उदाहरण के लिए, IIS ने 40 सेकंड में 5,000 उपयोगकर्ताओं की लंबाई के साथ परीक्षण पूरा किया, जो प्रति सेकंड 123 अनुरोध है।
नीचे दिए गए रेखांकन साइट सामग्री के पूर्ण हस्तांतरण तक समय दिखाते हैं। यह एक विशिष्ट समय पर पूरा किए गए अनुरोधों का प्रतिशत है। हमारे मामले में, सभी अनुरोधों का 80% IIS में 8ms में और अपाचे और Nginx पर 4.5ms में संसाधित किया गया था, और Apache और Nginx पर सभी अनुरोधों का 98% 8 मिलीसेकंड के अंतराल के भीतर निष्पादित किया गया था।
5000 अनुरोधों के संसाधित होने में लगने वाला समय:
5000 अनुरोधों के संसाधित होने में लगने वाला समय:
यदि आपके पास 3.5 गीगाहर्ट्ज़ सीपीयू और 8 कोर के साथ एक वर्चुअल मशीन है, तो आप जो चाहते हैं उसे चुनें। इस परीक्षण में सभी वेब सर्वर बहुत समान हैं। हम नीचे प्रत्येक होस्ट के लिए किस वेब सर्वर के बारे में बात करेंगे।
जब यह थोड़ी अधिक वास्तविक स्थिति की बात आती है, तो सभी वेब सर्वर आमने-सामने हो जाते हैं।
प्रवाह क्षमता:
एक साथ कनेक्शन की संख्या पर देरी की अनुसूची। चिकनी और कम बेहतर है। अंतिम 2% को ग्राफ़ से बाहर निकाल दिया गया क्योंकि वे उन्हें अपठनीय बना देंगे।
अब उस विकल्प पर विचार करें जहां सर्वर को एक साझा होस्टिंग पर होस्ट किया गया है। 2.2 GHz पर 4 कोर और 1.8 GHz पर एक कोर लें।
कैसे पैमाना है
यदि आपने कभी यह देखा है कि इलेक्ट्रो-वैक्यूम ट्रायड, पेंटोड्स आदि की I - V विशेषताएँ कैसी दिखती हैं, तो ये ग्राफ आपको परिचित होंगे। यही हम पकड़ने की कोशिश कर रहे हैं - तृप्ति। सीमा यह है, जब आप कितने कोर फेंकते हैं, उत्पादकता वृद्धि ध्यान देने योग्य नहीं होगी।
पहले, पूरी चुनौती 98% अनुरोधों को सभी अनुरोधों पर कम से कम देरी के साथ संसाधित करने की थी, ताकि वक्र को जितना संभव हो सके रखा जा सके। अब, एक और वक्र के निर्माण का उपयोग करके, हम प्रत्येक सर्वर के लिए इष्टतम ऑपरेटिंग बिंदु पाते हैं।
ऐसा करने के लिए, अनुरोध प्रति सेकंड (RPR) मीट्रिक लें। क्षैतिज आवृत्ति, ऊर्ध्वाधर - प्रति सेकंड संसाधित किए गए अनुरोधों की संख्या, लाइनें - कोर की संख्या।
एक सहसंबंध दिखाया गया है कि नग्नेक्स एक के बाद एक अनुरोधों को कितनी अच्छी तरह से संभालता है। इस तरह के परीक्षण में 8 कोर खुद को बेहतर दिखाते हैं।
यह ग्राफ स्पष्ट रूप से दिखाता है कि नगीनक्स एक कोर पर कितना बेहतर (बहुत ज्यादा नहीं) चलता है। यदि आपके पास नगनेक्स है, तो आपको केवल एक स्टैटिक्स की मेजबानी करने पर कोर की संख्या को कम करने पर विचार करना चाहिए।
IIS, हालांकि क्रोम में DevTools के अनुसार इसका सबसे कम TTFB है, Apache Foundation की ओर से तनाव परीक्षण के खिलाफ गंभीर लड़ाई में Nginx और Apache दोनों को खोने का प्रबंधन करता है।
रेखांकन की पूरी वक्रता ट्रेन द्वारा पुन: प्रस्तुत की जाती है।
एक प्रकार का निष्कर्ष:
हां, अपाचे कर्नेल 1 और 8 पर बदतर काम करता है, और 4 पर यह थोड़ा बेहतर काम करता है।
हां, 8 कोर पर नग्नेक्स 1 और 4 कोर पर एक के बाद एक बेहतर अनुरोधों को संभालता है, और कई कनेक्शन होने पर बदतर काम करता है।
हां, IIS बहु-थ्रेडेड लोड के लिए 4 कोर पसंद करता है और सिंगल-थ्रेडेड के लिए 8 कोर पसंद करता है। अंत में, IIS उच्च भार के तहत 8 कोर पर सभी की तुलना में थोड़ा तेज था, हालांकि सभी सर्वर फ्लश चले गए।
यह माप त्रुटि नहीं है, यहाँ त्रुटि + -1ms से अधिक नहीं है। देरी और आरपीआर के लिए प्रति सेकंड 2-3 अनुरोधों से अधिक नहीं।
परिणाम, जब 8 कोर बदतर होते हैं, तो सभी आश्चर्यचकित नहीं होते हैं, कई कोर और एसएमटी / हाइपरथ्रेडिंग गंभीर रूप से नीचा प्रदर्शन करते हैं यदि हमारे पास समय सीमा है जिसके लिए हमें पूरी पाइपलाइन को पूरा करना होगा।
हम स्थापित विंडोज सर्वर 2019 कोर के साथ 99 रूबल के लिए एक अद्यतन अल्ट्रालाइट
विंडोज वीडीएस टैरिफ प्रदान करते हैं।
