मैंने इसे पहले एक क्लाइंट के साथ देखा है जिसने मुझे कुछ आपातकालीन सहायता के लिए बुलाया था।
heroku bash . के साथ कुछ ताक-झांक करने के बाद हमने अंततः निष्कर्ष निकाला कि नया उदाहरण विशेष रूप से व्यस्त अंतर्निहित सर्वर पर था। हमने एक अन्य मशीन के लिए अनुयायी पदोन्नति के माध्यम से एक फेलओवर किया, जिस बिंदु पर प्रदर्शन में काफी सुधार हुआ - हालांकि मास्टर के साथ समस्याओं के कारण फेलओवर स्वयं चुनौतीपूर्ण था।
जहां तक मुझे पता है कि हेरोकू के उदाहरण अमेज़ॅन ईसी 2 नोड्स (एक्सएन वीएम) हैं जो प्रत्येक हेरोकू उपयोगकर्ता के डेटाबेस क्लस्टर को अलग करने के लिए एक एलएक्ससी कंटेनर चलाते हैं। एलएक्ससी एक पूर्ण वीएम की तुलना में कम अलगाव प्रदान करता है; ओपनसीजेड के साथ कॉन्फ़िगर की गई सटीक नीति, किसी भी नियंत्रण समूह नीतियों, आदि के आधार पर इंस्टेंस रैम, डिस्क I/O, CPU, आदि के लिए संघर्ष कर सकते हैं।
यदि आप ऐसे उदाहरण पर हैं जहां अन्य उपयोगकर्ता बहुत कुछ नहीं कर रहे हैं और यदि कंटेनर आपके डीबी को उन संसाधनों का उपयोग करने की अनुमति देता है जो वर्तमान में अन्य उपयोगकर्ताओं द्वारा आवश्यक नहीं हैं, तो आप आसानी से गारंटीकृत प्रदर्शन से लगातार उच्च देख सकते हैं।
मुझे संदेह है कि बड़ी हेरोकू योजनाओं पर लोग वास्तव में उस सिस्टम के संसाधनों का उपयोग कर रहे हैं जिसके साथ आप एक कंटेनर साझा कर रहे हैं।
यदि आप एक बड़े उदाहरण के लिए प्रचार विफलता करते हैं जहां सभी उपयोगकर्ता वहां हैं क्योंकि उन्हें वास्तव में बड़ी मशीन द्वारा पेश किए गए संसाधनों की आवश्यकता है तो आप वास्तव में कम प्राप्त कर सकते हैं कुल मिलाकर संसाधन, क्योंकि हर कोई वास्तव में अपने शेयरों का उपयोग कर रहा है।
यह निराशाजनक है कि हेरोकू अपने डीबी चलाने वाले सिस्टम में इतनी कम दृश्यता प्रदान करता है। यह बताना मुश्किल है कि कैसे/अगर वे कंटेनर होस्ट के बीच संतुलन लोड करते हैं, सिस्टम पर अंतर्निहित लोड क्या है, आदि।
एक टिप्पणी में, @Forrest ने बताया कि Heroku के पास एक उपयोगी उनके सर्वर विवरण पर पृष्ठ , यह दर्शाता है कि केवल निचले स्तर बहु-किरायेदार हैं, लेकिन उच्च स्तरीय नहीं हैं। यह आसानी से यहां देखे गए प्रदर्शन हानि की व्याख्या करेगा, और ऊपर मेरी टिप्पणियों के साथ फिट होगा कि निचली योजना फॉरेस्ट को अन्य उपयोगकर्ताओं से अप्रयुक्त संसाधनों को उधार लेने की अनुमति दे रही थी।
