120

वर्तमान में हम एक आवश्यकता के साथ काम कर रहे हैं कि वेब सर्वर से पहली प्रतिक्रिया यूके में 200 मी के तहत होनी चाहिए। वर्तमान में लोड बैलेंसर और 1 डीबी सर्वर के तहत 2 समर्पित वेब सर्वर, हम 800ms पर आ रहे हैं।

पल में साइट में 5 से कम ग्राहक, 2 उत्पाद, 4 श्रेणियां हैं, फिलहाल साइट का कोई दृश्य नहीं है, यह शैली मुक्त और छवि मुक्त है।

इसे वार्निश के साथ नगनेक्स पर भी चलाया जा रहा है।

क्या कोई मुझे वेब सर्वर सेटअप पर कोई सलाह दे सकता है? हमारा धीरे-धीरे क्यों आ रहा है? आप इसे अनुकूलित करने के लिए क्या सलाह दे सकते हैं? 400% जल्दी प्राप्त करने की आवश्यकता है!

configuration performance

— lukefowell
स्रोत

2

यदि साइट वार्निश कैश से आ रहा यह <100ms में होना चाहिए

— फैबियन Blechschmidt

क्या आप वास्तव में के लिए पूरा करने की कोशिश कर रहे हैं? प्रति घंटे कितने अनूठे आगंतुक? कितने पृष्ठ / आगंतुक? प्रति घंटे कितने आदेश? सर्वर क्या विनिर्देशन हैं? Magento संस्करण?

— बेन लेसानी - सोनासी

आप सर्वर के बीच प्रतिकृति कैसे संभाल रहे हैं? मशीनों के बीच आपके पास क्या नेटवर्क कनेक्टिविटी है? आप किस PHP संस्करण का उपयोग कर रहे हैं? MySQL संस्करण क्या आप उपयोग कर रहे हैं? क्या सर्वर ओएस आप उपयोग कर रहे हैं?

— बेन लेसानी - सोनासी

उच्चतर ttfb रैंकिंग वाली साइटों को पहले पृष्ठ पर Google ने अमेज़ॅन, ईबे और अन्य लोगों के साथ देखा है, कई तकनीकी कारकों में से एक - कई व्यावसायिक कारकों को ध्यान में नहीं रखना। आप इसे नीचे से ऊपर आ रहे हैं, smes के लिए ठीक है लेकिन शीर्ष साइटों के साथ रैंक करने के लिए यह अलग तरह से काम करता है। आपको डायनामिक पेज लोड 1-2 की आवश्यकता है, हमारे पास 5-10x छोटे हार्डवेयर पर 10,000s उत्पादों के साथ साइटें हैं और कोई fpc (डायनामिक कंटेंट) कम ttfb और <1s की औसत साइट पूर्ण नहीं है। टियर 1/2 प्रदाताओं पर भी - बेहतर रैंकिंग लेकिन टियर 3/4 और 5/6 प्रदाताओं की तुलना में धीमी - fpc समस्या को छुपाता है इसलिए इसे अभी के लिए हटा दें।

145

मैं काट लूंगा।

वेब सर्वर से पहली प्रतिक्रिया यूके में 200ms से कम में आनी चाहिए
। फिलहाल साइट का कोई दृश्य नहीं है, यह स्टाइल फ्री और इमेज फ्री है।

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

हम 800ms पर आ रहे हैं
यह भी पर चलाया जा रहा है Nginx वार्निश के साथ

आपने वार्निश को गलत तरीके से कॉन्फ़िगर किया है।

वार्निश की ठीक से कॉन्फ़िगर की गई स्थापना <100ms पेज लोड समय (हम <10ms के करीब देखें) वितरित करेंगे।

वास्तव में, Magento के लिए, आपको इस तरह से कुछ देखने की उम्मीद करनी चाहिए,

जब कोई ग्राहक लॉग इन नहीं होता ...
Ie एक अनोखा सत्र (ऐड-टू-कार्ट / विशलिस्ट, लॉग इन आदि) नहीं बनाया गया

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

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

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache

वार्निश ट्यूनिंग का मामला नहीं है - इसका एक मामला है - "आप वास्तव में कुछ भी नहीं कर रहे हैं" ।

