لو سمحتم يا شباب كنت محتاج اعرف شوية حاجات كده

انا عندى app المفروض هيشتغل عليه 200 مستخدم ورفعته على ال glassfish

كنت عاوز اعرف ايه انسب مواصفات لل server اللى هستخدمه من ناحية الرامات والكلام ده المفروض متقلش عن اد ايه

 

وكمان ايه انسب اعدادات لل glassfish من حيث ال connection pool وعدد ال user والكلام ده هل ليهم اعدادات خاصة لما يكون في مستخدمين كتير على ال glassfish ولا ايه

مع العلم انى عامل فى ال app حوالى 7 application module وعامل data source واحدة ليهم هل ده كويس ولا اعمل اكتر من datasource 

ولو عندى برضه app تانية هل اعمله data source مختلفة ولا ايه

 

ارجو اللى عنده خبرة في الوضوع ده يقولى علشان ال users ميشتغلوش وبعدين البرنامج يقف 

وشكرا جزيلا

توجد طريقة حسابية عند اوراكل لمعرفة حجم الذاكرة المطلوب للتشغيل ولكن عموماً دون الدخول في تفاصيل كثيرة فأنصحك ألا تقل الذاكرة عن 24 جيجا

إعداد الـ connection pool من المفترض ان يزيد قليلاً عن أقصى عدد للمستخدمين المتزامنين بنسبة حوالي 5-10%

الأفضل عمل application module واحد فقط

الـ datasource يكون واحد فقط

شكرا جزيلا م/ مصطفى ماجد على ردك 

بس المشكلة انى عملت ال app خلاص فيه حوالى 7 application module ومن الصعب انى اعمله من اول وجديد

هل هتبقى فيه مشكله ولا عادى اكمل ؟؟

هذا يسبب تحميلاً وعدد كبير من الاتصالات يكون مفتوح. الأفضل نقلهم في application module واحد

شكرا جزيلا م/ مصطفى 

فى الحقيقة حضرتك لك فضل كبير فى تعليمى ال ADF

العفو.

الفضل لله أولاً.

 سبعة Application module عدد كبير اذا كان كلهم root Application module  يعنى اليوزر الواحد حيعمل سبع اتصالات للداتابيز شوف بقه لو عندك مثلا عشره يوزر فى نفس الوقت حيعملوا كام من الافضل تخلى واحد بس  parent Application Module والباقى nested  للroot شوف الموضوع ده 

 

https://blogs.oracle.com/jdevotnharvest/entry/recommended_number_and_size_of_application_modules

 

شكرا جزيلا م/ هالة على الأضافة

 

i totally agree with halla

 

best of the best to have nested AMs as well as your parent Root AM

 

a good approach to build your data model projects and deploy it as jar files to be imported in your parent application and handle it as nested AM.

 

benefit of this approach, High Performance as you avoid many VOs in same AM and avoid duplicated db connection with navigating from AM to another.

finally, activate lazy loading facility in Root AM to differentiate between AM execution & VOs Executions.

 

good luck