आप यहाँ अनुकूलन की एक विस्तृत, व्यापक दुनिया में आ रहे हैं और निश्चित रूप से एक आकार नहीं है जो सभी दृष्टिकोणों को फिट करता है।
प्रदर्शन को परिभाषित करें
क्या आप किसी एकल उपयोगकर्ता, या समग्र क्षमता / कुल समरूपता के लिए पृष्ठ लोड समय का मतलब है? दोनों बहुत अलग-अलग हैं - और सख्ती से संबंधित नहीं हैं। सीमित क्षमता के साथ फास्ट स्टोर होना पूरी तरह से संभव है; या बहुत सारी क्षमता वाला एक धीमा स्टोर।
तो प्रदर्शन के किसी भी प्रकार को संबोधित करते समय:
- एकल उपयोगकर्ता माना पृष्ठ लोड समय
- कुल क्षमता / संगामिति
आपको प्रत्येक को अपने स्वयं के समाधानों के साथ स्वतंत्र रूप से निपटना होगा - खासकर जब से प्रत्येक के पास अपनी अड़चनें हैं।
आइए हम यह मानें कि आप एक सक्षम होस्ट के साथ हैं जो आपके सर्वर के अन्य पहलुओं को आपके स्टोर के लिए पहले से ही कॉन्फ़िगर कर चुका है।
एकल उपयोगकर्ता माना पृष्ठ लोड समय
MySQL
सीधे अड़चन नहीं है। यह सब विलंबता के बारे में है, मामलों के बहुमत में जब पृष्ठ लोड समय का परीक्षण - केवल कैश मारा जाएगा। तो यहाँ कुंजी विलंबता को कम करने के लिए है।
- MySQL कैश आकार को उचित रूप से ट्यून करें (कोई सही उत्तर नहीं है, हम सेटिंग्स को पूरी तरह से अलग, मासिक, प्रति स्टोर ट्यून करते हैं)
- नेटवर्क विलंबता को कम करें। 64 बाइट फ़्रेम के लिए; 10Mbps के लिए 51.2 51, 100Mbps के लिए 5.12µ और 1Gbps के लिए 4.096 fors। यह 100Mbps से 1Gbps तक संक्रमण करके सिर्फ 20% का सुधार देता है। एस 1
- नेटवर्क क्षमता बढ़ाएं। आपको प्रति सेकंड कई मेगाबाइट्स पर आश्चर्य होगा कि एक वेब और डीबी सर्वर के बीच आदान-प्रदान किया जा रहा है, आमतौर पर 10 एमबी / एस से अधिक - इसलिए न्यूनतम 100 एमबी / एस को एस 1 की आवश्यकता होती है । या, बस DB सर्वर को स्थानीय रूप से स्थानांतरित करें।
- SOLR का उपयोग करना। बाहरी इंजन कभी-कभी बेहतर अनुकूल होते हैं, SOLR निश्चित रूप से LARGER कैटलॉग (और मुझे तनाव, बड़े कैटलॉग ) के लिए तेज़ होता है । यहां तक कि अन-ट्यून्ड SOLR स्तरित नेविगेशन और खोज परिणामों को MySQL कैन से अधिक तेजी से उत्पन्न करेगा।
लेकिन इन बदलावों का पेज लोड समय पर ऐसा आंशिक प्रभाव पड़ेगा - जहां अड़चन वास्तव में कहीं और है।
- आवेदन को ट्यून करें। Magento के पास कुछ काफी बड़े कीड़े हैं जिस तरह से यह संग्रह बनाता है और उन्हें कैश करता है; हम कई बड़े कोर कोड मुद्दों पर आए हैं जो प्रदर्शन को अपंग कर सकते हैं। कुछ मामलों में, केवल स्तरित नेविगेशन परिणामों पर उत्पाद गणना प्रदर्शन को हटाने से एक बड़े संग्रह को लोड करने के 2 सेकंड मुंडा हो जाते हैं ।
- MySQL धीमी लॉग की समीक्षा करें। धीमे प्रश्नों की जाँच करें और आवश्यकतानुसार अनुक्रमित जोड़ें। उपयुक्त अनुक्रमित के साथ और बिना कई जोड़ के साथ एक जटिल क्वेरी चलाने के बीच का अंतर दसियों सेकंड हो सकता है ।
आवेदन अड़चन है। सॉफ्टवेयर नहीं। इसलिए केवल कोर-कोड में सुधार या अपने टेम्पलेट को कम भारी बनाने से किसी भी MySQL कॉन्फ़िगरेशन परिवर्तन की तुलना में प्रदर्शन पर अधिक नाटकीय प्रभाव पड़ेगा ।
हम किससे परेशान नहीं होंगे
- स्टोरेज इंजन को बदलना। MariaDB और Percona समान InnoDB इंजन - Percona XtraDB साझा करते हैं। उन्हें एक और एक ही माना जा सकता है। एकल क्वेरी निष्पादन समय के संदर्भ में - प्रदर्शन बिल्कुल वैनिला MySQL बिल्ड का दर्पण होगा। यह लोड / कंसीडर के तहत प्ले में आता है।
- एक MySQL गुलाम चल रहा है। यह प्रदर्शन में सुधार नहीं करेगा जब तक कि दास शारीरिक रूप से करीब (नेटवर्क के दृष्टिकोण से) स्थित न हो, या दास के पास मास्टर की तुलना में बेहतर हार्डवेयर हो। यह लोड / कंसीडर के तहत प्ले में आता है।
- बाहरी DB सर्वर चलाना। यह अब तक की सबसे खराब सलाह है जिसे हम कई मेजबानों / एजेंसियों द्वारा बार-बार सौंपते हैं। जब तक आप हार्डवेयर / संसाधनों पर छत से नहीं टकराते हैं या आपको कई वेब सर्वर मिलते हैं (पढ़ें: उच्च उपलब्धता), मैगेंटो स्टोर के लिए स्थानीय मशीन पर MySQL एक अच्छा विचार है। यह सभी नेटवर्क ओवरहेड और विलंबता को काट देता है। यहां तक कि एक 100Gb / s नेटवर्क (हाँ, प्रति सेकंड एक सौ गीगाबिट्स) की तुलना कच्चे वॉल्यूम, थ्रूपुट और विलंबता के लिए एक स्थानीय यूनिक्स सॉकेट के साथ नहीं होगी ।
s1 केवल अलग डेटाबेस सर्वर के लिए। स्थानीय DB सर्वर पर लागू नहीं होता है।
कुल क्षमता / संगामिति
MySQL अड़चन
हो सकती है। लेकिन केवल एक बार जब आप अपने PHP प्रदर्शन और क्षमता को उस बिंदु पर ले जाते हैं, जहां MySQL चीजों को धीमा कर रहा है। यदि आपने वार्निश और एफपीसी को ठीक से कॉन्फ़िगर किया है (हमें इस बात की शुरुआत न करें कि हमने कितने असफल प्रयासों को या तो देखा है) - तो MySQL एक अड़चन बन जाता है।
तो उपरोक्त संशोधनों के अतिरिक्त।
- MySQL इंजन बदलें। XtraDB लोड के तहत उत्कृष्टता प्राप्त कर सकता है और स्टॉक MySQL वितरण पर वास्तविक लाभ दिखाता है।
- MySQL के साथ अद्यतित रहें। 5.5 लोड के तहत 5.0 से बेहतर प्रदर्शन करता है।
- PHP MySQL ड्राइवर बदलें। PHP 5.3 और नए में एक देशी MySQL ड्राइवर है, लेकिन कुछ परिस्थितियों में, हमने Magento के लिए MySQLND को बेहतर बनाने के लिए अलग ड्राइवर के साथ PHP 5.2 पाया है। इसे अपने लिए परखें
- खोज इंजन बदलें। SOLR / Sphinx (या यहां तक कि कुछ 3 पार्टी बाहरी सेवाओं) के लिए खोज को आगे बढ़ाते हुए वास्तव में गैर-लेन-देन भार (यानी लोगों को आदेश नहीं रखने) के बोझ को कम कर सकते हैं।
- स्तरित नेविगेशन इंजन बदलें। फिर से, SOLR स्तरित नेविगेशन के लिए एक शानदार इंजन है और इसकी गैर-लॉकिंग प्रकृति के कारण MySQL की तुलना में कहीं अधिक तेज है।
- एक MySQL दास जोड़ें। यह ब्राउज़िंग (गैर-लेन-देन) लोड में मदद करता है , लेकिन आपको प्रति घंटे अधिक आदेशों को संसाधित करने में मदद नहीं करेगा - क्योंकि यह इस डेटा को संसाधित करने और दोहराने के लिए मास्टर पर निर्भर है।
हम किससे परेशान नहीं होंगे
- मास्टर / मास्टर। मास्टर / स्लेव के हार्डवेयर संतृप्ति के उच्च उच्च टिपिंग बिंदु के कारण सेट अप (प्रति घंटे 1000 से अधिक ऑर्डर) - हमने कभी भी उत्पादन में मास्टर / मास्टर का उपयोग करने की आवश्यकता नहीं पाई है। हमने व्यापक परीक्षण किया है, लेकिन प्रदर्शन परिप्रेक्ष्य से और मास्टर / मास्टर के अंतर्निहित जोखिमों और समस्याओं के साथ इसे कभी भी लाभप्रद नहीं पाया, यह बस इसके लायक नहीं है।
बनाम लिखो स्केलेबिलिटी
अंतिम पैराग्राफ वास्तव में स्केलेबिलिटी को पढ़ने और लिखने के एक प्रमुख क्षेत्र की ओर ले जाता है। पढ़ें स्केलिंग अधिक से अधिक दासों के साथ बहुत अधिक जटिलता के बिना काफी असीम रूप से प्रदर्शन किया जा सकता है।
मैगेंटो के रिट्स को राइट्स के अनुपात को देखते हुए लगभग 0.1% है - यह देखते हुए कि राइट्स को अधिक चिंता नहीं होनी चाहिए। यही कारण है कि मैंने MySQL क्लस्टर और इसके स्मार्ट फीचर्स जैसे कि ऑटो-शार्डिंग (अलग-अलग मशीनों को अलग करना) का उल्लेख नहीं किया है ।
हार्डवेयर, हार्डवेयर, हार्डवेयर
जब यह सुधार की बात आती है, तो हार्डवेयर आसानी से इसका सबसे तेज जवाब होता है, इसलिए मैंने जानबूझकर दोनों परिदृश्यों में इसका उल्लेख नहीं किया है।
लेकिन अगर आपके अंतर्निहित हार्डवेयर अपर्याप्त है, तो दुनिया के सभी सॉफ़्टवेयर परिवर्तन कोई अंतर नहीं करेंगे। इसका मतलब हो सकता है ...
- सीमित बफ़र्स के साथ कम गुणवत्ता वाले स्विच
- अत्यधिक संतृप्त नेटवर्क लिंक
- भौगोलिक रूप से दूर के सर्वर
- खराब नेटवर्क QoS / CoS
- RAM की सीमित कुल राशि
- कम मेमोरी बैंडविड्थ रैम
- कम IOPs HDD सबसिस्टम
- सॉफ्टवेयर RAID नियंत्रक
- कम घड़ी की गति वाला सीपीयू
- कम बैंडविड्थ वाला चिपसेट
- हार्डवेयर वर्चुअलाइजेशन (कर्नेल स्तर वर्चुअलाइजेशन के अलावा लगभग सभी प्रकार)
आजकल, वास्तव में उच्च स्तर पर है कि आप वास्तव में हार्डवेयर पर कितना ऊंचा पैमाना बना सकते हैं। क्लाउड "क्लाउड में" अनंत स्केलिंग के मिथक को अनदेखा करता है क्योंकि क्लाउड हार्डवेयर काफी औसत दर्जे का होता है। उदाहरण के लिए अमेज़ॅन के प्रमुख मॉडल केवल 12 करोड़ @ 3.3GHz हैं। लेकिन इसके बाहर, कुछ बहुत शक्तिशाली सर्वर उपलब्ध हैं - हमारे शीर्ष सर्वर में 160 कोर और 2TB (हाँ, टेराबाइट्स) रैम हैं। हमने अभी तक किसी की क्षमताओं से अधिक नहीं देखा है।
तो आपको ऊर्ध्वाधर स्केलिंग के लिए एक विशाल गुंजाइश मिली है, इससे पहले कि आपको क्षैतिज स्केलिंग पर विचार करने की आवश्यकता हो।
कभी चलती लक्ष्य
यह ध्यान देने योग्य है कि प्रदर्शन की खोज में, अड़चन हमेशा चलती रहेगी।
एक शेयर Magento स्टोर के लिए।
कैश चालू करें। PHP अड़चन
है बैकएंड कैश जोड़ें। PHP अड़चन है
एक आवेदन-स्तर पूर्ण पृष्ठ कैश जोड़ें। PHP अड़चन है
एक सर्वर-स्तरीय फ्रंट-एंड कैश जोड़ें (जैसे। वार्निश)। MySQL अड़चन है
एक वैकल्पिक खोज / स्तरित नेविगेशन इंजन (जैसे। SOLR / Sphinx) जोड़ें। PHP अड़चन है
अधिक एप्लिकेशन सर्वर जोड़ें। MySQL एक अड़चन
है MySQL दास जोड़ें। फ्रंट-एंड कैश वह टोंटी है जिसमें
अधिक फ्रंट-एंड कैश सर्वर जोड़ें। PHP अड़चन है
अधिक एप्लिकेशन सर्वर जोड़ें। एसओएलआर / स्फिंक्स अड़चन है
आदि।
यह बहुत ज्यादा कुल्ला-धोने के दोहराने का मामला बन जाता है। लेकिन यह समझने के लिए स्पष्ट है कि MySQL निश्चित रूप से अनुकूलन के लिए कॉल का पहला पोर्ट नहीं है - और वास्तव में केवल तब चलता है जब MySQL PHP के आनुपातिक रूप से अधिक CPU का उपभोग कर रहा है - और यह कभी भी तब होता है जब FPC और वार्निश दोनों का उपयोग होता है और सर्वर (s) पूरी तरह से प्रोसेसिंग के आदेश हैं और कुछ और नहीं (क्योंकि बाकी सब कुछ कैश में है)।
आँख बंद करके बदलाव न करें
बस एक MySQL गुलाम जोड़ना क्योंकि आप पढ़ते हैं कि हम ऊपर कहते हैं कि यह मदद करेगा, आप एक विशाल स्तर पर प्रदर्शन और विश्वसनीयता खर्च कर सकते हैं। एक भीड़भाड़ नेटवर्क, कम कल्पना दास सर्वर या यहां तक कि अनुचित सेटिंग्स प्रतिकृति समस्याओं का कारण बन सकती हैं जो आपके स्टोर को धीमी गति से प्रस्तुत कर सकती हैं क्योंकि यह मास्टर और स्लेव के बीच सिंक्रनाइज़ेशन समस्याओं का कारण था।
चीजों को परिप्रेक्ष्य में रखने के लिए - कुछ वास्तविक दुनिया उदाहरण हैं।
उदाहरण 1 - प्रति घंटे 300 ऑर्डर
हमने प्रति घंटे 300 ऑर्डर देने के लिए निम्नलिखित हार्डवेयर का उपयोग किया है ; और केवल उस टिपिंग बिंदु पर - हमने तब एक समर्पित MySQL सर्वर और एक स्थानीय MySQL दास को जोड़ने की आवश्यकता महसूस की।
1 सर्वर
CPU: 2x इंटेल E5-4620
RAM: 64GB HDD: 4x 80k IOP / s SSDs
RAID: हार्डवेयर RAID 10
Magento संस्करण: Magento EE
OS: MageStack
पूरे समय के दौरान, लोड औसत 3.00 के नीचे रहा।
उदाहरण 2 - प्रति घंटे 180 आदेश
दो दिन पहले, हमारा एक नया ग्राहक आसानी से एक बड़े ट्रैफ़िक स्पाइक को भिगो देता है। एकल-सर्वर और मैगनेटो सामुदायिक संस्करण के साथ प्रति घंटे 180 ऑर्डर संसाधित करना ।
1 सर्वर
CPU: 2x इंटेल E5-4620
RAM: 64GB HDD: 4x 80k IOP / s SSDs
RAID: हार्डवेयर RAID 10
Magento संस्करण: Magento CE
OS: MageStack
वेबसाइट: Wellgosh.com
पूरे समय के दौरान, लोड औसत ६.०० से कम रहा। इस परिदृश्य में लोड अधिक था और यह कारकों के एक जोड़े के लिए नीचे था।
- उदाहरण 1 में स्टोर-साइड ट्यूनिंग का प्रदर्शन नहीं किया गया था
- एक आवेदन-स्तर एफपीसी की कमी
और इस की पुनरावृत्ति को देखते हुए, हम अभी भी ग्राफ के माध्यम से कुछ प्रतिक्रिया देने के लिए विस्तृत आँकड़े प्राप्त कर चुके हैं। ये एक उत्कृष्ट कहानी बताते हैं कि कैसे लोड को एक अलग Magento आर्किटेक्चर (लोड बैलेंसर, वेब सर्वर, db सर्वर आदि - MageStack का उपयोग करके ) के प्रमुख घटकों के बीच वितरित किया जाता है ।
तो आगे से पीछे ... जिस तारीख को आप देखना चाहते हैं, वह 22 फरवरी को सुबह 12:00 बजे है।
फ़ायरवॉल पैकेट
वार्निश ट्रैफ़िक
Nginx आवागमन
MySQL लोड
सीपीयू लोड
और सबसे महत्वपूर्ण बात, भार का वितरण
यह छवि वास्तव में यह सब बताती है। और यह है कि MySQL निश्चित रूप से बोझ नहीं है - अभी तक कम से कम नहीं। इसलिए हमारी सलाह, अपने प्रदर्शन की चिंताओं को कहीं और केंद्रित करें, जब तक कि आप प्रति घंटे कुछ हजार से अधिक आदेशों को संसाधित नहीं कर रहे हैं।
और संक्षेप में
प्रदर्शन में बदलाव करना "एक आकार सभी के लिए उपयुक्त नहीं है"। यह आपके वर्तमान अड़चनों का विश्लेषण करने और आपकी दुकान और बुनियादी ढांचे के अनुरूप सूक्ष्म परिवर्तन / समायोजन करने का मामला है।
लेकिन एक तरफ प्रदर्शन, Percona का उपयोग करने के लिए अन्य लाभ हैं
हम Percona XtraDB का उपयोग करते हैं, लगभग विशेष रूप से। हम MySQL के कस्टम-संकलित बिल्ड को चलाते हैं जिसे हमने विशेष रूप से Magento के लिए विकसित किया था और इस प्रक्रिया के दौरान Percona से परामर्श किया था। लेकिन यह सिर्फ प्रदर्शन नहीं था जिसने इस विकल्प को प्रभावित किया।
- पेरकोना टूलकिट
- pt-प्रश्न-पचाने
- xtrabackup
- आदि।
- Percona रिलीज आवृत्ति
- पर्कोना सलाहकार समर्थन
- InnoDB पूल संरक्षण के साथ वार्म कैश पुनः आरंभ होता है
और भी बहुत कुछ। इसलिए MySQL पर इसका उपयोग करने से केवल प्रदर्शन के अलावा अन्य फायदे भी थे। वास्तव में - MySQL है और हमेशा प्रदर्शन और स्थिरता की खोज में हमारी चिंताओं में से सबसे कम रहा है।
विशेषताएं: wellgosh.com , sonassi.com , iebmedia.com ।