आदर्श Magento सर्वर कॉन्फ़िगरेशन फ़ाइलें

वहाँ एक नहीं है, ठीक है, काफी नहीं है।

हम 400 से अधिक सर्वरों को संचालित करते हैं, सभी विशुद्ध रूप से Magento स्टोर - अलग-अलग आकार और क्षमता के। और यह दुर्लभ है कि हमारे पास जो कॉन्फ़िगरेशन फाइलें हैं - वे दूसरे से मेल खाएंगी। ऐसा इसलिए है क्योंकि सभी व्यवसाय एक जैसे नहीं हैं।

कई अलग-अलग कारणों से अड़चनें बन सकती हैं:

सक्रिय सत्र के साथ आगंतुक संगणना की उच्च संख्या
'खराब' के शिकार लोग बॉट को क्रॉल करते हैं, जो आवश्यक, अचूक भार पैदा करते हैं
स्तरित नेविगेशन हिट का उच्च अनुपात
खोज प्रश्नों की उच्च संख्या
प्रति घंटे लेनदेन की उच्च मात्रा
खराब तरीके से बनाया गया खाका
बहुत अधिक / धीमी / भारी 3 पार्टी एक्सटेंशन
404 हिट के उच्च अनुपात के लिए आउटडेटेड इनबाउंड लिंक
सीमा पर नेटवर्क इंटरफ़ेस क्षमता
बड़ी / जटिल सूची (उत्पादों / श्रेणियों / विशेषताओं के बहुत सारे)

तो इस पूरे स्पेक्ट्रम में स्टोर के साथ, प्रत्येक के पास अधिक इष्टतम प्रदर्शन के लिए एक अलग दृष्टिकोण है।

ऊपर उल्लिखित मुद्दों को हल करने के लिए; हम जानबूझकर "अधिक / बेहतर हार्डवेयर" बताने से बचेंगे

वार्निश से परे एक एफपीसी का उपयोग करें
नेटवर्क किनारे पर खराब बॉट्स को फ़िल्टर करें / ब्लॉक करें - या कुकी राज्य / URL की परवाह किए बिना वार्निश के सभी अनुरोधों को पुनर्निर्देशित करें
स्टॉक स्तरित नेविगेशन को SOLR में बदलें, स्तरित नेविगेशन फ़िल्टर निर्भर करें
स्टॉक खोज को SOLR में बदलें
MySQL लोड को मास्टर / स्लेव कॉन्फ़िगरेशन में वितरित करें - यह केवल तब करें जब आपने ब्राउज़िंग लोड की गारंटी दी हो वार्निश / FPC द्वारा अवशोषित
टेम्पलेट को फिर से बनाएँ
उन्हें पट्टी करें
वितरण तक मॉनीटर एक्सेस लगातार लॉग करता है और नग्नेक्स / वार्निश पर यूआरएल को फिर से लिखना। यदि यह Nginx स्तर पर कर रहा है - सुनिश्चित करें कि वार्निश 301/302 पुनर्निर्देशन को कैशिंग कर रहा है।
एक सीडीएन के लिए स्थिर सामग्री को विभाजित करें, या कनेक्टिविटी में सुधार करें
अधिक हार्डवेयर जोड़ें (ठीक है, हमें इसे किसी बिंदु पर कहना था)

तो इस बात को ध्यान में रखते हुए - आप देखेंगे कि शायद Nginx config फाइल, PHP fcgi पूल कॉन्फिग फाइल, MySQL config फाइल या वार्निश कॉन्फिग फाइल नहीं है जो समान होने जा रही है। हार्डवेयर के साथ युगल खुद को बदलता है; उपलब्ध स्मृति, I / O प्रदर्शन (HDD और नेटवर्क) और CPU - और आप पाएंगे कि सूक्ष्म भिन्नताएं हैं जो 400% प्रदर्शन का कारण बनती हैं जो आपको इच्छा देती हैं - लेकिन कोई भी त्वरित उत्तर जो आप आसानी से ऑन-लाइन पाएंगे।

