java - خادم تطبيقات Websphere-ما الذي يتطلبه الأمر لبدء أي صوم؟




performance java-ee (6)

أنا أستخدم Rational Application Developer v7.0 الذي يأتي مع بيئة اختبار متكاملة. عندما أحصل على تصحيح Webapp الخاص بي ، فإن وقت بدء الخادم في وضع التصحيح يقترب من 5-6 دقائق - وهو وقت كاف لأخذ استراحة لتناول القهوة!

في بعض الأحيان ، يزعجني لدرجة أنني أبدأ في شتم IBM لبناء نظام تشغيل بدلاً من خادم تطبيقات! وضع أكثر من 20 عملية وخدمات عديمة الفائدة بدون تكوين موثق لضبطها ، لبدء أي أسرع.

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

ليس لدي أي خدمات ويب ، ولا حبوب شركة ، ولا طوابير ، بل تطبيق ويب بسيط يتطلب تجمع اتصال. هل قمت بشيء في الماضي لجعل بيئة الاختبار المتكاملة الخاصة بك ، والبدء بسرعة في وضع التصحيح وهناك تستهلك أقل من ذاكرة الوصول العشوائي؟

حدث: حاولت تعطيل بعض الخدمات (تدويل ، تطبيقات افتراضية ، إلخ ...) والآن أصبح خادم WebSphere من سيئ إلى أسوأ. لا يستغرق الأمر وقتًا مرعبًا لبدء التشغيل فحسب ، بل يستمر في التجميد بين الحين والآخر لمدة تصل إلى دقيقتين. :-( يبدو وكأنه ، والتحسين ليس هذا شيء جيد ، دائما!


أحد الأسباب الرئيسية هو أن لديك تطبيقًا كبيرًا يحتوي على العديد من الوحدات ، والفئات ، والمجلدات ، واصفات XML ، وما إلى ذلك ، وحقيقة أن عملية بدء خادم تطبيق Websphere هي واحدة مترابطة في حد ذاتها (وبالتالي يمكن بدء تشغيل كل تطبيق بشكل منفصل موضوع إذا كان لديهم نفس الوزن). أحد الأسباب الأخرى هو أن إطارات Eclipse EMF و JST تتسم بدرجة كبيرة من I / O أثناء بدء التشغيل والنشر / النشر.

أحد الأسباب الأخرى لبدء التشغيل الممل هو مسح التعليقات التوضيحية الذي سيحدث أثناء النشر / النشر. يمكن التحكم في هذا التعليق التوضيحي وتعديله بطرق مختلفة. انظر إلى هذا الموقع: http://wasdynacache.blogspot.se/2012/05/how-to-speed-up-annotation-processing.html

أولا وقبل كل شيء ، فحص وتقييم الأجهزة الخاصة بك ، على حد سواء وحدة المعالجة المركزية والذاكرة والأقراص الصلبة. هل يعمل المعالج / المعالج بنسبة 100٪ لفترة طويلة أثناء بدء التشغيل؟ إذا كان الأمر كذلك ، فقد يكون المعالج ضعيفًا جدًا. هل يحدث الترحيل؟ ثم قد تضطر إلى وضع بعض أكثر من ذاكرة الوصول العشوائي. تعتبر إطارات عمل Websphere / eclipse JST و EMF غاية في كثافة I / O لذا يجب عليك التفكير في الاستثمار في قرص SSD. يجب عليك أيضًا التأكد من أن العمليات الأخرى على جهازك (برامج الحماية من الفيروسات إلخ) لا تسرق موارد الأجهزة من عمليات جافا Websphere.

حتى بالنسبة للأجهزة: 1. المعالج - واحد سريع جدا ، منذ نشرها وبدء تشغيلها في الغالب مفردات لا تحتاج إلى أن العديد من النوى وحدة المعالجة المركزية 2. الذاكرة - سوف تحتاج على الأقل 512 ميغابايت من ذاكرة الوصول العشوائي الفعلية ، وهذا يعتمد على حجم من تطبيقك بالطبع. 3. التخزين - سأذهب بالتأكيد إلى SSD سريع بما أن إطار الكسوف الأساسي هو I / O المكثف.

فيما يلي بعض الحيل لتقليل أثر مرحلة البدء. الرجاء قبل تطبيق هذه الإعدادات تأكد من تسجيل بدء خط أساسي حتى تتمكن من ملاحظة الفرق في بدء التشغيل ، أي وقت البدء المنخفض.

  1. JVM args: -Xverify: none -Xquickstart -Xnoclassgc -XX: + UseNUMA -XtlhPrefetch -Xgcthreads4 (حصلت على 4 معالجات افتراضية مثبتة على الجهاز الخاص بي)
  2. قم بتوسيع حجم الذاكرة ليتناسب مع متطلبات التطبيق الخاص بك.
  3. تعطيل autostart التطبيق لتقليل وقت النشر.
  4. تعطيل PMI و التتبع غير الضروري.
  5. ملف التطبيق الخاص بك أثناء بدء التشغيل وإصلاح الاختناقات إذا وجدت أي.

وسيطات JVM الأخرى التي قد تكتسب الأداء:

  • com.ibm.cacheLocalHost = صحيح
  • com.ibm.ws.classloader.zipFileCacheSize = 512
  • com.ibm.ws.classloader.resourceRequestCacheSize = 1024
  • com.ibm.ws.management.event.pull_notification_timeout = 20000
  • com.ibm.ws.amm.scan.context.filter.packages = صحيح
  • org.eclipse.jst.j2ee.commonarchivecore.disableZip = صحيح

وسيطات Jvm التي ستجعل خادم تطبيقات Websphere تتوقف على الفور:

  • com.ibm.ejs.sm.server.quiesceTimeout = 0
  • com.ibm.ejs.sm.server.quiesceInactiveRequestTime = 1000

خصائص Webcontainer:

  • com.ibm.wsspi.jsp.disableTldSearch = صحيح
  • com.ibm.wsspi.jsp.disableResourceInjection = صحيح

الوسيطات JVM التي قد يتم تحديدها eclipse.ini (لاحظ أن معلمات كومة الذاكرة المؤقتة تم تكوينها وفقًا لظروف بيئتي)

  • -Dcom.ibm.ws.management.event.max_polling_interval = 5000
  • -Xquickstart
  • -Xverify: لا شيء
  • -Xmxcl25000
  • -Xjit: dataTotal = 65536
  • -Xcodecache64m
  • -Xscmx48m
  • -Xnolinenumbers
  • -Xverify: لا شيء
  • -Xmnx64m
  • -Xmx1446m
  • -Xmnx64m
  • -XX: + UseCompressedOops
  • -XX: + UseNUMA

أفضل طريقة لتصحيح رمز الخادم هي استخدام تصحيح الأخطاء عن بُعد.

تحتاج أولاً إلى إضافة ما يلي إلى معلمات JVM في البرنامج النصي لبدء تشغيل الخادم:

-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

سيتسبب هذا في JVM للاستماع على المنفذ المحدد ، ثم من IDE يمكنك بدء جلسة تصحيح أخطاء عن بعد ضد هذا المنفذ وتصحيح كما لو تم تشغيل التعليمات البرمجية في نفس العملية.

إن العمل بهذه الطريقة يمنعك من إعادة تشغيل الخادم بشكل متكرر وبالتالي الخطوات الجانبية لمشكلتك مع وقت بدء Websphere.

يمكنك الحصول على بعض النتائج الفردية إذا كانت الثنائيات الموجودة على الخادم والمصدر في IDE تخرج عن المزامنة ولكن على العموم ليست مشكلة.


إذا لم يكن لديك EJBs ، لا JMS ، إلخ ، فقط قم بنشرها تحت حاوية servlet مستقلة مثل Tomcat أو Jetty ، ستندهش من مدى السرعة :-) ، كونها مثيرة للسخرية هنا ولكن هذا صحيح!


