मैंने हाल ही में उन परिदृश्यों के बारे में सीखा है जिन्हें वास्तविक अनुरोधों की सेवा शुरू करने से पहले एक ऐप (उच्च थ्रूपुट आवश्यकता के साथ) को गर्म करने की आवश्यकता होती है। इसके पीछे तर्क जीआईटी को अपना प्रदर्शन जादू करने की इजाजत देना था!उच्च थ्रूपुट जावा ऐप्स को गर्म करना
क्या यह जावा ऐप्स के लिए मानक है या यह आमतौर पर मेमोरी भारी (पदचिह्न) ऐप्स के लिए किया जाता है?
यदि आप एक उच्च यातायात वेबपैप/वेबसाइट के बारे में बात कर रहे हैं तो जेआईटी एक मामूली मुद्दा है। सबसे बड़ी समस्या उन सभी कैश परतों को गर्म करने (पॉप्युलेटिंग) कर रही है, जिनकी आपको आवश्यकता होगी। उदा। ehcache regions which are being populated from hibernate। ऐसा इसलिए है क्योंकि आईओ संबंधित कार्यों के लिए कुछ भी की तुलना में धीमी परिमाण कि सीपीयू (जो है अंदर होता है के आदेश हैं जब तक आप की गणना के भग्न :)
+1 "जब तक आप फ्रैक्टल की गणना नहीं कर रहे हैं"। – z5h
सूचक के लिए धन्यवाद लेकिन मुझे लगता है कि मैं "महंगा" डेटा के बजाय कोड पथ को गर्म करने का जिक्र कर रहा था। मैं विशेष रूप से सोच रहा था कि क्या बड़े जावा ऐप्स को पूर्व-गर्म करने के लिए यह समझ में आता है कि विशेष रूप से JVMs यह तय करने के लिए पर्याप्त स्मार्ट हैं कि कोड कोड कितना उपयोग किया जाता है और इसलिए उनके लिए जेआईटी कैश करने के लिए। निश्चित रूप से एक है पर्फ़। पहली बार जेआईटीिंग करते समय मारा और इसलिए मैं जानना चाहता था कि वास्तविक जीवन में किसी को इस मुद्दे का सामना करना पड़ा है जो उन्हें अपने ऐप्स को गर्म करने के लिए प्रोत्साहित करता और यदि ऐसा है तो क्या परफ। उन्होंने देखा है सुधार। –
@ आयुष पुरी: और मेरा जवाब यह था कि यदि आप वेबएप के बारे में बात कर रहे हैं तो वास्तविक जीवन में (और वेबपैप्स के संदर्भ में) में जेआईटी गर्मजोशी 0.01% महत्वपूर्ण है) हर किसी को हल करने में बड़ी समस्याएं होती हैं (डेटाबेस, कैश आदि के लिए गर्मजोशी) – cherouvim
सवाल यह है कि कर रहे हैं, जब आप अपने रास्ते से बाहर जाने के लिए ऐसा करना चाहते हैं ?
यदि आप कोई वेबपैप रोल करते हैं, और यह तुरंत रहता है, तो जब आप इसे "वार्मिंग" कर रहे हैं, तो आप अतिरिक्त लोड जोड़ रहे हैं, जो काउंटर-उत्पादक है। डेस्कटॉप ऐप शुरू होने पर भी यही सच है। अगर उपयोगकर्ता तुरंत इसका उपयोग शुरू करने जा रहा है तो वार्मिंग में कोई बात नहीं है। या इससे भी बदतर, जब आप ऐप को गर्म कर रहे हों तो उपयोगकर्ता को बातचीत करने की इजाजत नहीं दी गई।
यदि आप कोई वेबपैप रोल करते हैं, और आप अपने लोड बैलेंसर्स को इंगित करने से पहले तैनाती का परीक्षण करते हैं, तो आप इसे पहले से ही एक साइड परिणाम के रूप में गर्म कर चुके हैं।
व्यक्तिगत रूप से, _I_ प्रदर्शन परीक्षण करते समय ऐसा करने के लिए मेरे रास्ते से बाहर निकल जाएगा। या जब मेरे पास क्लस्टर होता है, और क्लस्टर में प्लग करने से पहले मशीन को गर्म करना उपयोगकर्ताओं को प्रभावित नहीं करता है। –
लेकिन अगर आपके उत्पादन वातावरण में वार्मिंग का लाभ नहीं है, तो आप प्रदर्शन परीक्षण वातावरण में गर्म होने से अपने प्रदर्शन परीक्षण परिणामों को क्यों छोड़ना चाहेंगे? – zkarthik
मैं पूरी तरह से सहमत हूं कि इसे केवल आपके लोड बैलेंसर में जोड़ने से पहले एक ऐप को गर्म करने का अर्थ होता है। –
cherouvim's answer के अलावा, मैं कुछ अन्य मुद्दों कि वार्म अप की आवश्यकता होती है के बारे में सोच सकते हैं:
Xms आपके Xmx से छोटा है)।मुझे कल्पना है कि ओएस स्वयं को एप्लिकेशन के व्यवहार में भी जोड़ता है, ताकि ओएस कॉल भी गर्म अवधि से प्रभावित हो सकें।
उपरोक्त में से अधिकांश (कैश जनसंख्या, ऑब्जेक्ट प्रारंभिक) जावा के लिए विशिष्ट नहीं हैं।
+1: फ़ाइल कैश की ओएस आबादी एक बड़ा कारक हो सकता है। – erickson
> ढेर आवंटन (यदि आपका एक्सएमएस आपके एक्सएमएक्स से छोटा है)। अच्छा बिंदु। और मेरा मानना है कि यही कारण है कि एक्सएमएक्स = एक्सएमएस सेट करने के लिए कहा जाता है –
प्रदर्शन ट्यूनिंग ** आपके ** विशिष्ट परिदृश्यों में खुशी के आकलन और विश्लेषण के मुकाबले "परिदृश्यों के बारे में सीखना" के बारे में कम है। – flybywire
मेरा प्रश्न भी देखें: http://stackoverflow.com/questions/1481853/technique-or-utility-to-minimize-java-warm-up-time – noahlz