يسعى مطورو ASP باستمرار لتحقيق أداء أفضل وقابلية للتوسع في مشاريع التصميم الخاصة بهم. ولحسن الحظ، هناك العديد من الكتب والمواقع التي تقدم نصائح رائعة في هذا المجال. ومع ذلك، فإن هذه الاقتراحات مبنية على استنتاجات مستمدة من هيكل عمل منصة ASP، ولا يوجد قياس كمي لتحسين الأداء الفعلي. نظرًا لأن هذه التوصيات تتطلب تعليمات برمجية أكثر تعقيدًا وتجعل التعليمات البرمجية أقل قابلية للقراءة، يُترك للمطورين تقييم ما إذا كان تحسين أداء تطبيقات ASP الخاصة بهم يستحق التكلفة دون رؤية النتائج الفعلية.
تنقسم هذه المقالة إلى جزأين وسأقدم بعض نتائج اختبار الأداء لمساعدة المطورين في تحديد ما إذا كانت مبادرة معينة جديرة بالاهتمام ليس فقط للمشاريع المستقبلية، ولكن أيضًا لتحديث المشروع الأصلي. سأقوم في الجزء الأول بمراجعة بعض القضايا الأساسية المتعلقة بتطوير ASP. في الجزء الثاني، ستغطي تحسين بعض وظائف ADO ومقارنة نتائجها مع صفحات ASP التي تستدعي كائنات VB COM لأداء نفس وظائف ADO. وكانت النتائج مذهلة ومفاجئة في بعض الأحيان.
وفي هذا المقال سنجيب على الأسئلة التالية:
* ما هي الطريقة الأكثر فعالية لكتابة المحتوى الذي تم إنشاؤه بواسطة ASP في تدفق الاستجابة؟
* هل يجب تمكين المخزن المؤقت؟
* هل يجب أن تفكر في إضافة تعليقات إلى كود ASP الخاص بك؟
* هل يجب تعيين اللغة الافتراضية بشكل صريح للصفحة؟
* هل يجب إغلاق حالة الجلسة إذا لم تكن هناك حاجة إليها؟
* هل يجب وضع منطق البرنامج النصي في الإجراءات الفرعية ومجالات الوظائف؟
* ما هي الآثار المترتبة على استخدام ملفات التضمين؟
* ما نوع العبء الذي يتم فرضه عند معالجة الأخطاء؟
* هل إعداد معالج السياق له أي تأثير على الأداء؟
تم إجراء جميع الاختبارات باستخدام أداة التركيز على تطبيقات الويب (WAST) من Microsoft، وهي أداة مجانية يمكن العثور عليها هنا. لقد قمت بإنشاء برنامج نصي اختباري بسيط باستخدام WAST والذي يطلق عليه بشكل متكرر اختبارات صفحة ASP الموضحة أدناه (أكثر من 70000 مرة لكل منها). يعتمد وقت الاستجابة على متوسط إجمالي وقت البايت الأخير (TTLB)، وهو الوقت من وقت الطلب الأولي إلى الوقت الذي تتلقى فيه الأداة آخر بت من البيانات من الخادم. خادم الاختبار الخاص بنا هو Pentium 166 مع 196 ميجابايت من ذاكرة الوصول العشوائي والعميل هو Pentium 450 مع 256 ميجابايت من ذاكرة الوصول العشوائي. قد تعتقد أن أداء هذه الأجهزة ليس متقدمًا جدًا، لكن لا تنس أننا لا نختبر سعة الخادم، بل نختبر فقط الوقت الذي يستغرقه الخادم لمعالجة صفحة واحدة في كل مرة. لا تقوم الآلات بأي عمل آخر أثناء الاختبار. يتم تضمين البرامج النصية لاختبار WAST وتقارير الاختبار وجميع صفحات اختبار ASP في ملف ZIP لتتمكن من مراجعتها واختبارها بنفسك.
ما هي الطريقة الأكثر فعالية لكتابة المحتوى الذي تم إنشاؤه بواسطة ASP في تدفق الاستجابة؟
أحد أكبر أسباب استخدام ASP هو إنشاء محتوى ديناميكي على الخادم. لذا فإن نقطة البداية الواضحة لاختبارنا هي تحديد الطريقة الأكثر ملاءمة لإرسال المحتوى الديناميكي إلى تدفق الاستجابة. من بين العديد من الخيارات، يوجد خياران أساسيان: أحدهما هو استخدام علامات ASP المضمنة، والآخر هو استخدام عبارة Response.Write.
ولاختبار هذه الخيارات قمنا بإنشاء صفحة ASP بسيطة قمنا فيها بتعريف بعض المتغيرات ثم قمنا بإدراج قيمها في جدول. على الرغم من أن هذه الصفحة بسيطة وغير عملية للغاية، إلا أنها تسمح لنا بعزل واختبار بعض المشكلات الفردية.
استخدام علامات ASP المضمنة
يتضمن الاختبار الأول استخدام علامة ASP المضمنة < %= x % >، حيث x هو متغير معين. تعتبر هذه الطريقة هي الأسهل من حيث التنفيذ، كما أنها تحافظ على جزء HTML من الصفحة بتنسيق يسهل قراءته وصيانته.
＜% خيار صريح
الاسم الأول خافت
DimLastName
خافت الأوسط الأولي
عنوان خافت
مدينة خافتة
الدولة القاتمة
رقم الهاتف الخافت
رقم الفاكس خافت
خافت البريد الإلكتروني
DimBirthDate
الاسم الأول = جون
MiddleInitial = س
اسم العائلة = عام
العنوان = 100 الشارع الرئيسي
المدينة = نيويورك
الولاية = نيويورك
رقم الهاتف = 1-212-555-1234
رقم الفاكس = 1-212-555-1234
البريد الإلكتروني = [email protected]
تاريخ الميلاد = 1/1/1950
%>
<HTML>
<الرأس>
＜ العنوان ＞ اختبار الاستجابة ＜ / العنوان ＞
＜ /الرأس ＞
＜الجسم＞
＜ H1 ＞ اختبار الاستجابة ＜ /H1 ＞
＜ الجدول ＞
＜ tr ＞＜ td ＞＜ b ＞ الاسم الأول:＜ /b ＞＜ /td ＞＜ td ＞＜ %= الاسم الأول % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ الأولي الأوسط:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ الاسم الأخير:＜ /b ＞＜ /td ＞＜ td ＞＜ %= اسم العائلة % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ العنوان:＜ /b ＞＜ /td ＞＜ td ＞＜ %= العنوان % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ المدينة:＜ /b ＞＜ /td ＞＜ td ＞＜ %= المدينة % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ الحالة:＜ /b ＞＜ /td ＞＜ td ＞＜ %= الحالة % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ رقم الهاتف:＜ /b ＞＜ /td ＞＜ td ＞＜ %= رقم الهاتف % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ رقم الفاكس:＜ /b ＞＜ /td ＞＜ td ＞＜ %= FaxNumber % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ البريد الإلكتروني:＜ /b ＞＜ /td ＞＜ td ＞＜ %= البريد الإلكتروني % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ تاريخ الميلاد:＜ /b ＞＜ /td ＞＜ td ＞＜ %= تاريخ الميلاد % ＞＜ /td ＞＜ /tr ＞
＜ /الجدول ＞
＜ / الجسم ＞
＜ /HTML ＞
الكود الكامل لـ /app1/response1.asp
الأفضل السابق (سرعة الاستجابة) = 8.28 مللي ثانية/صفحة
استخدم عبارة Response.Write في كل سطر من HTML
توصي العديد من وثائق التعلم الأفضل بتجنب الطريقة السابقة. السبب الرئيسي لذلك هو أنه أثناء عملية إخراج الصفحة ومعالجتها لفرض زمن الوصول، إذا كان على خادم الويب التحويل بين إرسال HTML عادي ومعالجة البرنامج النصي، تحدث مشكلة تسمى تبديل السياق. عندما يسمع معظم المبرمجين هذا، يكون رد فعلهم الأول هو تغليف كل سطر من HTML الخام في وظيفة Response.Write.
…
الاستجابة.كتابة(＜html＞)
الاستجابة.اكتب (＜الرأس＞)
الاستجابة.الكتابة (＜العنوان＞اختبار الاستجابة＜/العنوان＞)
الاستجابة. الكتابة (＜/الرأس＞)
الاستجابة.كتابة(＜الجسم＞)
الاستجابة. الكتابة (＜h1＞اختبار الاستجابة＜/h1＞)
الاستجابة.كتابة(＜جدول＞)
الاستجابة.كتابة(＜ tr ＞＜ td ＞＜ b ＞ الاسم الأول:＜ /b ＞＜ /td ＞＜ td ＞ & الاسم الأول & ＜ /td ＞＜ /tr ＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞ الأولي الأوسط:＜ /b ＞＜ /td ＞＜ td ＞ & MiddleInitial & ＜ /td ＞＜ /tr ＞)
…<
جزء من /app1/response2.asp
الأفضل السابق (سرعة الاستجابة) = 8.28 مللي ثانية/صفحة
زمن الاستجابة = 8.08 مللي ثانية/صفحة
الفرق = -0.20 مللي ثانية (تخفيض بنسبة 2.4%)
يمكننا أن نرى أن مكاسب الأداء من استخدام هذا الأسلوب صغيرة جدًا مقارنة باستخدام العلامات المضمنة، ربما لأن الصفحة تقوم بتحميل الخادم بمجموعة من استدعاءات الوظائف الصغيرة. أكبر عيب في هذا الأسلوب هو أنه نظرًا لأن HTML مضمن الآن في البرنامج النصي، فإن رمز البرنامج النصي يصبح أكثر تفصيلاً ويصعب قراءته وصيانته.
استخدام وظائف المجمع
ربما يكون الاكتشاف الأكثر إحباطًا عند محاولة استخدام أسلوب عبارة Response.Write هو أن وظيفة Response.Write لا يمكنها وضع CRLF في نهاية كل سطر. لذلك عندما تقرأ الكود المصدري من المتصفح، فإن HTML الذي تم وضعه بشكل مثالي أصبح الآن سطرًا واحدًا بلا نهاية. أعتقد أن اكتشافك التالي قد يكون أكثر رعبًا: لا توجد وظيفة شقيقة Writeln في كائن الاستجابة. لذلك، رد الفعل الواضح هو إنشاء دالة مجمعة للدالة Response.Write لإلحاق CRLF بكل سطر.
…
writeCR(＜ tr ＞＜ td ＞＜ b ＞ الاسم الأول:＜ /b ＞＜ /td ＞＜ td ＞ & الاسم الأول & ＜ /td ＞＜ /tr ＞)
…
كتابة فرعيةCR(str)
الاستجابة.الكتابة (str & vbCRLF)
نهاية الفرعية
جزء من /app1/response4.asp
الأفضل السابق (سرعة الاستجابة) = 8.08 مللي ثانية/صفحة
زمن الاستجابة = 10.11 مللي ثانية/صفحة
الفرق = +2.03 مللي ثانية (زيادة بنسبة 25.1%)
بالطبع، نظرًا لأن هذا الأسلوب يضاعف بشكل فعال عدد استدعاءات الوظائف، فإن تأثيره على الأداء يكون كبيرًا ويجب تجنبه بأي ثمن. ومن المفارقات أن CRLF يضيف أيضًا 2 بايت لكل سطر إلى الدفق التفاعلي، والذي لا يحتاج المتصفح إلى عرضه على الصفحة. كل ما تفعله لغة HTML المنسقة جيدًا هو تسهيل الأمر على منافسيك لقراءة كود مصدر HTML الخاص بك وفهم تصميمك.
قم بتسلسل الاستجابة المتتالية.اكتب في عبارة واحدة
بغض النظر عن اختباراتنا السابقة مع وظائف التغليف، فإن الخطوة المنطقية التالية هي استخراج جميع السلاسل من عبارات Response.Write المنفصلة وربطها في عبارة واحدة، وبالتالي تقليل عدد استدعاءات الوظائف، وتحسين أداء الصفحة بشكل كبير.
…
الاستجابة.كتابة(＜html＞&_)
＜ رأس ＞ & _
＜العنوان＞اختبار الاستجابة＜/العنوان＞ & _
＜ /الرأس ＞ & _
<الجسم> & _
＜ h1 ＞ اختبار الاستجابة ＜ /h1 ＞ & _
＜ الجدول ＞ & _
＜ tr ＞＜ td ＞＜ b ＞ الاسم الأول:＜ /b ＞＜ /td ＞＜ td ＞ & الاسم الأول & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞ تاريخ الميلاد:＜ /b ＞＜ /td ＞＜ td ＞ & تاريخ الميلاد & ＜ /td ＞＜ /tr ＞ & _
＜ /الجدول ＞ & _
＜ / الجسم ＞ & _
＜ / أتش تي أم أل ＞)
جزء من /app1/response3.asp
الأفضل السابق (سرعة الاستجابة) = 8.08 مللي ثانية/صفحة
زمن الاستجابة = 7.05 مللي ثانية/صفحة
الفرق = -1.03 مللي ثانية (تخفيض بنسبة 12.7%)
حاليًا، هذا هو التكوين الأمثل.
قم بتسلسل الاستجابة المتتالية. اكتب في عبارة واحدة، مع إضافة CRLF في نهاية كل سطر
مع الأخذ في الاعتبار أولئك الذين يحتاجون إلى أن يبدو الكود المصدري الخاص بهم نظيفًا من المتصفح، فقد استخدمت ثابت vbCRLF لإدراج بعض أحرف الإرجاع في نهاية كل سطر في الاختبار السابق وإعادة تشغيله.
…
الاستجابة.كتابة(＜html＞&vbCRLF&_
＜ الرأس ＞ & vbCRLF & _
＜ العنوان ＞ اختبار الاستجابة ＜ /العنوان ＞ & vbCRLF & _
＜ /head ＞ & vbCRLF & _
…
جزء من /app1/response5.asp
الأفضل السابق (سرعة الاستجابة) = 7.05 مللي ثانية/صفحة
زمن الاستجابة = 7.63 مللي ثانية/صفحة
الفرق = +0.58 مللي ثانية (زيادة بنسبة 8.5%)
والنتيجة هي انخفاض طفيف في الأداء، ربما بسبب التسلسل الإضافي وزيادة عدد الأحرف.
المراجعة والملاحظة
يمكن استخلاص بعض القواعد من الاختبارات السابقة على مخرجات ASP:
* تجنب الاستخدام المفرط لـ ASP المضمنة.
* قم دائمًا بتسلسل عبارات الاستجابة المتتالية في عبارة واحدة.
* لا تستخدم مطلقًا وظائف الالتفاف حول Response.Write لإلحاق CRLF.
* إذا كان من الضروري تنسيق مخرجات HTML، فقم بإلحاق CRLF مباشرةً ضمن عبارة Response.Write.
هل يجب تمكين المخزن المؤقت؟
بدء المخزن المؤقت عبر البرنامج النصي
من خلال تضمين Response.Buffer=True في الجزء العلوي من البرنامج النصي لـ ASP، سيقوم IIS بتخزين محتوى الصفحة مؤقتًا.
＜% خيار صريح
Response.Buffer = صحيح
الاسم الأول خافت
…
جزء من /app1/buffer__1.asp
الأفضل السابق (زمن الاستجابة) = 7.05 مللي ثانية/صفحة
زمن الاستجابة = 6.08 مللي ثانية/صفحة
الفرق = -0.97 مللي ثانية (تخفيض بنسبة 13.7%)
لقد تم تحسين الأداء بشكل كبير. ولكن مهلا، هناك شيء أفضل.
بدء المخزن المؤقت عبر تكوين الخادم
على الرغم من تمكين المخزن المؤقت بشكل افتراضي في IIS 5.0، إلا أنه يجب تمكينه يدويًا في IIS 4.0. ابحث الآن عن مربع الحوار "خصائص" الخاص بالموقع وحدد الزر "تكوين" من علامة التبويب "الدليل الرئيسي". ثم حدد تمكين التخزين المؤقت ضمن خيارات التطبيق. بالنسبة لهذا الاختبار، تم نقل عبارة Response.Buffer من البرنامج النصي.
الأفضل السابق = 7.05 مللي ثانية/صفحة
زمن الاستجابة = 5.57 مللي ثانية/صفحة
الفرق = -1.48 مللي ثانية (تخفيض بنسبة 21.0%)
حاليًا، هذه هي أسرع استجابة حصلنا عليها على الإطلاق، وهي أقل بنسبة 21% من وقت الاستجابة الأفضل السابق لدينا. من الآن فصاعدا، ستستخدم اختباراتنا المستقبلية وقت رد الفعل هذا كقيمة أساسية.
المراجعة والملاحظة
تعد المخازن المؤقتة طريقة رائعة لتحسين الأداء، لذا من الضروري تعيين المخازن المؤقتة على القيم الافتراضية للخادم. إذا لم تتمكن الصفحة لسبب ما من تشغيل المخزن المؤقت بشكل صحيح، فما عليك سوى استخدام الأمر Response.Buffer=False. أحد عيوب المخازن المؤقتة هو أن المستخدم لا يرى شيئًا من الخادم حتى تتم معالجة الصفحة بأكملها. لذلك، أثناء معالجة الصفحات المعقدة، من الجيد الاتصال أحيانًا بـ Response.Flush لتحديث المستخدم.
تمت إضافة قاعدة أخرى الآن: قم دائمًا بتمكين التخزين المؤقت عبر إعدادات الخادم.
هل يجب أن تفكر في إضافة تعليقات إلى كود ASP الخاص بك؟
يعرف معظم مطوري HTML أن تضمين تعليقات HTML يعد فكرة سيئة، فهو أولاً يزيد من حجم البيانات التي يتم نقلها، وثانيًا، يقومون فقط بتزويد المطورين الآخرين بمعلومات حول تنظيم صفحتك. ولكن ماذا عن التعليقات على صفحات ASP؟ وهي لا تترك الخادم أبدًا، ولكنها تزيد حجم الصفحة، لذا يجب تقسيمها باستخدام ASP.
في هذا الاختبار، أضفنا 20 تعليقًا، كل منها يتكون من 80 حرفًا، بإجمالي 1600 حرف.
＜% خيار صريح
'------------------------------------------------ - ---------------------------------
…20 سطراً…
'------------------------------------------------ - ---------------------------------
الاسم الأول خافت
…
جزء /app2/comment_1.asp
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 5.58 مللي ثانية/صفحة
الفرق = +0.01 مللي ثانية (زيادة بنسبة 0.1%)
وكانت نتائج الاختبار مذهلة. على الرغم من أن طول التعليقات يبلغ ضعف طول الملف نفسه تقريبًا، إلا أن وجودها ليس له تأثير كبير على أوقات الاستجابة. لذلك يمكننا اتباع القواعد التالية:
وطالما تم استخدامها بشكل معتدل، يكون لتعليقات ASP تأثير ضئيل أو معدوم على الأداء.
هل يجب تعيين اللغة الافتراضية بشكل صريح للصفحة؟
يتعامل IIS مع VBScript بشكل افتراضي، ولكنني أرى أنه في معظم الحالات يتم تعيين اللغة بشكل صريح إلى VBScript باستخدام عبارة <%@LANGUAGE=VBSCRIPT%>. سيختبر اختبارنا التالي مدى تأثير وجود هذا الإعلان على الأداء.
＜ %@ LANGUAGE=VBSCRIPT % ＞
＜% خيار صريح
الاسم الأول خافت
…
جزء /app2/language1.asp.
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 5.64 مللي ثانية/صفحة
الفرق = +0.07 مللي ثانية (زيادة بنسبة 1.2%)
كما ترون، فإن تضمين إعلانات اللغة له تأثير طفيف على الأداء. لذلك:
* ضبط تكوين اللغة الافتراضية للخادم لتتناسب مع اللغة المستخدمة في الموقع.
* لا تقم بتعيين إعلان اللغة إلا إذا كنت تستخدم لغة غير افتراضية.
هل يجب إيقاف تشغيل حالة الجلسة إذا لم تكن هناك حاجة إليها؟
هناك العديد من الأسباب لتجنب استخدام سياق جلسة IIS، ومن الممكن أن تكون تلك الأسباب مقالة خاصة بهم. السؤال الذي نحاول الإجابة عليه الآن هو ما إذا كان إغلاق سياق الجلسة عندما لا تحتاج الصفحة إليه سيساعد في تحسين الأداء. من الناحية النظرية، ينبغي أن يكون نعم، لأنه لن تكون هناك حاجة لاستخدام الصفحة لإنشاء مثيل لسياق الجلسة.
كما هو الحال مع المخزن المؤقت، هناك طريقتان لتكوين حالة الجلسة: من خلال البرامج النصية ومن خلال إعدادات الخادم.
إغلاق سياق الجلسة عبر البرنامج النصي
بالنسبة لهذا الاختبار، ولإغلاق سياق الجلسة في الصفحة، قمت بإضافة إعلان حالة الجلسة.
＜ %@ ENABLESESSIONSTATE = FALSE % ＞
＜% خيار صريح
الاسم الأول خافت
…
جزء /app2/session_1.asp.
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 5.46 مللي ثانية/صفحة
الفرق = -0.11 مللي ثانية (انخفاض بنسبة 2.0%)
لقد تم إحراز تقدم جيد من خلال هذا الجهد الصغير. انظر الآن إلى الجزء الثاني.
أغلق سياق الجلسة من خلال تكوين الخادم
لإغلاق سياق الجلسة على الخادم، انتقل إلى مربع الحوار خصائص الموقع. حدد زر التكوين في علامة التبويب الدليل الرئيسي. ثم قم بإلغاء تحديد تمكين حالة الجلسة ضمن خيارات التطبيق. نقوم بإجراء الاختبار بدون عبارة ENABLESESSIONSTATE.
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 5.14 مللي ثانية/صفحة
الفرق = -0.43 مللي ثانية (تخفيض بنسبة 7.7%)
وهذا تحسن كبير آخر في الأداء. لذلك، يجب أن تكون قاعدتنا: قم دائمًا بإغلاق حالة الجلسة على مستوى الصفحة أو التطبيق عندما لا تكون هناك حاجة إليها.
هل سيؤدي استخدام Option Explicit إلى تغيير الأداء بشكل كبير؟
قم بتعيين Option Explicit في أعلى صفحة ASP ليتطلب الإعلان عن كافة المتغيرات في الصفحة قبل الاستخدام. هناك سببان لذلك. أولاً، يمكن للتطبيقات معالجة الوصول المتغير بشكل أسرع. ثانيًا، هذا يمنعنا من استخدام أسماء المتغيرات بشكل غير صحيح عن طريق الخطأ. في هذا الاختبار، نقوم بإزالة مرجع Option Explicit والإعلان Dim الخاص بالمتغير.
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 6.12 مللي ثانية/صفحة
الفرق = +0.55 مللي ثانية (زيادة 9.8٪)،
على الرغم من إزالة بعض أسطر التعليمات البرمجية من الصفحة، إلا أن أوقات الاستجابة لا تزال تزداد. لذا، على الرغم من أن استخدام الخيار الصريح يستغرق وقتًا طويلاً في بعض الأحيان، إلا أنه له تأثير كبير على الأداء. لذا يمكننا إضافة قاعدة أخرى: استخدم دائمًا الخيار الصريح في VBScript.
هل يجب وضع منطق البرنامج النصي في الإجراءات الفرعية ومجالات الوظائف؟
يعد استخدام الوظائف والإجراءات الفرعية طريقة جيدة لتنظيم التعليمات البرمجية وإدارتها، خاصة عند استخدام منطقة التعليمات البرمجية عدة مرات على الصفحة. العيب هو أنه يضيف استدعاء دالة إضافية إلى النظام الذي يقوم بنفس الوظيفة. مشكلة أخرى تتعلق بالإجراءات الفرعية والوظائف هي نطاق المتغيرات. من الناحية النظرية، يعد تحديد المتغيرات داخل منطقة الوظيفة أكثر كفاءة. الآن دعونا نرى كيف يلعب هذان الجانبان دورهما.
نقل العبارة Response.Write إلى روتين فرعي
يقوم هذا الاختبار ببساطة بنقل عبارة Response.Write إلى منطقة الروتين الفرعي.
…
استدعاء writeTable()
جدول الكتابة الفرعي ()
الاستجابة.كتابة(＜html＞&_)
＜ رأس ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞ البريد الإلكتروني:＜ /b ＞＜ /td ＞＜ td ＞ & البريد الإلكتروني & ＜ /td ＞＜ /tr ＞ & _
＜ tr ＞＜ td ＞＜ b ＞ تاريخ الميلاد:＜ /b ＞＜ /td ＞＜ td ＞ & تاريخ الميلاد & ＜ /td ＞＜ /tr ＞ & _
＜ /الجدول ＞ & _
＜ / الجسم ＞ & _
＜ / أتش تي أم أل ＞)
نهاية الفرعية
جزء /app2/function1.asp
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 6.02 مللي ثانية/صفحة
الفرق = +0.45 مللي ثانية (زيادة بنسبة 8.1%)
كما هو متوقع، تضع الاستدعاءات الروتينية حملاً إضافيًا على الصفحة.
نقل كافة البرامج النصية إلى الإجراءات الفرعية
في هذا الاختبار، يتم نقل عبارة Response.write وإعلانات المتغيرات إلى منطقة الروتين الفرعي.
＜% خيار صريح
استدعاء writeTable()
جدول الكتابة الفرعي ()
الاسم الأول خافت
…
DimBirthDate
الاسم الأول = جون
…
تاريخ الميلاد = 1/1/1950
الاستجابة.كتابة(＜html＞&_)
＜ رأس ＞ & _
＜العنوان＞اختبار الاستجابة＜/العنوان＞ & _
＜ /الرأس ＞ & _
<الجسم> & _
＜ h1 ＞ اختبار الاستجابة ＜ /h1 ＞ & _
＜ الجدول ＞ & _
＜ tr ＞＜ td ＞＜ b ＞ الاسم الأول:＜ /b ＞＜ /td ＞＜ td ＞ & الاسم الأول & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞ تاريخ الميلاد:＜ /b ＞＜ /td ＞＜ td ＞ & تاريخ الميلاد & ＜ /td ＞＜ /tr ＞ & _
＜ /الجدول ＞ & _
＜ / الجسم ＞ & _
＜ / أتش تي أم أل ＞)
نهاية الفرعية
جزء /app2/function2.asp
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 5.22 مللي ثانية/صفحة
الفرق = -0.35 مللي ثانية (تخفيض بنسبة 6.3%)
مثيرة جدا للاهتمام! على الرغم من أن نقل المتغيرات إلى نطاق الوظيفة يضيف استدعاء دالة إضافية، إلا أنه يؤدي في الواقع إلى تحسين الأداء. يمكننا إضافة القواعد التالية:
* في الصفحة، إذا كان سيتم استخدام الرمز أكثر من مرة، فقم بإحاطة الرمز في منطقة الوظيفة.
* عندما يكون ذلك مناسبًا، انقل إعلانات المتغير إلى نطاق الوظيفة.
ما هي الآثار المترتبة على استخدام ملفات التضمين؟
إحدى الميزات المهمة لبرمجة ASP هي تضمين التعليمات البرمجية من الصفحات الأخرى. باستخدام هذه الميزة، يمكن للمبرمجين مشاركة الوظائف عبر صفحات متعددة، مما يجعل صيانة التعليمات البرمجية أسهل. العيب هو أنه يجب على الخادم تجميع الصفحة من مصادر متعددة. فيما يلي اختباران باستخدام تضمين الملفات.
تضمين الملفات باستخدام التعليمات البرمجية المضمنة
في هذا الاختبار، تم نقل جزء صغير من التعليمات البرمجية إلى ملف التضمين:
＜% خيار صريح
الاسم الأول خافت
…
DimBirthDate
الاسم الأول = جون
…
تاريخ الميلاد = 1/1/1950
%>
＜ !-- #include file=inc1.asp -- ＞
/app2/include_1.asp جزء
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 5.93 مللي ثانية/صفحة
الفرق = +0.36 مللي ثانية (زيادة بنسبة 6.5%)
هذا ليس مفاجئا. يتم تشكيل الحمولة باستخدام تضمين الملفات.
استخدم تضمين الملفات في منطقة الوظيفة
هنا، يتم تغليف التعليمات البرمجية في روتين فرعي في ملف تضمين. يتم إنشاء مرجع التضمين في أعلى الصفحة ويستدعي الروتين الفرعي في الموقع المناسب في البرنامج النصي لـ ASP.
＜% خيار صريح
الاسم الأول خافت
…
DimBirthDate
الاسم الأول = جون
…
تاريخ الميلاد = 1/1/1950
استدعاء writeTable()
%>
＜ !-- #include file=inc2.asp -- ＞
/app2/include_2.asp جزء
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 6.08 مللي ثانية/صفحة
الفرق=+0.51 مللي ثانية (زيادة بنسبة 9.2%)
وهذا له تأثير أكبر على الأداء من استدعاءات الوظائف. لذا: استخدم تضمين الملفات فقط عند مشاركة التعليمات البرمجية بين الصفحات.
ما مقدار الحمل الذي يتم إنشاؤه عند تنفيذ معالجة الأخطاء؟
معالجة الأخطاء ضرورية لجميع التطبيقات الحقيقية. في هذا الاختبار، يتم استدعاء معالج الأخطاء عن طريق استدعاء وظيفة On Error Resume Next.
＜% خيار صريح
على خطأ استئناف التالي
الاسم الأول خافت
…
جزء /app2/error_1.asp
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 5.67 مللي ثانية/صفحة
الفرق = 0.10 مللي ثانية (زيادة بنسبة 1.8%)
كما ترون، معالجة الأخطاء لها ثمن. يمكننا أن نقترح ما يلي: استخدم مقابض الأخطاء فقط عندما يحدث شيء يتجاوز قدرتك على الاختبار أو التحكم. أحد الأمثلة الأساسية هو استخدام كائنات COM للوصول إلى موارد أخرى، مثل كائنات ADO أو FileSystem.
هل إعداد معالج السياق له أي تأثير على الأداء؟
عند حدوث خطأ، فإن تعيين معالج السياق على الصفحة يسمح للبرنامج النصي بعكس الإجراء. يتم تعيين هذا باستخدام بيان المعالجة على الصفحة.
＜ %@ المعاملة = % المطلوبة ＞
＜% خيار صريح
الاسم الأول خافت
…
جزء /app2/transact1.asp
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 13.39 مللي ثانية/صفحة
الفرق = +7.82 مللي ثانية (زيادة بنسبة 140.4%)
آه! هذه هي حقا النتيجة الأكثر دراماتيكية. لذا يرجى ملاحظة القاعدة التالية: استخدم سياق المعالجة فقط عند تنفيذ عمليتين أو أكثر كوحدة واحدة.
ختاماً
المهم في الجزء الأول من هذه المقالة هو تراكم العديد من الأشياء الصغيرة. لتسليط الضوء على هذه المشكلة، قمت بإعداد اختبار نهائي حيث قمت بكل الأشياء التي اختبرناها من قبل والتي بدت غير ضارة ولكن في الواقع كان لها تأثير سيء. لقد قمت بتضمين مجموعة من عبارات Response.Write، وإيقاف تشغيل المخزن المؤقت، وتعيين اللغة الافتراضية، وإزالة مرجع Option Explicit، وتهيئة معالج الأخطاء.
＜ %@ LANGUAGE=VBSCRIPT % ＞
<%
على خطأ استئناف التالي
الاسم الأول = جون
…
تاريخ الميلاد = 1/1/1950
الاستجابة.كتابة(＜html＞)
الاستجابة.اكتب (＜الرأس＞)
الاستجابة.الكتابة (＜العنوان＞اختبار الاستجابة＜/العنوان＞)
الاستجابة. الكتابة (＜/الرأس＞)
الاستجابة.كتابة(＜الجسم＞)
الاستجابة. الكتابة (＜h1＞اختبار الاستجابة＜/h1＞)
الاستجابة.كتابة(＜جدول＞)
الاستجابة.كتابة(＜ tr ＞＜ td ＞＜ b ＞ الاسم الأول:＜ /b ＞＜ /td ＞＜ td ＞ &_
الاسم الأول & ＜ /td ＞＜ /tr ＞)
…
Response.Write(＜ tr ＞＜ td ＞＜ b ＞ تاريخ الميلاد:＜ /b ＞＜ /td ＞＜ td ＞ &_
تاريخ الميلاد & ＜ /td ＞＜ /tr ＞)
الاستجابة.كتابة (＜/جدول＞)
الاستجابة.كتابة(＜/الجسم＞)
الاستجابة.كتابة(＜/html＞)
%>
جزء /app2/final_1.asp
خط الأساس = 5.57 مللي ثانية/صفحة
زمن الاستجابة = 8.85 مللي ثانية/صفحة
الفرق = +3.28 مللي ثانية (زيادة بنسبة 58.9%)
قد يبدو الأمر واضحًا، ولكن من المهم أن نفهم أن الكود الذي نضعه على الصفحة له تأثير على الأداء. قد تؤدي التغييرات الصغيرة على الصفحة في بعض الأحيان إلى زيادة أوقات الاستجابة بشكل ملحوظ.
ملخص القواعد
* تجنب الاستخدام المفرط لـ ASP المضمنة.
* قم دائمًا بتسلسل عبارات الاستجابة المتتالية في عبارة واحدة.
* لا تستخدم مطلقًا وظائف الالتفاف حول Response.Write لإلحاق CRLF.
* إذا كان من الضروري تنسيق مخرجات HTML، فقم بإلحاق CRLF مباشرةً ضمن عبارة Response.Write.
* قم دائمًا بتمكين التخزين المؤقت عبر إعدادات الخادم.
* طالما تم استخدامها بشكل معتدل، فإن تعليقات ASP ليس لها تأثير يذكر على الأداء أو لا تأثير لها على الإطلاق.
* ضبط تكوين اللغة الافتراضية للخادم لتتناسب مع اللغة المستخدمة في الموقع.
* لا تقم بتعيين إعلان اللغة إلا إذا كنت تستخدم لغة غير افتراضية.
* استخدم دائمًا الخيار الصريح في VBScript.
* قم دائمًا بإيقاف تشغيل حالة الجلسة على مستوى الصفحة أو التطبيق عند عدم الحاجة إليها.
* استخدم تضمين الملفات فقط عند مشاركة التعليمات البرمجية بين الصفحات.
* في الصفحة، إذا كان سيتم استخدام الرمز أكثر من مرة، فقم بإحاطة الرمز في منطقة الوظيفة.
* عندما يكون ذلك مناسبًا، انقل إعلانات المتغير إلى نطاق الوظيفة.
* استخدم مقابض الأخطاء فقط في حالة حدوث ظروف تتجاوز قدرات الاختبار أو التحكم.
* استخدم معالجة السياق فقط عند تنفيذ عمليتين أو أكثر كوحدة واحدة.
إذا نظرنا إلى الوراء الآن، هناك عدد من الأسئلة التي يمكن أن تكون بمثابة إرشادات عامة:
* تجنب التكرار--لا تقم بتعيين الخصائص التي تم تعيينها افتراضيًا بالفعل.
* الحد من عدد استدعاءات الوظائف.
* تقليل نطاق الكود.