WEB सर्भरहरूको युद्ध। भाग २ - यथार्थवादी HTTPS परिदृश्य:

हामीले प्रविधिको बारेमा कुरा गरेका थियौं पहिलो भाग लेख, यो एक मा हामी HTTPS परीक्षण गर्छौं, तर अधिक यथार्थवादी परिदृश्यहरूमा। परीक्षणको लागि, हामीले एउटा Let's Encrypt प्रमाणपत्र प्राप्त गर्यौं र Brotli कम्प्रेसनलाई 11 मा सक्षम पार्यौं।

यस पटक हामी VDS मा सर्भर डिप्लोइ गर्ने वा मानक प्रोसेसर भएको होस्टमा भर्चुअल मेसिनको रूपमा पुन: उत्पादन गर्ने प्रयास गर्नेछौं। यस उद्देश्यको लागि, एक सीमा सेट गरिएको थियो:

• 25% - जुन ~ 1350 MHz को आवृत्ति बराबर छ
• 35% -1890MHz
• ४१% - २२१४ मेगाहर्ट्ज
• ४१% - २२१४ मेगाहर्ट्ज

एक पटकको जडानको संख्या ५०० बाट घटाएर १, ३, ५, ७ र ९ ,

परिणामहरु:

ढिलाइ:

TTFB लाई विशेष रूपमा छुट्टै परीक्षणको रूपमा समावेश गरिएको थियो, किनभने HTTPD उपकरणहरूले प्रत्येक व्यक्तिगत अनुरोधको लागि नयाँ प्रयोगकर्ता सिर्जना गर्दछ। यो परीक्षण अझै पनि वास्तविकताबाट धेरै पृथक छ, किनभने प्रयोगकर्ताले अझै पनि पृष्ठहरूको एक जोडी क्लिक गर्नेछ, र वास्तविकतामा TTFP ले मुख्य भूमिका खेल्नेछ।

पहिलो, सामान्यतया IIS भर्चुअल मेसिनको पहिलो सुरुवात पछिको पहिलो अनुरोधले औसत 120 ms लिन्छ।

सबै पछिका अनुरोधहरूले 1.5 ms को TTFP देखाउँछन्। Apache र Nginx यस सन्दर्भमा पछाडि छन्। व्यक्तिगत रूपमा, लेखकले यो परीक्षणलाई सबैभन्दा खुलासा मान्छन् र यसको आधारमा मात्र विजेता छनौट गर्नेछन्।
नतिजा अचम्मलाग्दो छैन किनकि IIS क्यासले पहिले नै स्थिर सामग्री कम्प्रेस गरेको छ र यसलाई पहुँच गर्दा प्रत्येक पटक कम्प्रेस गर्दैन।

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

कार्यसम्पादन मूल्याङ्कन गर्न, १ एकल जडान भएको परीक्षण पर्याप्त छ।
उदाहरणका लागि, IIS ले 5000 सेकेन्डमा 40 प्रयोगकर्ताहरूको परीक्षण पूरा गर्‍यो, जुन प्रति सेकेन्ड 123 अनुरोधहरू हो।

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

5000 अनुरोधहरू प्रशोधन गरिएको समय:

5000 अनुरोधहरू प्रशोधन गरिएको समय:

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

जब यो अलि बढी यथार्थवादी स्थितिमा आउँछ, सबै वेब सर्भरहरू टाउकोमा जान्छन्।

थ्रुपुट:

एकसाथ जडानहरूको संख्या बनाम ढिलाइको ग्राफ। नरम र तल्लो राम्रो छ। अन्तिम 2% चार्टबाट हटाइयो किनभने तिनीहरूले तिनीहरूलाई अपठनीय बनाउनेछन्।

अब सर्भर भर्चुअल होस्टिङमा होस्ट गरिएको विकल्पलाई विचार गरौं। 4 GHz मा 2.2 कोर र 1.8 GHz मा एक कोर लिनुहोस्।

कसरी मापन गर्ने

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

पहिले, सम्पूर्ण चुनौती सबै अनुरोधहरूको लागि न्यूनतम विलम्बताको साथ 98% अनुरोधहरू प्रशोधन गर्नु थियो, कर्भलाई सकेसम्म समतल राखेर। अब, अर्को कर्भ निर्माण गरेर, हामी प्रत्येक सर्भरको लागि इष्टतम अपरेटिङ बिन्दु फेला पार्नेछौं।

यो गर्नको लागि, प्रति सेकेन्ड अनुरोधहरू (RPR) सूचक लिनुहोस्। तेर्सो फ्रिक्वेन्सी हो, ठाडो भनेको प्रति सेकेन्ड प्रशोधित अनुरोधहरूको संख्या हो, रेखाहरू कोरहरूको संख्या हुन्।

Nginx ले एक पछि अर्को अनुरोधहरू कसरी राम्रोसँग प्रक्रिया गर्दछ भन्ने सम्बन्ध देखाउँदछ। यस परीक्षणमा 8 कोरहरूले राम्रो प्रदर्शन गर्दछ।

यो ग्राफले स्पष्ट रूपमा देखाउँछ कि कति राम्रो (धेरै होइन) Nginx एकल कोरमा काम गर्दछ। यदि तपाइँसँग Nginx छ भने, तपाइँ केवल स्थिर व्यक्तिहरू होस्ट गर्दै हुनुहुन्छ भने, तपाइँ एकमा कोरको संख्या घटाउने विचार गर्नुपर्छ।

IIS, यद्यपि यसमा क्रोममा DevTools अनुसार सबैभन्दा कम TTFB छ, अपाचे फाउन्डेशनबाट तनाव परीक्षणको साथ गम्भीर लडाईमा Nginx र Apache दुवैलाई हराउन प्रबन्ध गर्दछ।

ग्राफको सबै वक्रता फलामले ढाकिएको पुन: उत्पादन गरिन्छ।

केही प्रकारको निष्कर्ष:

हो, Apache 1 र 8 core मा नराम्रो काम गर्दछ, तर 4 मा अलि राम्रो काम गर्दछ।

हो, 8 कोरहरूमा Nginx ले 1 र 4 कोरहरूमा एकपछि अर्को राम्रो अनुरोध गर्दछ, र धेरै जडानहरू हुँदा खराब काम गर्दछ।

हो, IIS ले बहु-थ्रेडेड वर्कलोडका लागि ४ कोर र एकल-थ्रेडेड वर्कलोडका लागि ८ कोर मनपर्छ। अन्ततः, IIS उच्च लोड अन्तर्गत 4 कोरहरूमा अरू सबै भन्दा थोरै छिटो थियो, यद्यपि सबै सर्भरहरू बराबर थिए।

यो मापन त्रुटि होइन, यहाँ त्रुटि +-1ms भन्दा बढी छैन। ढिलाइमा र RPR को लागि प्रति सेकेन्ड +- 2-3 अनुरोधहरू भन्दा बढी।

नतिजाहरू जहाँ 8 कोरहरू खराब प्रदर्शन गर्छन् कुनै पनि अचम्मको कुरा होइन, धेरै कोरहरू र SMT/हाइपरथ्रेडिङले कार्यसम्पादनलाई धेरै ह्रास गर्छ यदि हामीसँग समय सीमा छ जसमा हामीले सम्पूर्ण पाइपलाइन पूरा गर्नुपर्छ।

स्रोत: www.habr.com