अपाचे + नगनेक्स + गज़िप_स्टैटिक + युकोमप्रेसर

इस लेख में, मैं अपाचे और नेग्नेक्स के बीच बुनियादी अंतर, फ्रंटएंड बैकएंड की वास्तुकला, बैकेंड के रूप में अपाचे की स्थापना और फ्रंटेंड के रूप में नेग्नेक्स के बारे में वर्णन करूंगा। मैं एक ऐसी तकनीक का भी वर्णन करूंगा जो एक वेब सर्वर के संचालन को गति देती है: gzip_static + yuicompressor।

nginx

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

• worker_processes
  
  
  
  - शुरू करने के लिए प्रक्रियाओं की संख्या। आमतौर पर प्रोसेसर कोर की संख्या के बराबर सेट।
• worker_connections
  
  
  
  - एक प्रक्रिया द्वारा संसाधित कनेक्शन की अधिकतम संख्या। यह सीधे सिस्टम पर खुले फ़ाइल डिस्क्रिप्टर की अधिकतम संख्या (लिनक्स पर डिफ़ॉल्ट रूप से 1024) पर निर्भर करता है।

अपाचे

अपाचे एक भारी सर्वर है (यह ध्यान दिया जाना चाहिए कि, यदि वांछित है, तो इसे काफी हल्का किया जा सकता है, हालांकि, इससे इसकी वास्तुकला नहीं बदलेगी); इसके दो मुख्य कार्य मॉडल हैं - प्रीफ़ॉर्क और वर्कर ।

प्रीफ़ॉर्क मॉडल का उपयोग करते हुए, अपाचे प्रत्येक अनुरोध को संसाधित करने के लिए एक नई प्रक्रिया बनाता है, और यह प्रक्रिया सभी काम करती है: अनुरोध को स्वीकार करती है, सामग्री उत्पन्न करती है, और उपयोगकर्ता को देती है। यह मॉडल निम्नलिखित मापदंडों से कॉन्फ़िगर किया गया है:

• StartServers
  
  
  
  - वेब सर्वर शुरू होने पर शुरू करने के लिए प्रक्रियाओं की संख्या निर्धारित करता है।
• MinSpareServers
  
  
  
  - निष्क्रिय प्रक्रियाओं की न्यूनतम संख्या। यह आवश्यक है ताकि जब कोई अनुरोध आए, तो यह तेजी से संसाधित करना शुरू कर देगा। वेब सर्वर अतिरिक्त प्रक्रिया शुरू करेगा ताकि वे निर्दिष्ट संख्या हो।
• MaxSpareServers
  
  
  
  - निष्क्रिय प्रक्रियाओं की अधिकतम संख्या। यह आवश्यक है ताकि अतिरिक्त स्मृति पर कब्जा न हो। वेब सर्वर अनावश्यक प्रक्रियाओं को मार देगा।
• अधिकतम ग्राहक - समसामयिक ग्राहकों की अधिकतम संख्या। वेब सर्वर प्रक्रियाओं की निर्दिष्ट संख्या से अधिक शुरू नहीं करेगा।
• MaxRequestsPerChild
  
  
  
  - प्रक्रिया की प्रक्रिया की अधिकतम संख्या, जिसके बाद वेब सर्वर इसे मार देगा। फिर, स्मृति को बचाने के लिए, क्योंकि प्रक्रियाओं में मेमोरी धीरे-धीरे "लीक" होगी।

यह मॉडल Apache 1.3 द्वारा समर्थित एकमात्र था। यह स्थिर है, सिस्टम से मल्टीथ्रेडिंग की आवश्यकता नहीं है, लेकिन यह बहुत सारे संसाधनों का उपभोग करता है और कार्यकर्ता मॉडल की गति में थोड़ा खो देता है।

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

• StartServers
  
  
  
  - वेब सर्वर शुरू होने पर शुरू करने के लिए प्रक्रियाओं की संख्या निर्धारित करता है।
• MinSpareThreads
  
  
  
  - प्रत्येक प्रक्रिया में थ्रेड्स की न्यूनतम संख्या लटकी हुई है।
• MaxSpareThreads
  
  
  
  - प्रत्येक प्रक्रिया में अधिकतम लटके हुए धागे।
• ThreadsPerChild
  
  
  
  - थ्रेड्स की संख्या सेट करता है जो प्रत्येक प्रक्रिया शुरू होने पर शुरू होती है।
• अधिकतम ग्राहक - समसामयिक ग्राहकों की अधिकतम संख्या। इस स्थिति में, सभी प्रक्रियाओं में थ्रेड्स की कुल संख्या सेट करता है।
• MaxRequestsPerChild
  
  
  
  - प्रक्रिया की प्रक्रिया की अधिकतम संख्या, जिसके बाद वेब सर्वर इसे मार देगा।