आप सहकर्मी पर सहकर्मी 1 प्रायोजित मैगनेटो श्वेत पत्र को कॉपी कर सकते हैं (हम इसकी अनुशंसा नहीं करेंगे); आशा है कि सेटिंग्स आपकी उपलब्ध मेमोरी, थ्रेड लिमिट, टीसीपी / आईपी स्टेट्स, I / O की क्षमता से अधिक नहीं हैं और वेनिला अपाचे / mod_php कॉन्फ़िगरेशन की तुलना में कम प्रदर्शन की ओर ले जाती हैं।

तो चलिए जारी रखते हैं।

आदर्श Magento सर्वर स्टैक

यह आपको वास्तविकता के करीब पहुंचने की अधिक संभावना है। यह प्रदर्शित करने के लिए एक अच्छा उदाहरण यह दिखाना है कि कैसे एक समर्पित मैगनेटो ओएस को कॉन्फ़िगर किया गया है, मैजस्टैक

MageStack - Magento ऑपरेटिंग सिस्टम

अलग उप-घटकों को लें और आपको Magento स्टोर चलाने के लिए सबसे इष्टतम / महत्वपूर्ण सॉफ़्टवेयर की एक सूची मिली है, जब इसे ठीक से कॉन्फ़िगर किया गया है । विशेष रूप से:

फ़ायरवॉल, DOS फ़िल्टर, लोड बैलेंसर, वार्निश, Nginx, PHP, Redis, Memcached, MySQL

इसलिए जब आप पूछें:

सबसे अच्छा Magento सर्वर सेटअप क्या है?

आपका लक्ष्य वास्तव में क्या है?

उच्च उपलब्धता
विश्वसनीयता
प्रशासन की सादगी
प्रदर्शन
अनुमापकता

पर्याप्त व्याख्यान, हम इसे कैसे करेंगे

आंशिक रूप से एक समान नस के नीचे सर्वर गलती पर दिए गए उत्तर को दर्पण करने के लिए । आपको अपने निपटान में 3 सर्वर मिले हैं - इसलिए पहले उन्हें यथासंभव रूप से उन्मुख करें। हम अत्यधिक उपलब्ध समाधान से बचेंगे क्योंकि यह उत्तर के दायरे से बहुत दूर है।

मल्टी-सर्वर कॉन्फ़िगरेशन के लिए आवश्यक उप-घटक हैं:

फ़ायरवॉल
भार संतुलन
वेब सर्वर
MySQL सर्वर
आम भंडारण

तो हम कुछ सिस्टम को बहु-उद्देश्य देंगे। PCI-DSS अनुपालन प्रत्येक सर्वर के लिए एक भूमिका तय करता है। तो 5 भूमिकाओं और 3 सर्वरों के साथ - आप तुरंत ब्रीच में होंगे। MageStack वर्चुअलाइजेशन का उपयोग करके यह गोल हो जाता है - आप भी ऐसा ही कर सकते हैं।

सर्वर 1: लोड बैलेंसर + वेब सर्वर
सर्वर 2: वेब सर्वर
सर्वर 3: डेटाबेस सर्वर

कम-विलंबता और महत्वपूर्ण नेटवर्क बैंडविड्थ (> 1Gbps, <125 )s) के बिना, आम भंडारण होने के बजाय - यह आपके लिए बेहतर है कि आप प्रत्येक मशीन पर केवल स्टोर रुट डायरेक्टरी को स्टोर करें और डेटा का उपयोग करें, या तो वास्तविक समय का उपयोग करके ionotifyया लैप्स का उपयोग करके। एक cronनौकरी। फिर, हम नेटवर्क फ़ाइल सिस्टम जैसे एनएफएस, या ग्लिटर या डीआरबीडी जैसे प्रतिकृति उपकरणों से बचेंगे - क्योंकि विशाल ट्यूनिंग और सभ्य नेटवर्क बैंडविड्थ की आवश्यकता है।

वार्निश को यथासंभव सामने बैठने की आवश्यकता है। लेकिन वार्निश SSL को डिक्रिप्ट नहीं कर सकता है। इसलिए इसे एसएसएल टर्मिनेटर के साथ मिलाएं; नेग्नेक्स, पाउंड, स्टनेल, स्टड आदि वार्निश में लोड बैलेंसर में महान नहीं है - लेकिन एक 2 सर्वर सेट के लिए पर्याप्त होगा।

नेग्नेक्स + पीएचपी-एफपीएम ठीक है, लेकिन नग्नेक्स कूल-सहायता का बहुत अधिक सेवन न करें। यह परंपरागत रूप से अपाचे / mod_php कॉन्फ़िगरेशन के लिए लगभग समान रूप से प्रदर्शन करेगा, यहाँ कुछ अच्छा पढ़ना है कि Nginx का उपयोग क्यों नहीं करना है । नेग्नेक्स अच्छा है, बहुत अच्छा है, लेकिन निश्चित रूप से यह एक Magento स्टोर की अड़चन नहीं है - और इसकी जटिलता और देशी Magento समर्थन की कमी को देखते हुए। अधिकांश नौसिखिए सिस्टम प्रशासक अपाचे / mod_php का उपयोग किसी और चीज़ से करने से लाभान्वित होंगे। यह PHP-FPM का उपयोग करने पर एक पुरातन सिफारिश की तरह लग सकता है - लेकिन हमारे प्रदर्शन परीक्षण ने दिखाया है कि प्रदर्शन केवल ~ 7% Nginx समाधान के साथ तेज है - जब ठीक से कॉन्फ़िगर किया गया हो। एक उच्च-प्रदर्शन, विश्वसनीय नग्नेक्स / पीएचपी-एफपीएम सेट-अप के लिए आवश्यक ट्यूनिंग और अनुभव यह अपाचे / mod_php को बेहतर बनाने के लिए काफी विशाल है। जिसका भी आप उपयोग करना चाहते हैं, वह आपका कॉल है।

डेटाबेस सर्वर सरल है, MySQL। लेकिन जैसा कि पहले उल्लेख किया गया है, यदि आपके पास एक उच्च परिवर्तित साइट है, तो मास्टर / स्लेव कॉन्फ़िगरेशन की सलाह दी जाती है। आप इस दृष्टिकोण का पालन करना चाहिए कि क्या इस लेख को पढ़कर निर्धारित किया जा सकता है ।

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

Redis Magento के मूल निवासी नहीं है, लेकिन कॉलिन मोलेनहॉर के विस्तार के साथ - इसका Memcache की तुलना में बेहतर समाधान है, कैश टैग, सत्र भंडारण और यहां तक कि लगातार कैश भंडारण का समर्थन करता है - यह Memcache के रूप में काफी अस्थिर नहीं है । लेकिन इसकी कमियां हैं। हमने बड़े पैमाने पर उत्पादन भंडार (> 500 ऑर्डर / घंटा,> 30k uniques / hour) पर पाया है कि कैश (और टैग) बहुत तेज़ी से भर सकते हैं और एक बार संतृप्ति के बिंदु हिट हो जाने के बाद, LRU तंत्र कुछ हद तक विफल हो जाता है ( विभिन्न सेटिंग्स के बावजूद) और एक बड़े पैमाने पर तत्काल अड़चन का कारण बनता है। तो यह नियमित रूप से पुराने रिकॉर्ड मैन्युअल रूप से prune करने के लिए विवेकपूर्ण है।

तो किस हार्डवेयर का इस्तेमाल करना चाहिए?

वेब सर्वर: सबसे तेज सीपीयू, अधिकांश सीपीयू कोर, 2 जीबी रैम / कोर
डीबी सर्वर का अनुपात : फास्ट सीपीयू, सबसे तेज डिस्क I / एमबी, सबसे रैम

इसलिए जब आपकी 3 मशीनों का बहु-उपयोग हो रहा है, तो सबसे अच्छा लेआउट होगा:

सर्वर 1: एसएसएल टर्मिनेटर -> वार्निश -> नेग्नेक्स / अपाचे> पीएचपी
सर्वर 2: नेग्नेक्स / अपाचे> PHP, रेडिस, (MySQL स्लेव)
सर्वर 3: MySQL

प्रत्येक आवेदन के विशिष्ट विन्यास के रूप में। खैर, यह आपके हार्डवेयर विनिर्देशों, आपके स्टोर की जटिलता, आपके प्रकार और आगंतुक की प्रकृति और आगंतुकों की सरासर मात्रा के लिए नीचे है।

— बेन सबकानी - सोनासी
स्रोत

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

— जेडब्ल्यू।

1

@JW। - डार लिंक रॉट। मैंने लिंक अपडेट किया है।

— बेन लेसानी - सोनासी

30

आप उस क्लस्टर कॉन्फ़िगरेशन के साथ एक महान पथ पर हैं। मैं रेडिस के लिए एक समर्पित कैश होस्ट जोड़ने की सलाह देता हूं; उच्च CPU शक्ति और RAM (~ 64 GB) के साथ एक का चयन करें।

यहाँ उन विन्यासों की पूरी सूची दी गई है, जिनका उपयोग मैंने LEMP क्लस्टर के लिए अत्यधिक उपलब्ध, दोष सहिष्णु, वितरित और लोड किया है। यह भी शामिल है app/etc/local.xml, core_config_dataमेज, और MySQL, php-एफ पी एम, nginx, और Redis के लिए विन्यास। सभी Ubuntu 12.04 LTS 64-बिट चलाते हैं। कॉन्फ़िगरेशन में कमियां के बिना बहुत सारे अनुकूलन शामिल हैं।

हाइलाइट

व्यवस्थापक उपयोगकर्ता: 46
श्रेणियाँ: 2,450 (सबसे बड़े में 2,400 उत्पाद हैं)
उत्पाद इकाइयाँ: 101,000
कॉम्बो उत्पाद: 484
उत्पाद संबंध: 54,000
स्टॉक और सक्षम विन्यास योग्य उत्पादों में: 10,100
सीएमएस ब्लॉक: 3,100
सीएमएस पृष्ठ: 1,400

अगस्त 2013 यातायात:

40 मिलियन मासिक पेजव्यू
2.3 मिलियन अद्वितीय आगंतुक
46,000 मासिक चेकआउट
संयुक्त राज्य अमेरिका से 89% आगंतुक

वेब होस्ट

बेमानी, अत्यधिक उपलब्ध हार्डवेयर फायरवॉल और हार्डवेयर लोड बैलेंसरों के पीछे 10 मेजबान हैं। अधिकांश स्थैतिक संपत्ति एक सीडीएन से भरी हुई हैं।

साइट-वाइड औसत प्रतिक्रिया समय: 282 एमएस
औसत एफपीसी प्रतिक्रिया: 48 एमएस
लोड औसत: 0.6 से 1.0 (परीक्षणों में, प्रदर्शन में 35% की गिरावट जब लोड औसत हिट ~ 5.0)
दोहरी इंटेल Xeon CPU E3-1230 V2 @ 3.30GHz (प्रत्येक 4 कोर)
32 जीबी डीडीआर 3 1333 मेगाहर्ट्ज रैम

मॉड्यूल

https://github.com/colinmollenhour/Cm_RedisSession
https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
https://github.com/aligent/CacheObserver.git --branch = मॉडल
https://github.com/aligent/Lokey_ShippingAdjustments
https://github.com/aligent/VF_CustomMenu.git --branch = उत्पादन
https://github.com/Vinai/customer-activation
https://github.com/gknoppe-guidance/magento-cachebuster

कैश होस्ट करता है

स्वचालित फेलओवर के साथ मास्टर-स्लेव कॉन्फ़िगरेशन में रेडिस चलाने वाले दो होस्ट हैं। तीन रेडिस इंस्टेंस (सत्र, बैकएंड और एफपीसी) का उपयोग थ्रूपुट को बढ़ाने और दृढ़ता व्यवहार के ठीक-ठीक ट्यूनिंग प्रदान करने के लिए किया जाता है।

प्रति सेकंड 3,000 कमांड
0.7 एमएस औसत प्रतिक्रिया समय
लोड औसत 1.0 से 1.5
Quad Intel Xeon CPU E5-2620 0 @ 2.00GHz (6 कोर प्रत्येक)
128 जीबी बफर DDR3 1333 मेगाहर्ट्ज रैम
मैकेनिकल डिस्क, RAID 1, हार्डवेयर नियंत्रक

डेटाबेस होस्ट करता है

गर्म असफलता के साथ मास्टर-गुलाम कॉन्फ़िगरेशन में MySQL 5.6.11 चलाने वाले दो होस्ट हैं।

