👇🏻 🧓🏾 📃 जावा न केवल खूनी उद्यम है, बल्कि तेजी से विलंबता-संवेदनशील अनुप्रयोग भी है 🌤️ 👒 🥕

मैं Raiffeisenbank में एल्गोरिथम ट्रेडिंग करता हूं। यह बैंकिंग क्षेत्र का एक विशिष्ट क्षेत्र है। हम एक ट्रेडिंग प्लेटफॉर्म बनाते हैं जो कम और अनुमानित देरी के साथ काम करता है। एप्लिकेशन की सफलता निर्भर करती है, एप्लिकेशन की गति पर, अन्य बातों के साथ, इसलिए हमें ट्रेडिंग में शामिल पूरे स्टैक से निपटना होगा: निजी नेटवर्क चैनल, विशेष हार्डवेयर, ओएस सेटिंग्स और एक विशेष जेवीएम, और, ज़ाहिर है, आवेदन ही। हम स्वयं ही विशेष रूप से एप्लिकेशन के अनुकूलन को रोक नहीं सकते हैं - ओएस या नेटवर्क सेटिंग्स समान रूप से महत्वपूर्ण हैं। यह समझने के लिए तकनीकी विशेषज्ञता और क्षरण की आवश्यकता है कि डेटा पूरे स्टैक से कैसे बहता है, और जहां देरी हो सकती है।

प्रत्येक संगठन / बैंक सॉफ्टवेयर के इस वर्ग के विकास का खर्च नहीं उठा सकते हैं। लेकिन मैं भाग्यशाली था कि इस तरह की परियोजना को रायफेनबैंक की दीवारों के भीतर लॉन्च किया गया था, और मेरे पास एक उपयुक्त विशेषज्ञता थी - मैं इंटेल मॉस्को कंपाइलर प्रयोगशाला में कोड प्रदर्शन में विशिष्ट था। हमने C, C ++ और फोरट्रान के लिए कंपाइलर बनाए। Raiffeisenbank में, मैं जावा में बदल गया। यदि पहले मैंने किसी तरह का उपकरण बनाया था, जिसका उपयोग कई लोग करते थे, तो अब मैं बैरिकेड्स के दूसरी ओर चला गया हूं और न केवल कोड के प्रदर्शन, बल्कि संपूर्ण एप्लिकेशन स्टैक के अनुप्रयुक्त विश्लेषण में लगा हुआ हूं। नियमित रूप से, प्रदर्शन समस्या का अनुसंधान करने का तरीका कोड से परे है, उदाहरण के लिए, कर्नेल या नेटवर्क सेटिंग्स में।

जावा हाईलोड के लिए नहीं है?

यह व्यापक रूप से माना जाता है कि जावा अत्यधिक लोड सिस्टम के विकास के लिए बहुत उपयुक्त नहीं है।
यह केवल आंशिक रूप से सहमत हो सकता है। जावा कई पहलुओं में सुंदर है। अगर हम इसकी तुलना C ++ जैसी भाषा से करते हैं, तो इसका संभावित ओवरहेड अधिक हो सकता है, लेकिन कभी-कभी C ++ में समान रूप से समान समाधान धीरे-धीरे काम कर सकते हैं। ऐसे अनुकूलन हैं जो स्वचालित रूप से जावा में काम करते हैं, लेकिन सी ++ में काम नहीं करते हैं, और इसके विपरीत। जावा जेआईटी संकलक के बाद आने वाले कोड की गुणवत्ता को देखते हुए, मैं विश्वास करना चाहता हूं कि प्रदर्शन उस चीज से नीच होगा जो मैं चोटी पर हासिल कर सकता था, कई बार से अधिक नहीं। लेकिन एक ही समय में मुझे बहुत तेजी से विकास, उत्कृष्ट उपकरण और ऑफ-द-शेल्फ घटकों का विस्तृत चयन मिलता है।

आइए इसका सामना करते हैं: C ++ दुनिया में, IntelliJ और Eclipse के पीछे विकास वातावरण (IDE) महत्वपूर्ण हैं। यदि कोई डेवलपर इनमें से किसी भी वातावरण का उपयोग करता है, तो डिबगिंग गति, बग ढूंढना और जटिल तर्क लिखना उच्च परिमाण का एक आदेश है। नतीजतन, यह पता चला है कि जावा को सही स्थानों पर दर्ज करना आसान है ताकि यह खरोंच से सब कुछ करने के लिए और सी ++ में बहुत लंबे समय तक तेजी से काम करे। सबसे मजेदार बात यह है कि प्रतिस्पर्धी कोड लिखते समय, जावा और सी ++ दोनों में सिंक्रोनाइज़ेशन के दृष्टिकोण बहुत समान हैं: वे या तो ओएस-स्तर के आदिम हैं (उदाहरण के लिए, सिंक्रनाइज़ / एसटी :: म्यूटेक्स ) या लोहे के आदिम ( परमाणु * / एसटी :: परमाणु <*> ) । और इस समानता को देखना बहुत महत्वपूर्ण है।

सामान्य तौर पर, हम एक गैर-हाईलोड एप्लिकेशन विकसित कर रहे हैं))

हाईलोड और कम विलंबता अनुप्रयोग के बीच अंतर क्या है?