सीमांत बैकेंड

अपाचे की मुख्य समस्या यह है कि प्रत्येक अनुरोध (कम से कम एक धागा) के लिए एक अलग प्रक्रिया आवंटित की जाती है, जिसे विभिन्न मॉड्यूलों के साथ भी लटका दिया जाता है और बहुत सारे संसाधनों का उपभोग किया जाता है। इसके अलावा, यह प्रक्रिया मेमोरी में लटकाएगी जब तक कि यह क्लाइंट को सभी सामग्री न दे। यदि ग्राहक के पास एक संकीर्ण चैनल है, और सामग्री काफी मात्रा में है, तो इसमें लंबा समय लग सकता है। उदाहरण के लिए, सर्वर 0.1 सेकंड में सामग्री उत्पन्न करेगा, और यह 10 सेकंड के लिए क्लाइंट को दिया जाएगा, सभी सिस्टम संसाधन लेते समय।

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

Nginx बंडल (फ्रंटएंड) + Apache (बैकएंड) को कॉन्फ़िगर करना

यह माना जाता है कि Nginx और Apache पहले से ही स्थापित हैं। आपको सर्वर को कॉन्फ़िगर करना होगा ताकि वे विभिन्न बंदरगाहों को सुनें। उसी समय, यदि दोनों सर्वर एक ही मशीन पर स्थापित होते हैं, तो बैकएंड को केवल लूपबैक इंटरफ़ेस (127.0.0.1) पर लटका देना बेहतर होता है। Nginx में, यह सुनने के निर्देश के साथ कॉन्फ़िगर किया गया है:

  80 सुनो; 

अपाचे में, इसे सुनो निर्देश के साथ कॉन्फ़िगर किया गया है:

  127.0.0.1:81 सुनें 

अगला, आपको Nginx को प्रॉक्सी बैकएंड अनुरोधों को बताने की आवश्यकता है। यह निर्देशन द्वारा किया जाता है। proxy_pass 127.0.0.1:81;



। यह संपूर्ण न्यूनतम विन्यास है। हालाँकि, हमने ऊपर कहा था कि स्टैग्नेंट फाइल्स की वापसी के साथ Nginx को सौंपना बेहतर है। मान लीजिए कि हमारे पास एक विशिष्ट PHP साइट है। फिर हमें अपाचे पर केवल .php फ़ाइलों के लिए प्रॉक्सी से अनुरोध करने की आवश्यकता है, नगनेक्स पर सब कुछ प्रसंस्करण (यदि आपकी साइट mod_rewrite का उपयोग करती है, तो आप Nginx पर फिर से लिखना भी कर सकते हैं, और बस .htaccess फ़ाइलों को बाहर फेंक सकते हैं)। यह भी विचार करना आवश्यक है कि क्लाइंट अनुरोध Nginx पर आता है, और Apache के लिए अनुरोध Nginx द्वारा पहले से ही किया जाता है, इसलिए कोई होस्ट HTTP शीर्ष लेख नहीं होगा, और Apache क्लाइंट पता (REMOTE_ADDR) 127.0.0.1 निर्धारित करेगा। होस्ट हेडर को स्थानापन्न करना आसान है, लेकिन अपाचे REMOTE_ADDR को ही निर्धारित करता है। यह समस्या अपाचे के लिए mod_rpaf का उपयोग करके हल की गई है। यह निम्नानुसार काम करता है: नग्नेक्स क्लाइंट आईपी को जानता है और एक निश्चित HTTP हेडर (उदाहरण के लिए, एक्स-रियल-आईपी) को जोड़ता है जिसमें यह आईपी पंजीकृत है। mod_rpaf इस शीर्ष लेख को प्राप्त करता है और अपाचे REMOTE_ADDR चर के लिए अपनी सामग्री लिखता है। इस प्रकार, अपाचे द्वारा निष्पादित php स्क्रिप्ट क्लाइंट का वास्तविक आईपी देखेंगे।

अब कॉन्फ़िगरेशन जटिल हो जाएगा। सबसे पहले, सुनिश्चित करें कि Nginx और Apache दोनों के पास एक ही रूट के साथ एक ही वर्चुअल होस्ट है। Nginx के लिए उदाहरण:

  सर्वर {
	 80 सुनो;
	 server_name example.com;
	 root /var/www/example.com/;
 } 

