GWT - संचरित डेटा में झांकना

GWT एक बेहतरीन ढांचा है। मैं एक जावा डेवलपर हूं और मैंने JSP, JSF और GWT का उपयोग करके पतले क्लाइंट के साथ काम किया है। जेएसपी के बारे में कहने के लिए कुछ खास नहीं है, तकनीक अब लगभग समाप्त हो गई है, लेकिन जेएसएफ में मुझे दो परियोजनाओं पर दो साल तक खाना बनाना पड़ा, और इसे हल्का करने के लिए मेरे इंप्रेशन, सबसे अच्छे नहीं हैं: जेएसटीएल, एचटीएमएल, जावास्क्रिप्ट और अन्य चीजों की गड़बड़ी एक अकथनीय "खुशी" देती है। किसी जटिल पृष्ठ के अतुलनीय व्यवहार के विश्लेषण के क्षणों में परमानंद करना। हां, उदाहरणों में सब कुछ साफ-सुथरा और सरल दिखता है, लेकिन वास्तविक जीवन ऐसा नहीं है, और परियोजना के JSF- पृष्ठ आकार में भी मध्यम हैं और टेम्प्लेट का उपयोग करते हुए डिजाइन करने के लिए एक सक्षम इत्मीनान से दृष्टिकोण के साथ प्रतीत होता है, यह अभी भी "गंध" के लिए शुरू होता है, विशेष रूप से भाग में पठनीयता। GWT में, सब कुछ काफी साफ-सुथरा है, क्योंकि हम अपनी मूल जावा भाषा में लिखते हैं, भले ही एक स्ट्रिप-डाउन संस्करण में, लेकिन यह पर्याप्त से अधिक है।

अगर हम इस तथ्य के बारे में बात करते हैं कि जीडब्ल्यूटी में क्लाइंट पर बड़ी जावास्क्रिप्ट फाइलें भरी हुई हैं, तो यहां मेरी राय है। GWT में, पहली बार जब कोई क्लाइंट लॉग इन करता है, तो तर्क लोड किया जाता है, भले ही वह बहुत अधिक हो, लेकिन केवल एक बार। डाउनलोड के बाद, क्लाइंट और सर्वर के बीच केवल शुद्ध व्यापार तर्क डेटा बहता है। विशेष रूप से, मेरे पास पहले 3MB डाउनलोड है, फिर AJAX अनुरोध / प्रतिक्रिया करता है, यह वास्तव में इस बात पर निर्भर करता है कि आपके पास किस तरह का डेटा है। जेएसएफ में, किसी भी पृष्ठ पर प्रवेश करने पर, ब्राउज़र में डेटा और इंटरफ़ेस का वर्णन होता है जिसमें वे प्रदर्शित होते हैं। ज्यादातर मामलों में, इंटरफ़ेस विवरण (html) का आकार स्वयं डेटा के आकार से कई गुना बड़ा है। क्लाइंट पर 1KB डेटा दिखाने के लिए (तालिका की कई पंक्तियाँ, उदाहरण के लिए), आपको HTML के 15-30 kB को ब्राउज़र में स्थानांतरित करना होगा (हम मानते हैं कि चित्र और स्क्रिप्ट कैश्ड हैं)। लेकिन पृष्ठ पर डेटा आमतौर पर बहुत अधिक होता है: शीर्षक, मेनू, विभिन्न ब्लॉक आदि। वास्तव में, डेटा और कार्यक्षमता के साथ काफी संतृप्त एक पृष्ठ का वजन आमतौर पर कम से कम 100-200 kB होता है। GWT, एक ही पृष्ठ को प्रदर्शित करने के लिए, सर्वर से 1 kB डेटा लेगा और वह यह है। यदि उपयोगकर्ता नियमित हैं और लंबे समय से साइट पर हैं, तो प्राथमिक 3 एमबी के नुकसान की भरपाई आधे घंटे के लिए की जाती है। इसे ध्यान में रखते हुए, GWT नौकरियों के कार्यान्वयन के लिए आदर्श है, लेकिन नियमित साइटों के लिए, यह इतना अच्छा नहीं हो सकता है।

किसी भी मामले में, यह चर्चा के तहत विषय में एक छोटे से "डुबकी" के लिए एक परिचय है, और लेख प्रौद्योगिकियों की तुलना करने के बारे में नहीं है, लेकिन ब्राउज़र और सर्वर के बीच जाने वाले डेटा पर जासूसी कैसे समस्याओं को सुलझाने और अनुकूलन में मदद कर सकती है। क्लाइंट-सर्वर इंटरैक्शन। लेखन के समय, हमने पहले से ही पुराने जीडब्ल्यूटी 1.5 का उपयोग किया था, और डीटीओ के हस्तांतरण के लिए, उतना ही पुराना और अब समर्थित गिलाद पुस्तकालय नहीं था। मेरी योजना GWT के नवीनतम संस्करण में अपग्रेड करने और GWT- शर्मी RequestFactory के पक्ष में गिलियड को छोड़ने की है। तकनीक के बावजूद, उपकरण और डिबगिंग के तरीके समान हैं। मैं FireBug प्लगइन स्थापित FireFox का उपयोग किया।

हमें स्मृति रिसाव कैसे मिला

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

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

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

नेटवर्क ट्रैफिक और मेमोरी को कैसे बचाएं

