परिणाम की माप के साथ Drupal के लिए सर्वर अनुकूलन

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

इसके बजाय अग्रदूत

यह लेख Drupal की आधिकारिक वेबसाइट पर उपलब्ध सर्वर ट्यूनिंग विचार के चयन पर आधारित है। इसमें से, जो चुना गया है वह प्रकृति में सबसे सार्वभौमिक है और एक मनमाना सर्वर पर लागू किया जा सकता है जिस पर Drupal का उपयोग करने की योजना है (विशेष रूप से, PHP और MySQL की स्थापना पर अनुभाग)। यह लेख स्वयं CMS की ठीक-ठीक ट्यूनिंग को कवर नहीं करता है।

प्रायोगिक मॉडल

लोड को सत्यापित करने के लिए, एक निश्चित संदर्भ भारी साइट बनाई गई थी। इसके लिए, Drupal 7 और कई लोकप्रिय मॉड्यूल का उपयोग किया गया था, जिसमें व्यू और पथौतो शामिल थे। सामग्री प्रकारों में से एक में एक संख्यात्मक क्षेत्र जोड़ा गया था, जो 1 से 10 तक का मान ले सकता था। डेवेल मॉड्यूल की सामग्री पीढ़ी फ़ंक्शन का उपयोग करके, इस प्रकार की सामग्री के लगभग 10 हजार पृष्ठों का निर्माण किया गया था और प्रत्येक पोस्ट के लिए 0 से 15 टिप्पणियों तक।

अगला, एक दृश्य ब्लॉक बनाया गया था और मुख्य पृष्ठ पर रखा गया था, जिसमें 100 यादृच्छिक पृष्ठों का चयन किया गया था, जहां क्षेत्र ने मान 5 लिया (यानी, संभावना सिद्धांत के अनुसार, 1000 पृष्ठों में से 100) उन पर टिप्पणियों के साथ। वैश्विक: यह सुनिश्चित करने के लिए रैंडम फ़िल्टरिंग मानदंड का उपयोग किया गया था कि पृष्ठ को हर लोड पर नए सिरे से तैयार किए जाने की गारंटी है। एक व्यक्तिगत परीक्षण सर्वर पर, ऐसे पृष्ठ के लिए पीढ़ी का समय लगभग 10 सेकंड था। इसके अलावा तैयारी में, कॉमर्स किकस्टार्टर पर आधारित एक ऑनलाइन स्टोर का परीक्षण किया गया था और लगभग 5 हजार उत्पाद तैयार किए गए थे। हालांकि, यह पता चला कि ग्लोबल: रैंडम सर्च एपीआई के साथ सभी अनुकूल नहीं था, और रैंडमाइजेशन के बिना, 96 उत्पादों वाले पृष्ठ पिछले परीक्षण पृष्ठ की तुलना में काफी तेजी से लोड हुए। इसलिए, ऑनलाइन स्टोर की गति पर मापन नहीं किया गया था। परीक्षण साइटों को स्थानांतरित कर दिया गया है ...

प्रायोगिक उपकरण

प्रयोगों के लिए, मैंने कुछ दिनों के लिए हौसले से स्थापित VPS Intel Xeon E3-1230 3.2GHz / 2-3 GB RAM / 30 GB SSD और Intel Xeon E3-1230 / 8GB DDR3 / 4x1TB GATA2 / 100Mbps को नीदरलैंड में अनमाउंट किया (बाद में VPS और VPS के रूप में जाना जाता है)। E3-1230, क्रमशः)। सर्वर में मानक LAMP + Nginx कॉन्फ़िगर था। अधिकांश माप १००० के कुल संख्या और १० से ५० के समानांतर अनुरोधों की संख्या के साथ अब उपयोगिता द्वारा किए गए थे। अंत में, कई लोडिम्पैक्ट परीक्षण भी चलाए गए थे।

कच्चा सर्वर डेटा

किसी भी अनुकूलन के शुरू होने से पहले पहला माप किया गया था। दरअसल, इन मापों में मैंने 40 समानांतर प्रश्नों पर समझौता किया। प्राप्त परिणाम कुछ इस तरह दिखते हैं:


