वाडिन

Question

में बड़ी प्रणालियों के लिए मेमोरी पदचिह्न मैं वित्तीय क्षेत्र में काम कर रहा हूं और हम बड़े भारी लोड सिस्टम के विकास के लिए वाडिन 7 का चयन करने वाले हैं।

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

क्या कोई भी वाडिन में उन समस्याओं को कम करने या समाप्त करने के लिए अनुभव और संभावित कामकाज साझा कर सकता है?

Answer 1

मुझे लगता है कि तुम यहाँ एक नज़र होनी चाहिए: https://vaadin.com/blog/-/blogs/vaadin-scalability-study-quicktickets

इसके अलावा, मैं लोग हैं, जो उत्पादन में Vaadin चलाने से निम्नलिखित जानकारी मिल गया है।

Balázs Hódossy:

हम 000 10 से अधिक उपयोगकर्ताओं के साथ एक बैक ऑफिस प्रणाली है। दैनिक उपयोगकर्ता संख्या लगभग 3000 है लेकिन उनमें से आधे लॉगआउट के बिना 8 घंटे सिस्टम का उपयोग करते हैं। हम लिफ़ेरे 6.0.5 टोमकैट बंडल और वाडिन का उपयोग पोर्टल के रूप में करते हैं। हमारे दो सर्वरों में 48 जीबी रैम है और हम टोमकैट 24 जीबी ढेर देते हैं। डीबी को 18 जीबी और सिस्टम बाकी मिला। सत्र आकार, समवर्ती उपयोगकर्ताओं और गतिविधि के ढेर को मापें। अधिक मेमोरी अधिक शायद ही कभी पूर्ण जीसी का कारण बनती है। हम टॉमकैट श्रमिकों की संख्या बढ़ाने और ढेर को कम करने की योजना बना रहे हैं। जब आप अपने सर्वर को मापते हैं, तो को थोड़ा और स्मृति जोड़ने का प्रयास करें। यदि प्रोसेसर लागत घटाने और अधिक रैम खरीदने से लागत बहुत महत्वपूर्ण है। अधिकांश समय यह थोड़ा ट्यूनिंग के साथ मूल्यवान है।

पियरे-एम्मानुएल ग्रोस: (ulimit साथ सर्वर 3 जीबी 2 कोर जेट्टी 50000 करने के लिए 50 concurent उपयोगकर्ताओं के साथ Postgresql 9 एक कनेक्शन: 1000 dayly उपयोगकर्ता heavyly इस्तेमाल किया

के लिए, एक शुद्ध vaadin आवेदन पूल का उपयोग किया जाता है)। सॉफ़्टवेयर भाग के रूप में, मैंने डीटीओ ऑब्जेक्ट्स और शुद्ध जेडीबीसी को कैश करने के लिए भी ehcache का उपयोग किया।

Answer 2

हमारे उत्पादों के विकास के दौरान हमें डिफ़ॉल्ट वाडिन आर्किटेक्चर का उपयोग करके बड़ी मेमोरी पदचिह्न की समस्या का सामना करना पड़ा।

वाडिन आर्किटेक्चर घटनाओं द्वारा संचालित घटकों पर आधारित है। घटकों का उपयोग करना कसकर युग्मित अनुप्रयोग बनाने के लिए काफी सरल है। कारण यह है कि घटकों को पदानुक्रम में संरचित किया जाता है। यह एक पिरामिड की तरह है। बड़ा आवेदन बनाया गया है; प्रत्येक उपयोगकर्ता के लिए सत्र में बड़ा पिरामिड संग्रहीत किया जाता है।

मेमोरी आवंटन को काफी कम करने के लिए हमने पुराने स्कूल राज्य प्रबंधन का उपयोग करके पृष्ठभूमि पर एक व्यापक घटना मॉडल के साथ आवेदन के लिए एक पृष्ठ आधारित दृष्टिकोण बनाया है। यह एक्सएमएल प्रारूप में स्टेटकार्ट नोटेशन पर आधारित है।

परिणामस्वरूप सत्र उपयोगकर्ता वर्कफ़्लो के दौरान केवल विज़िट किए गए पृष्ठों को रखता है, जो स्टेटकार्ट कॉन्फ़िगरेशन द्वारा वर्णित है। जब उपयोगकर्ता वर्कफ़्लो समाप्त करता है, तो सभी पृष्ठों को कचरा कलेक्टर द्वारा एकत्रित करने के लिए जारी किया जाता है।

अंतर देखने के लिए हमने एप्लिकेशन के साथ काम करने वाले उपयोगकर्ता के लिए आवंटित स्मृति की तुलना करने के लिए कुछ परीक्षण किए हैं।

अनुप्रयोगों का विकास किया: - 2 एमबी

अप करने के लिए हम काफी खुश हैं

कसकर युग्मित दृष्टिकोण के साथ
• उपयोगकर्ता
ढीला युग्मित दृष्टिकोण के साथ
• प्रति ढेर के 15MB करने के लिए 5 से उपभोग परिणामों के साथ ही यह हमें प्रति सर्वर 1000-1500 समवर्ती उपयोगकर्ताओं तक 4 जीबी रैम का उपयोग करके बड़ी प्रणाली को स्केल करने देता है।

  लगभग भूल गया। हमने Lexaden Web Flow लाइब्रेरी का उपयोग किया। यह अपाचे लाइसेंस के साथ है।