अपाचे के लिए उदाहरण:

  <VirtualHost 127.0.0.1:81>
	 DocumentRoot "/var/www/example.com/"
	 ServerName example.com
 </ VirtualHost> 

अब हम उपरोक्त योजना के लिए सेटिंग्स सेट करते हैं:

nginx:

  सर्वर {
	 80 सुनो;
	 server_name example.com;
	 स्थान / {
		 root /var/www/example.com/;
		 index index.php;
	 }
	 स्थान ~ \ .php ($ | \ /) {
		 प्रॉक्सी_पास http://127.0.0.1:81;
		 प्रॉक्सी_सेट_हेडर एक्स-रियल-आईपी $ रिमोट_ड्रेड;
		 xy_set_header होस्ट $ होस्ट;
	 }
 } 

अपाचे:

  # mod_rpaf सेटिंग
 RPAFenable पर
 RPAFproxy_ips 127.0.0.1
 RPAFheader X-Real-IP

 <VirtualHost 127.0.0.1:81>
	 DocumentRoot "/var/www/example.com/"
	 ServerName example.com
 </ VirtualHost> 

नियमित अभिव्यक्ति \.php($|\/)



दो स्थितियों का वर्णन करती है: * .php के लिए एक अनुरोध और * .php / foo / bar के लिए एक अनुरोध। कई सीएमएस के काम के लिए दूसरा विकल्प आवश्यक है। जब example.com/ का अनुरोध किया जाता है , तो अनुरोध को फिर से लिखा जाएगा example.com/index.php (चूंकि हमने इंडेक्स फ़ाइल को परिभाषित किया है) और अपाचे के लिए भी अनुमानित होगा।

तेजी लाने: gzip_static + yuicompressor

वेब पर Gzip अच्छा है। पाठ फ़ाइलें पूरी तरह से संकुचित हैं, ट्रैफ़िक सहेजा जाता है, और सामग्री को तेज़ी से उपयोगकर्ता तक पहुंचाया जाता है। Nginx मक्खी पर संपीड़ित कर सकता है, इसलिए कोई समस्या नहीं है। हालांकि, प्रोसेसर संपीड़न सहित फ़ाइल संपीड़न पर समय की एक निश्चित राशि खर्च की जाती है। और यहाँ Nginx gzip_static निर्देश बचाव के लिए आता है। इसके काम का सार इस प्रकार है: यदि, किसी फ़ाइल का अनुरोध करते समय, निगनेक्स को एक ही नाम और अतिरिक्त एक्सटेंशन ".gz" के साथ एक फ़ाइल मिलती है, उदाहरण के लिए, style.css और style.css.gz, तो बजाय .css को संपीड़ित करने के बजाय, Nginx के साथ पढ़ा जाएगा। डिस्क पहले से ही संपीड़ित style.css.gz है और इसे संपीडित शैली की आड़ में देगी।

Nginx सेटिंग्स इस तरह दिखेगा:

  http {
	 ...
	 gzip_static on;
	 पर gzip;
	 gzip_comp_level 9;
	 gzip_types एप्लिकेशन / x-javascript टेक्स्ट / css;
	 ... 

बहुत अच्छा, हम एक .gz फ़ाइल को एक बार जनरेट करेंगे ताकि Nginx इसे कई बार हटा दे। इसके अलावा, हम YUI कंप्रेसर का उपयोग करके सीएसएस और जेएस को संपीड़ित करेंगे । यह उपयोगिता सीएसएस और जेएस फाइलों को यथासंभव कम करती है, रिक्त स्थान को हटाती है, नामों को छोटा करती है, आदि।

और यह सब अपने आप सिकुड़ जाता है, और यहां तक ​​कि स्वचालित रूप से अपडेट होने पर, आप क्रोन और एक छोटी स्क्रिप्ट का उपयोग कर सकते हैं। एक दिन में एक बार निम्नलिखित कमांड चलाने के लिए क्रोन में लिखें:

  / usr / bin / find / var / www -mmin 1500 -iname "* .js" -or -iname "* .css" |  xargs -i -n 1 -P 2 packfile.sh 

में -2 पैरामीटर अपने प्रोसेसर के कोर की संख्या निर्दिष्ट करें, अपने वेब निर्देशिका को packfile.sh और परिवर्तन / var / www के लिए पूर्ण पथ लिखना न भूलें।

Packfile.sh फ़ाइल में , लिखें:

  java -jar /var/www/gzip/yuicompressor-2.4.2.jar "$ 1" |  gzip -c -9> "$ 1.gz" 

yuicompressor-2.4.2.jar के लिए सही रास्ता बताना न भूलें।



यह सब, आलोचना सुनने के लिए तैयार है :)