एक्स अक्ष के साथ इस और बाद के समान ग्राफ़ में, उन अनुरोधों का अनुपात होगा जो वाई अक्ष के साथ संबंधित मान से अधिक नहीं होने पर एक समय के लिए परोसे गए थे।

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

PHP अनुकूलन

Drupal के अंतर्गत सर्वर पर सबसे पहला काम यह करना है कि php.ini में memory_limit मान को कम से कम 256M पर सेट करें। एक नियम के रूप में, यह अधिकांश साइटों के लिए पूरी तरह से पर्याप्त है। लेकिन 128M कभी-कभी पर्याप्त नहीं होता है। हालांकि, इसे अनुकूलन नहीं कहा जा सकता है, बल्कि यह एक महत्वपूर्ण आवश्यकता है।

PHP स्तर पर साइटों के काम को गति देने के लिए, डेवलपर्स विभिन्न कैशिंग ऑप्टिमाइज़र का उपयोग करने की सलाह देते हैं। अन्य स्रोत अक्सर एपीसी का उल्लेख करते हैं, इसलिए मैंने उसकी ओर रुख किया। आप इसे निर्देशों में कैसे डाल सकते हैं, इसके बारे में पढ़ सकते हैं। अब हम महत्वपूर्ण सेटिंग्स में रुचि रखते हैं। दरअसल, मुख्य पैरामीटर कैश मेमोरी सेगमेंट का आकार है, apc.shm_size। पृष्ठ जितना भारी होगा, निष्पादन में अधिक भिन्न फाइलें शामिल होंगी, उतना ही अधिक मूल्य होना चाहिए। उदाहरण के लिए, 64M परीक्षण स्थल के लिए पर्याप्त था। इस मान के साथ एक परीक्षण स्टोर ने एक त्रुटि उत्पन्न की:

[Mon Jan 13 21:41:46 2014] [error] [client 176.36.31.190] PHP Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0, referer: http://s2shop.1b1.info/products?page=2 

मान को 256M तक बढ़ाने से इस समस्या को तुरंत समाप्त कर दिया गया। डेवेल मॉड्यूल के अनुसार, एक बार साइटों को देखने के साथ, कैशिंग को शामिल करने से निम्नलिखित पैरामीटर प्रभावित होते हैं:

• पृष्ठ पीढ़ी का समय डेढ़ से दो गुना कम हो गया था;
• परीक्षण स्थल के लिए शिखर मेमोरी की खपत लगभग 50-55 एमबी से घटकर 30-32 एमबी और टेस्ट स्टोर के लिए लगभग 65-70 एमबी से 30-32 एमबी तक कम हो गई।

एपीसी को शामिल करने से एब के साथ बमबारी के परिणामों को कैसे प्रभावित किया गया, इस पर थोड़ी देर बाद चर्चा की जाएगी। सार्वजनिक रूप से उपलब्ध सार्वजनिक जानकारी के अनुसार, Apache + mod_php के बजाय php-fpm का उपयोग उल्लेखनीय परिणाम देता है। हालाँकि, मैंने अभी तक इन दोनों विन्यासों की तुलना करने की कोशिश नहीं की है।

MySQL अनुकूलन

MySQL को ऑप्टिमाइज़ करने के सबसे आसान तरीकों में से एक my.cnf को मेरे-विशाल.cnf के साथ बदलना है। यह फ़ाइल पर्याप्त (2 जीबी या अधिक) रैम और MySQL के बड़े पैमाने पर उपयोग के लिए सिस्टम के लिए डिज़ाइन की गई है। अन्य बातों के अलावा, यह मानक विन्यास से काफी बड़े बफर आकार (key_buffer_size) और क्वेरी कैशिंग (query_cache_size) को शामिल करने में भिन्न होता है।

अनुक्रमिक उपयोग के दौरान पीछे हटने की गति में एक सामान्य परिवर्तन कुछ इस तरह दिखता है।

E3-1230, 10 समानांतर अनुरोध


VPS, 10 समवर्ती अनुरोध


E3-1230, 30 समानांतर अनुरोध


VPS, 30 समवर्ती अनुरोध


जैसा कि आप देख सकते हैं, VPS पर गैर-अनुकूलित MySQL और अनुकूलित के बीच का अंतर E3-1230 की तुलना में अधिक ध्यान देने योग्य है। मुझे यह सुझाव देने की हिम्मत है कि यह वीपीएस पर एसएसडी ड्राइव के उपयोग के कारण है। आजकल, सर्वर कॉन्फ़िगरेशन जिसमें डेटाबेस को एसएसडी पर रखा जाता है, अधिक से अधिक लोकप्रिय हो रहा है। यह देखते हुए कि वे हाल ही में मूल्य में कितना गिर गए हैं, यह समाधान बहुत हिट नहीं करता है और कई मामलों में साइटों के काम को काफी तेज कर सकता है। एसएसडी के पक्ष में एक फायदा, मेरी राय में, निम्नलिखित दो रेखांकन हैं।

E3-1230, 50 समवर्ती अनुरोध


VPS, 50 समवर्ती अनुरोध


जैसा कि आप देख सकते हैं, SATA डिस्क के साथ सर्वर पर, कैशिंग के साथ बफरिंग बहुत जल्दी शुरू हो जाती है। इसी समय, एसएसडी ड्राइव के साथ वीपीएस पर, सामान्य प्रवृत्ति जारी है। VPS पर, मैंने key_buffer_size और query_cache_size मानों को और बढ़ाने की कोशिश की, जिसके कारण मुझे एक महत्वहीन लेकिन स्थिर प्रदर्शन लाभ (MySQL वक्र 2) मिला। हालांकि, इस स्तर पर, दोनों कॉन्फ़िगरेशन पर, प्रोसेसर पहले से ही घुट रहा है।

लोडइम्पैक्ट टेस्ट

एब उपयोगिता का उपयोग करके किए गए परीक्षण साइट पृष्ठों के वास्तविक लोडिंग को नहीं दिखाते हैं, बल्कि प्रदर्शन में गुणात्मक परिवर्तन करते हैं। जीवन डेटा के कुछ प्रकार के लिए, मैंने लोडिम्पैक्ट का उपयोग करके कुछ परीक्षण किए ।

1. 100 एसबीयू तक परीक्षण स्थल के मुख्य पृष्ठ पर लगाए गए थे, मोटे तौर पर समान रूप से 5 अलग-अलग स्थानों (संयुक्त राज्य अमेरिका में 2, यूरोप में 2, ऑस्ट्रेलिया में 1) में वितरित किए गए थे। कुल ग्राफ हमें यह देखने की अनुमति नहीं देता है कि क्या सर्वर ने इस लोड को कम से कम बढ़ाया है।
   
   
   
   लेकिन लोड में वृद्धि अधिक ध्यान देने योग्य हो जाती है यदि आप यूरोपीय बिंदुओं पर शुद्ध रूप से रेखांकन देखते हैं जिसके साथ कनेक्टिविटी बेहतर है।
   
   
   
   उसी समय, कुल डेटा स्ट्रीम 90 एमबीपीएस के करीब था। मैं चैनल को शेल्फ पर पकड़ना चाहता था, लेकिन कोई ऋण नहीं बचा था।
   
   
   
   प्रोसेसर पर लोड ध्यान देने योग्य हो जाता है, हालांकि, लोड औसत एब परीक्षणों के साथ किसी भी तुलना में नहीं जाता है।
   
   
   
2. अंत में, मैंने एक नियमित छोटी जानकारी एसडीएल पर क्लोन की और उस पर 8 अलग-अलग बिंदुओं से लोडिम्पैक्ट सेट किया। सभी परीक्षण बिंदु साइट के विभिन्न पृष्ठों में बदल गए। 10 मिनट में, एसबीयू की संख्या भी 100 तक पहुंच गई।
   
   
   
   वापसी बहुत ही समान थी, बिना किसी स्पष्ट मंदी के।
   
   
   
   उसी समय, सर्वर ने व्यावहारिक रूप से इस परीक्षण को नोटिस नहीं किया।
   
   

एक निष्कर्ष के बजाय

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