WEB सर्भरहरूको युद्ध। भाग 1 - HTTP सम्पर्क बाहिर:

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

यो परीक्षण भ्याकुममा गोलाकार घोडाको मापन हो, प्राप्त गरिएको डाटा बाहेक अरू केही छैन, र अब हामी यसको साथ के गर्ने थाहा छैन।

विधिशास्त्र

Nginx र Apache को लागि अपरेटिङ सिस्टम IIS Windows Server Core 18.04 को लागि Ubuntu 2019 LTS हो। परीक्षणहरू अघि, सबै अपरेटिङ सिस्टमहरूले डिसेम्बर 04.12.2019, XNUMX सम्मका नवीनतम अद्यावधिकहरू प्राप्त गरे।

परीक्षणहरू विशेष रूपमा HTTP मार्फत गरिएको थियो। प्रत्येक वेब सर्भरले उही पृष्ठ चलायो, ​​Codrops बाट नि: शुल्क Jekyll टेम्प्लेट। लिङ्क। प्रत्येक वेब सर्भरमा gzip कम्प्रेसन असक्षम गरिएको थियो।

थ्रुपुट परीक्षण Httpd-उपकरण संग तर्क संग गरिएको थियो:

ab -n 50000 -c 500 http://192.168.76.204:80/

सर्भरहरू 10, 5, र एक कोरमा 1, 8, र 4 प्रतिशत कोरमा सीमित थिए। परीक्षण बेन्च 9900K@5400MHz भएको कम्प्युटर थियो, जसको मतलब 10% सीमा प्राप्त गर्ने सर्भरले प्रति कोर लगभग 540MHz प्राप्त गर्छ।

TTFB परीक्षण गरिएको थियो जब सर्भर पहिलो पटक बुट गरियो र DevTools प्रयोग गरेर मापन गरियो; परिणाम प्राप्त गरेपछि, सर्भर बन्द गरियो र कुनै पनि प्रकारको क्यासहरूको उपस्थिति हटाउन अघिल्लो चेकपोइन्टमा फिर्ता गरियो।

परीक्षक र वेब सर्भर एउटै होस्टमा र एउटै भर्चुअल स्विचमा थिए।

डिस्क सबसिस्टमको तुरुन्तै मूल्याङ्कन गर्न, बाधाहरूको बारेमा एक विचार पाउनको लागि ATTO र CrystalDIskMark बेन्चमार्कको नतिजाहरू।

भर्चुअल मेसिनबाट लिइएको डाटा:

परिणामहरु:

TTFB:

IIS को लागि औसत TTFB सबैभन्दा सानो हो, 0,5ms, Apache को लागि 1,4ms र Nginx को लागि 4ms।

थ्रुपुट:

पहिले, कोरको संख्यामा आधारित प्रत्येक सर्भरले कति राम्रोसँग मापन गर्छ भनेर हेरौं।

ग्राफले वेब सर्भरमा परीक्षक कलहरूको संख्या र विलम्बता देखाउँछ। ग्राफले देखाउँछ कि NGINX ले 98ms वा कममा साइट डेलिभर गर्दै सबै अनुरोधहरूको 20% प्रशोधन गरेको छ। IIS, Apache जस्तै, क्रमशः 5ms र 76ms मा सबै कलहरूको अन्तिम 14% पूरा गर्यो।

ग्राफले तनाव परीक्षणको क्रममा एउटा अनुरोधको लागि औसत प्रशोधन समय देखाउँछ।

तपाईले ग्राफहरूबाट देख्न सक्नुहुने रूपमा, IIS ले Apache र Nginx दुबैलाई उडायो, उच्च लोड अन्तर्गत महत्त्वपूर्ण रूपमा ढिलो भयो। 

IIS स्पष्ट रूपमा 4 भन्दा XNUMX कोरलाई प्राथमिकता दियो, XNUMX मा कम विलम्बताहरू देखाउँदै, तर यसले एउटा कोरलाई पनि कडा रूपमा समर्थन गर्दैन।

NGINX सबै 8 कोरहरूमा राम्रो मापन गर्दछ, र Apache को लागि, एकल-कोर परिदृश्य उत्तम विकल्प जस्तो देखिन्छ।

स्केलेबिलिटी:

nginx:

अब फ्रिक्वेन्सी र कोरहरूको संख्याको सन्दर्भमा स्केलेबिलिटी हेरौं। 

Nginx ले 1 र 4 कोरहरूको लागि 1% को सीमामा परीक्षणहरू पास गरेन; जब यसले 2000 अनुरोधहरू पार गर्यो, यसले परीक्षकसँग जडान समाप्त गर्यो।

अपाचे:

Apache, Nginx जस्तै, 2500 अनुरोधहरू प्रशोधन गरेर, जडान छोड्यो र बन्द गर्यो। Apache 8, 4 र 1 कोर मा 1% को सीमा संग परीक्षण असफल भयो, तर यसको अतिरिक्त यो पनि एक कोर मा 5% सीमा संग परीक्षण असफल भयो, जुन Nginx भन्दा खराब छ।

IIS:

परीक्षणको क्रममा, IIS ले अनुरोधहरूको विशाल लाम जम्मा गर्‍यो तर ती प्रत्येकलाई प्रशोधन गर्‍यो। स्पष्ट रूपमा, बाकस बाहिर अनुरोध प्रक्रियाको लागि कुनै टाइमआउटहरू सेट गरिएको छैन।

चार्टले परीक्षण पूरा गर्न लागेको समय देखाउँछ। पूर्णतया बेतुका परीक्षण कन्फिगरेसनहरू खारेज गरियो। रेखाचित्रले हार्डवेयरको कुरा गर्दा IIS कत्तिको माग छ, र NGINX कति राम्रो छ भनेर देखाउँछ।

डिस्कबाट स्केलेबिलिटी:

nginx:

अब फ्रिक्वेन्सी र कोरको संख्या र डिस्क गतिको सन्दर्भमा स्केलेबिलिटी हेरौं। 

यस पटक Nginx दुई को सट्टा 4 परीक्षण असफल भयो।

अपाचे:

Apache पछिल्लो पटक जत्तिकै परीक्षण असफल भयो।

IIS:

IIS ले लगभग उस्तै ग्राफ देखाउँछ, जस्तो कि त्यहाँ कुनै डिस्क प्रतिबन्धहरू थिएनन्। सामान्यतया, सबै सर्भरहरूको ग्राफिक्स धेरै परिवर्तन भएन, जसको मतलब तिनीहरू प्रत्येकले RAM मा स्थिर डाटा क्यास गरे र त्यहाँबाट सेवा गरे। यहाँ हामी मुख्य बाधा देख्छौं - वेब सर्भर नै।

यो परीक्षणको आधारमा निष्कर्ष निकाल्न धेरै चाँडो छ; हामीले अझै सम्म HTTPS, कम्प्रेसन र HTTP/2 लाई Let's Encrypt बाट प्रत्यक्ष प्रमाणपत्रको साथ परीक्षण गरेका छैनौं। यसबारे हामी अर्को लेखमा कुरा गर्नेछौं।

स्रोत: www.habr.com