من 5 إلى 6 دقائق ليست طبيعية. يمكنني استخدام RAD و WAS كل يوم والحصول على أوقات بدء لائق. ما إصدار WAS الذي تشغله وكم ذاكرة الوصول العشوائي لديك؟

إذا قمت بمشاركة عدة مساحات عمل ومشاريع لنفس ملف WAS ، ففكر في إنشاء ملف تعريف WAS جديد لمساحة العمل الخاصة بك.

ربما جربت ذلك ولكن هنا قائمة بسيطة بالأشياء التي يمكنك تجربتها مباشرة. تأكد من تمكين إعدادات الخادم في RAD في الخيارات التالية:

  • تحسين خادم للاختبار وتطوير
  • تشغيل الخادم مع الموارد على مساحة العمل
  • تصغير ملفات التطبيق المنسوخة إلى الخادم

ألغِ تحديد "تمكين عميل اختبار عالمي" إذا لم تكن بحاجة إليه.

في وحدة تحكم المشرف ، يمكنك التحقق من بعض إعدادات الخادم مثل

  • تشغيل في وضع التطوير
  • بداية موازية
  • بدء المكونات حسب الحاجة

يمكنك أيضًا إزالة تثبيت تطبيق ivt الذي يأتي مثبتًا بشكل افتراضي عند إنشاء ملف WAS جديد. ثم الأشياء المعتادة مثل محرك أقراص غير مجزأة وحجم ملف ترحيل الصفحات يتم تعيين بشكل صحيح.

وأخيرًا شيء آخر ربما تعرفه بالفعل ، أعد نشره إلى خادمك بدلاً من إعادة تشغيله.


هناك بعض التلميحات والنصائح من أجل ضبط RAD 6 على أعمال المطورين التي قد تساعد ، العديد من هذه تنطبق أيضًا على RAD 7.

لقد رأيت قائمة مماثلة لـ RAD 7 ، سأقوم بنشرها إذا استطعت العثور عليها.

لقد وجدت بعض نصائح الضبط لـ Portal على RAD 7 .

أود أن أقول إن تجربتي مع بيئة الاختبار كانت دون المستوى الأمثل. أنا الآن أميل إلى استخدام Tomcat / Pluto مهيئًا لتصحيح الأخطاء عن بُعد باستخدام تهيئة تشغيل خارجية لإدارة ذلك من داخل Eclipse العارية والاعتماد على تكوينات JNDI المناسبة للتخلص من الخادم الأساسي.

إذا كنت تقوم بترميز واجهات برمجة التطبيقات ذات الصلة ، فلا يجب أن تكون مهمًا لأغراض التطوير التي لا تتناولها على Websphere. إذا كان لديك مشكلة خاصة على Webpshere يمكنك دومًا تحريك الوحش لتصحيحه.


يعالج WAS V7 بعض هذه المشاكل عن طريق السماح لك بتكوين ما يبدأ عند بدء تشغيل خادم التطبيق.

إذن إذا وعندما تهاجر إلى WAS V7 قد تبدو بعض التحسينات في هذا الفضاء.





websphere