🖖 👩‍🚒 ✋🏼 जावा क्लाउड में वर्टिकल स्केलिंग 🙇 🔊 👩🏼‍🏫

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

सर्वर कार्यान्वयन

सत्र में प्रत्येक नए उपयोगकर्ता को 10 एमबी आकार के बाइट्स की एक सरणी दी जाती है।

<html> <body> <h1>Hello!</h1> <% byte[] data = (byte[]) session.getAttribute("test-data"); if (data == null) data = new byte[1024 * 1024 * 10]; request.getSession().setAttribute("test-data", data); %> Your session ID <%=session.getId()%><br/> Your session data size <%=data.length%> bytes<br/> </body> </html>

ग्राहक का आगमन

ग्राफ ग्राहकों की तीन तरंगों को दिखाता है - क्रमशः 100, 300 और 1000।

100 ग्राहकों की पहली लहर (एक समय में 1 स्ट्रीम में) लगभग ~ 1.3 जीबी की खपत करती है। उसके बाद सत्रों (10 मिनट) का समय समाप्त होता है == उपयोगकर्ता सत्रों का सारा डेटा अनलोड किया जाता है और मेमोरी को प्लेटफॉर्म पर लौटा दिया जाता है।
300 ग्राहकों की दूसरी लहर (10 धाराओं में) ~ 3.5 जीबी। फिर से, सत्र समय समाप्त होने के बाद, स्मृति प्लेटफ़ॉर्म पर लौट आती है।
1000 ग्राहकों की तीसरी लहर (100 धाराओं में) ~ 11 जीबी। सत्र समय समाप्त होने के बाद, स्मृति प्लेटफ़ॉर्म पर लौट आती है।

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

ज़ूम सेटिंग्स

पहली पंक्ति के दाहिने कॉलम में, संख्या 3/64 (वर्तमान / सीमा) इंगित की गई है - क्लाउडलेट में मेमोरी की खपत (न्यूनतम अविभाज्य टुकड़ा 256Mb है)।
आवेदन को 1 से 64 क्लाउडलेट (256Mb से 16Gb तक) तक बढ़ाया जा सकता है। इस एप्लिकेशन के लिए स्केल फ़ैक्टर सेटिंग = x64 बार।

निष्कर्ष

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

अधिक यथार्थवादी संकेतकों के लिए - हर कोई जो इस पोस्ट का शीर्षक पढ़ता है वह वास्तविक स्थितियों पर परीक्षण में भाग लेता है। शीर्ष छवि प्रत्येक उपयोगकर्ता के सत्र में 200Kb लोड करती है। यदि विषय दिलचस्प है, तो वास्तविक परीक्षा के परिणाम बाद में पोस्ट किए जाएंगे। मुझे उम्मीद है कि 16Gb में स्थापित सीमाएं हबर उपयोगकर्ताओं के लिए पर्याप्त होंगी।

- अद्यतन

प्रयोग के परिणाम

इस लेख के लिए पहला शिखर - लोड परीक्षण - ११ जीबी मेमोरी लेता है।
दूसरी चोटी - इस लेख को मुख्य एक के लिए जारी करना - स्मृति के 2 जीबी ले लिया।
पूंछ - एक अवशिष्ट घटना, गतिविधि में गिरावट - स्मृति का 0.6Gb लिया।

इस तथ्य के आधार पर कि प्रत्येक अद्वितीय आगंतुक के लिए 200kb को मेमोरी में संचालित किया गया था, साथ ही 10 मिनट के भीतर चरम समय पर सर्वर पर 5,000 से अधिक लोग मौजूद नहीं थे।
परिणाम बताते हैं कि आपको अभी भी सर्वर लोड करने में सक्षम होना है :), लोड के अनुकरण ने वास्तविकता से अधिक स्मृति को हिला दिया।
दोनों ही मामलों में, उन्होंने मेमोरी से डायनामिक स्केलिंग का काम किया, अंतिम कीमत की गणना वास्तव में उपभोग किए गए क्लाउडलेट ~~तोते के~~ सापेक्ष की जाएगी।

जावा क्लाउड में वर्टिकल स्केलिंग

सर्वर कार्यान्वयन

ग्राहक का आगमन

ज़ूम सेटिंग्स

निष्कर्ष

प्रयोग के परिणाम

More articles: