الطريقة الأولى: تخزين البيانات مؤقتًا في طريقة init() الخاصة بـ servlet
بعد أن يقوم خادم التطبيق بتهيئة مثيل servlet وقبل تقديم طلبات العميل، فإنه يستدعي طريقة init() الخاصة بـ servlet. في دورة حياة servlet، سيتم استدعاء الأسلوب init() مرة واحدة فقط. من خلال تخزين بعض البيانات الثابتة مؤقتًا في طريقة init() أو إكمال بعض العمليات التي تستغرق وقتًا طويلاً والتي تحتاج إلى تنفيذها مرة واحدة فقط، يمكن تحسين أداء النظام بشكل كبير.
على سبيل المثال، يعد إنشاء تجمع اتصال JDBC في طريقة init () أفضل مثال. لنفترض أننا نستخدم واجهة DataSource لـ jdbc2.0 للحصول على اتصال بقاعدة البيانات، في الظروف العادية، نحتاج إلى الحصول على بيانات محددة من خلال مصدر JNDI. يمكننا أن نتخيل أنه في تطبيق معين، إذا تم تنفيذ استعلام JNDI لكل طلب SQL، فسوف ينخفض أداء النظام بشكل حاد. الحل هو التعليمة البرمجية التالية، التي تقوم بتخزين DataSource مؤقتًا بحيث لا يزال من الممكن استخدامه أثناء استدعاء SQL التالي:
ما يلي هو جزء مرجعي:
الطبقة العامة ControllerServlet يمتد HttpServlet {
public javax.sql.DataSource testDS = null;
init الفراغ العام (تكوين ServletConfig) يطرح ServletException {
super.init(config);
السياق ctx = null;
يحاول{
ctx = new originalContext();
testDS = (javax.sql.DataSource)ctx.lookup("jdbc/testDS");
}catch(NamingException ne){ne.printStackTrace();}
}catch(استثناء e){e.printStackTrace();}
}
public javax.sql.DataSource getTestDS(){
اختبار العودة؛
}
...
...
}
الطريقة الثانية: تعطيل إعادة التحميل التلقائي لـ servlet وJSP (إعادة التحميل التلقائي)
يوفر Servlet/JSP تقنية عملية، وهي تقنية إعادة التحميل التلقائي، والتي توفر للمطورين بيئة تطوير جيدة عند تغيير صفحات servlet وJSP دون الحاجة إلى إعادة تشغيل خادم التطبيق. ومع ذلك، فإن هذه التقنية تمثل خسارة كبيرة لموارد النظام أثناء مرحلة تشغيل المنتج، لأنها ستجلب عبئًا كبيرًا على محمل الفئة لمحرك JSP. لذلك، يعد إيقاف تشغيل وظيفة إعادة التحميل التلقائي بمثابة مساعدة كبيرة لتحسين أداء النظام.
الطريقة الثالثة: لا تسيء استخدام HttpSession
في العديد من التطبيقات، يحتاج برنامجنا إلى الحفاظ على حالة العميل حتى تتمكن الصفحات من التواصل مع بعضها البعض. لكن لسوء الحظ، نظرًا لأن HTTP عديم الحالة بطبيعته، فلا يمكنه حفظ حالة العميل. ولذلك، توفر خوادم التطبيقات العامة جلسات لحفظ حالة العميل. في خادم تطبيقات JSP، يتم تنفيذ وظيفة الجلسة من خلال كائن HttpSession، ولكن على الرغم من أنها مريحة، إلا أنها تجلب أيضًا الكثير من العبء على النظام. لأنه في كل مرة تحصل فيها على جلسة أو تقوم بتحديثها، يتعين على مشغل النظام إجراء عمليات تسلسل تستغرق وقتًا طويلاً عليها. يمكنك تحسين أداء النظام من خلال طرق المعالجة التالية لـ HttpSession.
إذا لم يكن ذلك ضروريًا، فيجب إيقاف تشغيل الإعدادات الافتراضية لـ HttpSession في صفحة JSP. ستقوم كل صفحة JSP بإنشاء جلسة HttpSession بشكل افتراضي إذا لم تحددها بشكل صريح. إذا لم تكن بحاجة إلى استخدام الجلسة في JSP الخاص بك، فيمكنك تعطيلها من خلال مؤشر صفحة JSP التالي:
ما يلي هو جزء مرجعي:
＜%@ جلسة الصفحة = "خطأ"%＞
لا تقم بتخزين كائنات بيانات كبيرة في HttpSession: إذا قمت بتخزين كائنات بيانات كبيرة في HttpSession، فسيقوم خادم التطبيق بإجراء تسلسل لها في كل مرة تتم قراءتها أو كتابتها، مما يضيف عبئًا إضافيًا على النظام. كلما زاد حجم كائن البيانات الذي تقوم بتخزينه في HttpSession، انخفض أداء النظام بشكل أسرع.
عندما لم تعد بحاجة إلى جلسة HttpSession، قم بتحريرها في أقرب وقت ممكن: عندما لم تعد بحاجة إلى الجلسة، يمكنك تحريرها عن طريق استدعاء الأسلوب HttpSession.invalidate(). حاول تعيين مهلة الجلسة قصيرة قدر الإمكان: في خادم تطبيقات JSP، هناك مهلة افتراضية للجلسة. عندما لا يقوم العميل بإجراء أي عمليات بعد هذا الوقت، سيقوم النظام تلقائيًا بتحرير الجلسة ذات الصلة من الذاكرة. كلما تم ضبط المهلة بشكل أكبر، انخفض أداء النظام، لذا فإن أفضل طريقة هي محاولة إبقاء قيمتها منخفضة قدر الإمكان.
الطريقة الرابعة: يعد ضغط إخراج الصفحة
طريقة جيدة لحل مشكلة تكرار البيانات، خاصة اليوم عندما لا يتم تطوير النطاق الترددي للشبكة بشكل كافٍ. تدعم بعض المتصفحات gzip (GNU zip) لضغط ملفات HTML. يمكن لهذه الطريقة تقليل وقت تنزيل ملفات HTML بشكل كبير. لذلك، إذا قمت بضغط صفحة HTML التي تم إنشاؤها بواسطة صفحة servlet أو JSP، فسيشعر المستخدم أن سرعة تصفح الصفحة ستكون سريعة جدًا. لسوء الحظ، لا تدعم جميع المتصفحات ضغط gzip، ولكن يمكنك التحقق في برنامجك مما إذا كان متصفح العميل يدعمه. فيما يلي مقتطف تعليمات برمجية حول تنفيذ هذه الطريقة:
فيما يلي مقتطف اقتباس:
doGet الفراغ العام (طلب HttpServletRequest، استجابة HttpServletResponse)
يلقي IOException، ServletException {
OutputStream out = null;
ترميز السلسلة = request.getHeader("Accept-Encoding");
إذا (ترميز != null && encoding.indexOf("gzip") != -1){
request.setHeader("ترميز المحتوى" , "gzip");
out = new GZIPOutputStream(request.getOutputStream());
}
else if (encoding != null && encoding.indexOf("comdivss") != -1){
request.setHeader("ترميز المحتوى" , "comdivss");
out = new ZIPOutputStream(request.getOutputStream());
}آخر{
out = request.getOutputStream();
}
...
...
}
الطريقة الخامسة: استخدم تجمع مؤشرات الترابط.
يقوم خادم التطبيق بإنشاء مؤشر ترابط لمعالجة كل طلب عميل مختلف بشكل افتراضي، ثم يقوم بتعيين طريقة الخدمة () لهم، ثم يتم إلغاء مؤشر الترابط المقابل أيضًا . نظرًا لأن إنشاء سلاسل الرسائل وتدميرها يستهلك موارد نظام معينة، فإن هذا الوضع الافتراضي يقلل من أداء النظام. لكن لحسن الحظ يمكننا تغيير هذا الوضع عن طريق إنشاء تجمع مؤشرات الترابط.
بالإضافة إلى ذلك، نحتاج أيضًا إلى تعيين الحد الأدنى لعدد سلاسل الرسائل والحد الأقصى لعدد سلاسل الرسائل لتجمع سلاسل الرسائل هذا. عندما يبدأ خادم التطبيق، سيقوم بإنشاء تجمع مؤشرات ترابط برقم يساوي الحد الأدنى لعدد سلاسل الرسائل. عندما يكون لدى العميل طلب، يتم إخراج مؤشر الترابط من التجمع للمعالجة ضعه مرة أخرى في حمام السباحة. إذا لم تكن هناك سلاسل رسائل كافية في التجمع، فسيقوم النظام تلقائيًا بزيادة عدد سلاسل الرسائل في التجمع، ولكن لا يمكن أن يتجاوز العدد الإجمالي الحد الأقصى لعدد سلاسل الرسائل. باستخدام تجمع مؤشرات الترابط، عندما تزيد طلبات العميل بشكل حاد، سيُظهر حمل النظام منحنى تصاعديًا سلسًا، وبالتالي تحسين قابلية التوسع للنظام.
الطريقة السادسة: اختيار آلية تضمين الصفحة الصحيحة
هناك طريقتان في JSP يمكن استخدامهما لتضمين صفحة أخرى:
1. استخدم توجيه التضمين
ما يلي هو جزء مرجعي.
＜%@ includee file=”test.jsp” %＞
2. استخدم مؤشر jsp.
ما يلي هو جزء مرجعي:
من الناحية العملية، تبين أنه إذا تم استخدام الطريقة الأولى، يمكن أن يكون أداء النظام أعلى.
الطريقة السابعة: تحديد دورة حياة Javabeans بشكل صحيح
أحد الجوانب القوية لـ JSP هو دعمه لـ javabeans. يمكن إدراج JavaBeans مباشرةً في صفحة JSP باستخدام علامة jsp:useBean الموجودة في صفحة JSP. إليك كيفية استخدامه:
إليك مقتطف اقتباس:
＜/jsp:useBean＞
تشير سمة النطاق إلى دورة حياة هذه الحبة. دورة الحياة الافتراضية هي الصفحة. إذا لم تقم باختيار دورة حياة الفول بشكل صحيح، فسوف يؤثر ذلك على أداء النظام.
على سبيل المثال، إذا كنت تريد فقط استخدام حبة معينة في طلب واحد، ولكنك قمت بتعيين دورة حياة الحبة على الجلسة، فعند انتهاء الطلب، ستظل الحبة في الذاكرة ما لم تنتهي مهلة الجلسة أو يغلق المستخدم المتصفح. سيؤدي هذا إلى استهلاك قدر معين من الذاكرة وزيادة عبء العمل على أداة تجميع البيانات المهملة JVM بشكل غير ضروري. ولذلك، فإن تحديد دورة الحياة الصحيحة للفاصوليا وتنظيفها في أسرع وقت ممكن بعد انتهاء مهمتها سيؤدي إلى تحسين أداء النظام.
بعض الطرق المفيدة الأخرى
1. حاول عدم استخدام عامل التشغيل "+" في عمليات اتصال السلسلة: في برمجة جافا، غالبًا ما نستخدم عامل التشغيل "+" لتوصيل عدة سلاسل، لكن ربما لم تفكر في الأمر من قبل أداء النظام؟ نظرًا لأن السلاسل عبارة عن ثوابت، فسيقوم JVM بإنشاء بعض الكائنات المؤقتة. كلما زاد عدد "+" الذي تستخدمه، سيتم إنشاء المزيد من الكائنات المؤقتة، مما سيكون له أيضًا بعض التأثير على أداء النظام. الحل هو استخدام كائن StringBuffer بدلاً من عامل التشغيل "+".
2. تجنب استخدام طريقة System.out.println(): نظرًا لأن System.out.println() عبارة عن مكالمة متزامنة، أي أنه عند الاتصال بها، يجب أن تنتظر عملية الإدخال / الإخراج للقرص حتى اكتمالها، لذا يجب أن نحاول لتجنب استخدامه دعوته. لكنها أداة لا غنى عنها ومريحة عندما نقوم بتصحيح أخطاء البرنامج. ولحل هذا التناقض، أقترح عليك استخدام أداة Log4j ( http://Jakarta.apache.org )، والتي يمكن أن تسهل تصحيح الأخطاء بدون طرق مثل System.out. سيتم إنشاء .println().
3. المفاضلة بين ServletOutputStream وPrintWriter: قد يؤدي استخدام PrintWriter إلى بعض النفقات العامة الصغيرة، لأنه يحول كل المخرجات الأصلية إلى دفق أحرف للإخراج، لذلك إذا تم استخدامه كمخرجات صفحة، فيجب أن يتحمل النظام عملية تحويل. لا توجد مشكلة إذا كنت تستخدم ServletOutputStream كمخرج للصفحة، ولكن يتم إخراجه بشكل ثنائي. ولذلك، يجب الموازنة بين إيجابيات وسلبيات كل منهما في التطبيقات العملية.
ملخص
الغرض من هذه المقالة هو تحسين أداء تطبيقك بشكل كبير من خلال بعض تقنيات الضبط لـ servlets وJSP، وبالتالي تحسين أداء تطبيق J2EE بأكمله. من خلال تقنيات الضبط هذه، يمكنك أن تجد أنه ليس نظامًا أساسيًا تقنيًا معينًا (مثل النزاع بين J2EE و.NET) هو الذي يحدد أداء تطبيقك، المهم هو أن يكون لديك فهم أعمق لهذه المنصة، لذا عندها فقط يمكنك تحسين تطبيقك بشكل أساسي.