हाईलोड शब्द हमारे काम की बारीकियों को पूरी तरह से प्रतिबिंबित नहीं करता है - हम विलंबता-संवेदी प्रणालियों में लगे हुए हैं। अंतर क्या है? अत्यधिक भरी हुई प्रणालियों के लिए, हार्डवेयर संसाधनों का पूर्ण उपयोग करते हुए, औसतन बहुत तेज़ी से काम करना महत्वपूर्ण है। व्यवहार में, इसका मतलब है कि सिस्टम के लिए हर सौवां / हज़ारवां /../ मिलियन मिलियन अनुरोध संभावित रूप से बहुत धीरे-धीरे काम कर सकते हैं, क्योंकि हम औसत मूल्यों पर ध्यान केंद्रित करते हैं और हमेशा यह ध्यान नहीं रखते हैं कि हमारे उपयोगकर्ता ब्रेक से काफी पीड़ित हैं।

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

कम से कम डेटा संरचनाएं लें। हम हैश तालिकाओं का उपयोग करते हैं, और यदि संपूर्ण डेटा संरचना का पुन: हैश महत्वपूर्ण पथ पर होता है, तो यह किसी विशेष उपयोगकर्ता के लिए एकल अनुरोध पर मूर्त ब्रेक को जन्म दे सकता है। या जेआईटी कंपाइलर - सबसे अधिक बार निष्पादित कोड पैटर्न का अनुकूलन करता है, शायद ही कभी निष्पादित कोड पैटर्न को pessimizing। लेकिन इस विशेष दुर्लभ मामले की गति हमारे लिए बहुत महत्वपूर्ण हो सकती है!

शायद यह कोड एक दुर्लभ प्रकार के आदेशों को संसाधित करता है? या कुछ असामान्य बाजार की स्थिति जो एक त्वरित प्रतिक्रिया की आवश्यकता है? हम यह सुनिश्चित करने की कोशिश करते हैं कि इन संभावित दुर्लभ घटनाओं के लिए हमारी प्रणाली की प्रतिक्रिया कुछ अनुमानित और, अधिमानतः, बहुत कम समय लेती है।

एक पूर्वानुमान प्रतिक्रिया समय कैसे प्राप्त करें?

इस प्रश्न का उत्तर दो वाक्यांशों में नहीं दिया जा सकता है। पहले सन्निकटन में, यह समझना महत्वपूर्ण है कि क्या किसी प्रकार का सिंक्रोनाइज़ेशन है - सिंक्रोनाइज़्ड, रीक्रेंट्रलॉक या java.util.concurrent से कुछ। अक्सर आपको व्यस्त-स्पिन'ह पर सिंक्रनाइज़ेशन का उपयोग करना पड़ता है। किसी भी तुल्यकालन का उपयोग करना आदिम हमेशा एक समझौता है। और यह समझना महत्वपूर्ण है कि ये सिंक्रोनाइज़ेशन प्राइमेटिव कैसे काम करते हैं और वे किस ट्रेड-ऑफ को लेकर चलते हैं। यह मूल्यांकन करना भी महत्वपूर्ण है कि किसी विशेष कोड का कचरा कितना उत्पन्न होता है। कचरा संग्रहकर्ता से निपटने का सबसे अच्छा तरीका यह है कि इसे ट्रिगर न किया जाए। जितना कम हम कचरा पैदा करेंगे, उतनी बार हम एक कचरा संग्रहकर्ता को चलाएंगे, और यह प्रणाली लंबे समय तक उसके हस्तक्षेप के बिना काम करेगी।

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

क्या मैं असुरक्षित हटा सकता हूं?

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

परोक्ष रूप से, मेरी राय में असुरक्षित से तरीकों को हटाने की बहुत साफ-साफ पुष्टि की गई है - जावा 11 में असुरक्षित से सबसे बेकार तरीकों को हटा दिया गया। मुझे लगता है कि जब तक असुरक्षित परियोजनाओं का उपयोग करने वाले सभी प्रोजेक्ट्स में से कम से कम आधा कुछ और नहीं होगा, तब तक Unsafe एक या दूसरे रूप में उपलब्ध होगा।

एक राय है: बैंक + जावा = खूनी ossified उद्यम?

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

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

एक बात और

मुझे लगता है कि सभी डेवलपर्स के लिए यह जानना बहुत महत्वपूर्ण है कि कैसे, यदि पूरे स्टैक नहीं हैं, तो इसका कम से कम आधा काम करता है: जावा कोड, बाइट कोड, आंतरिक मशीन रनटाइम और कोडांतरक के हार्डवेयर, ओएस, नेटवर्क। यह समस्याओं को व्यापक रूप से देखने की अनुमति देता है।
प्रदर्शन भी ध्यान देने योग्य है। औसत पर ध्यान केंद्रित नहीं करना बहुत महत्वपूर्ण है और हमेशा औसत और उच्च प्रतिशत (10/100/1000 / माप के सबसे खराब) को देखें।

मैं सेंट पीटर्सबर्ग में 30 मई को जावा उपयोगकर्ता समूह की बैठक में यह सब बात करूंगा। सर्गेई मेलनिकोव के साथ बैठक, यह सिर्फ मेरे लिए है)) आप यहां पंजीकरण कर सकते हैं ।

हम किस बारे में बात करने जा रहे हैं?

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

बैठक में आओ, यह एक शानदार शाम होगी, हमारे मंच के बारे में और हमारी पसंदीदा भाषा के बारे में कई दिलचस्प कहानियां होंगी।

बाद में मिलते हैं;)