आलसी मत बनो, और फायरबग में देखने के लिए कुछ घंटों का समय बिताओ जो सर्वर और वापस स्थानांतरित किया गया है, आप दिलचस्प चीजें पा सकते हैं। एक विशिष्ट उदाहरण: एक क्लाइंट (ब्राउज़र) सर्वर से समय-समय पर सूचनाएं मांगता है। वास्तव में, आपको एक सूची प्राप्त करने के लिए, जो अनुरोध किया गया था, उसके बारे में सर्वर डेटा में स्थानांतरित करने की आवश्यकता है। हमारे पास ग्राहक पर संग्रहीत एक उपयोगकर्ता ऑब्जेक्ट है, जिसमें विभिन्न सूची डेटा सहित इसके बारे में बहुत सारी जानकारी है। इसलिए, सर्वर से डेटा का अनुरोध करने का तरीका बस लागू किया गया था - संपूर्ण उपयोगकर्ता ऑब्जेक्ट पारित हो गया है। कई अन्य तरीकों को भी उसी तरह से लागू किया जाता है। डिबगिंग के तहत देखने के बाद, मैंने देखा कि स्ट्रिंग में क्रमबद्ध और उपयोगकर्ता सर्वर पर स्थानांतरित किया गया आकार 15kB है। लेकिन उपयोगकर्ता सत्र कैश में सर्वर पर इस ऑब्जेक्ट की एक प्रति है, और विधि द्वारा अनुरोधित डेटा प्राप्त करने के लिए, उपयोगकर्ता आईडी आमतौर पर पर्याप्त है। यदि आप उपयोगकर्ता ऑब्जेक्ट को उसकी आईडी के साथ विधि में प्रतिस्थापित करते हैं, तो अनुरोध का आकार 15kB से घटाकर 50-100 बाइट्स किया जा सकता है, या यहां तक ​​कि बिना मापदंडों के विधि को कॉल कर सकते हैं, और वर्तमान सत्र से उपयोगकर्ता की जानकारी ले सकते हैं।

ऐसा लगता था कि आधुनिक नेटवर्क के बुनियादी ढांचे के लिए 15kB? धूल! लेकिन हमें यह नहीं भूलना चाहिए कि कई अनुरोध हैं, और सिस्टम में उपयोगकर्ता अकेला नहीं है। इसके अलावा, नेटवर्क संसाधनों के अलावा, सर्वर प्राप्त 15kB को जावा उपयोगकर्ता ऑब्जेक्ट में बदलने के लिए प्रोसेसर और मेमोरी संसाधनों का उपभोग करता है, जिसमें से अनुरोध के लिए आईडी को गर्व से बाहर निकाला जाएगा, और बाकी सब कुछ कचरा कलेक्टर को छोड़ दिया जाएगा।

मैंने लोड परीक्षण कैसे किया

जब हमने तकनीक को अपडेट करते समय सर्वर को क्रैश करना शुरू कर दिया, तो समस्या के स्रोत का पता लगाने का एक प्रयास लोड परीक्षण का संचालन करना था। मुफ्त उपयोगिताओं और सॉफ्टवेयर पुस्तकालयों की त्वरित खोज और देखने से परीक्षण वातावरण बनाने में मदद नहीं मिली, इसलिए मैंने अपने दम पर कुछ सरल लिखने की कोशिश करने का फैसला किया। GWT सर्वर को भेजने वाले सभी HTTP अनुरोध हैं, जिसका अर्थ है कि आप मानक जावा भाषा टूल का उपयोग करके उनका अनुकरण करने का प्रयास कर सकते हैं। केवल यहां, अनुरोधों में वास्तव में क्या प्रसारित करना है? फिर से, फायरबग बचाव के लिए आया था। हम ग्राहक के हिस्से में जाते हैं, कोई भी कार्य करते हैं, FireBug में हम POST अनुरोधों की सामग्री लेते हैं। तनाव परीक्षण के लिए स्व-लिखित उपयोगिता बहुत छोटी और काफी कार्यात्मक थी। एक निश्चित उपयोगकर्ता ऑब्जेक्ट क्रियाओं का दोहराव सेट करता है, अर्थात HTTP अनुरोध भेजना। कई दसियों / सैकड़ों ऐसी वस्तुओं को विभिन्न थ्रेड्स में लॉन्च किया जाता है और सर्वर पर एक सभ्य भार दिया जाता है। अभी मैं JBoss 7 पर स्विच करने के बाद जांच के लिए सिस्टम लोड के तहत परीक्षण कर रहा हूं: प्रोसेसर संसाधन 90% सर्वर द्वारा उपयोग किए जाते हैं, रात के दौरान 500 एमबी मेमोरी की खपत होती है, क्लाइंट भाग में प्रवेश करते समय ध्यान देने योग्य "मंदी" होती है, जिसका मतलब है कि लोड अच्छा है!

निष्कर्ष

उपरोक्त सभी न केवल GWT पर लागू होता है, बल्कि किसी भी पतले क्लाइंट के लिए भी लागू होता है: डिबगिंग के तहत देखें कि सर्वर और क्लाइंट के बीच क्या होता है। यह न केवल बाधाओं / समस्या क्षेत्रों के संकेत दे सकता है, बल्कि उपयोग की जाने वाली प्रौद्योगिकियों के सार को बेहतर ढंग से समझने में भी मदद करता है।