प्रति सेकंड 1,500 कमांड
1.1 एमएस औसत प्रतिक्रिया समय
लोड औसत 0.1 (मास्टर) और 0.4 (दास)
Quad Intel Xeon CPU E7- 2860 @ 2.27GHz (10 कोर प्रत्येक)
128 जीबी बफर DDR3 1333 मेगाहर्ट्ज रैम
SSD, RAID 1 + 0, हार्डवेयर नियंत्रक
Tcmalloc के साथ MySQL 5.6.11

— parhamr
स्रोत

रेडिस सिंगल-थ्रेडेड होने के नाते आपका कैश क्वाड-हेक्सा-कोर सीपीयू के साथ थोड़ा अधिक संचालित नहीं है? इसके अलावा, आपका लोड लोड औसत मास्टर लोड औसत से अधिक क्यों है?

— कॉलिनम

@ कोलिनम: मैंने सर्वर नहीं खरीदा; हाँ, यह संचालित है! मैगेंटो रीड कनेक्शन के लिए दास का उपयोग किया जाता है, इसलिए यह न केवल मास्टर के लेखन के साथ रख रहा है, बल्कि बहुत सारे पढ़े हुए थ्रेड्स भी परोस रहा है।

— परमहर

4

मैगेंटो के लिए एक और सर्वर टिप होना चाहिए ओपचे के साथ PHP 5.4 या 5.5 स्थापित कर रहा है । PHP 5.4 5.3 ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ) की तुलना में बहुत अधिक तेज है ।

— kuba_ceg
स्रोत

0

मैं एक और महत्वपूर्ण टिप जोड़ना चाहता हूं जो वार्निश द्वारा कैश नहीं किए जाने पर मैग्नेटो पेज की गति में सुधार करता है और डिफ़ॉल्ट रूप से सक्षम नहीं होता है (कार्ट पेज लोड समय 6sc से 1.5sc में बदल जाता है)।

/Etc/mysql/my.conf में mysql क्वेरी कैश सक्रिय करें

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

cache_type इसे सक्षम करें, कैश आकार मेमोरी में कैश द्वारा उपयोग किया जाने वाला मूल्य है और कैश सीमा कैश के लिए क्वेरी परिणाम का अधिकतम आकार है

— Choussamaster
स्रोत

-2

हमारे वर्तमान कॉन्फ़िगरेशन के साथ हम 400 एमएस में प्रारंभिक प्रतिक्रिया प्राप्त कर रहे हैं और दस्तावेज़ 2 सेकंड में पूरा हो गया है (5mbps के मानक कनेक्शन का उपयोग करके)। हमारे होमपेज का आकार 1mb है।

हमारा सेटअप निम्नानुसार AWS पर आधारित है: हमारे पास R2 डेटाबेस से जुड़े लोड बैलेंसर (फेलओवर के साथ) के साथ एक ec2 उदाहरण है। हमने कैश स्टोरेज और सेशन स्टोरेज के लिए रेडिस कैश बैकएंड के साथ फुल पेज कैश भी लागू किया है।

औसतन हमारे पास प्रतिदिन 300 - 400 आगंतुक आते हैं, लेकिन रेडिस कैशिंग सक्षम होने के साथ-साथ गति बनाए रखने और लागत में कमी लाने के दौरान हमारे पास न्यूनतम पारिस्थितिक संसाधन उपयोग है।

हमारे पास लोड बैलेंसर होने का कारण यह है कि Ec2 एक नए उदाहरण को स्वचालित रूप से बूट करने के लिए सेटअप है यदि दुर्लभ अवसर पर हमारे पास ट्रैफ़िक स्पाइक्स हैं जो वर्तमान सेटअप को संभाल नहीं सकता है।

— razorgamez
स्रोत

बस एडब्ल्यूएस में एक इलास्टिक लोड बैलेंसर का उपयोग करने के लाभों को जोड़ने के लिए - आप इसके साथ अपने एसएसएल कनेक्शन को लोड कर सकते हैं और ओपनएसएसएल भेद्यता पैच के ढेरों के बारे में चिंता करने की ज़रूरत नहीं है जो आपको अपने ईसी 2 सत्रों पर लगातार लागू करना होगा यदि आप प्रबंधन करते हैं यह स्वयं

— रोबी एवेरिल