أفضل 10 طرق لتحسين أداء تطبيقات ASP.Net
الكاتب：Eve Cole
وقت التحديث：2009-06-30 15:49:49
يناقش هذا المقال:
الخرافات الشائعة حول تحسين أداء تطبيق asp.net نصائح مفيدة لتحسين أداء تطبيق asp.net
توصيات لتشغيل قواعد البيانات مع تطبيقات Asp.net
التخزين المؤقت ومعالجة الخلفية في Asp.net
في الوقت الحاضر، أصبحت كتابة تطبيق ويب ASP.NET أمرًا بسيطًا للغاية، ولا يرغب العديد من المبرمجين في قضاء الوقت في إنشاء تطبيق ذي أداء جيد. ستناقش هذه المقالة أفضل عشر طرق لتحسين أداء تطبيقات الويب. لن أقصر مناقشتي على تطبيقات ASP.NET فقط لأنها ليست سوى مجموعة فرعية من تطبيقات الويب. لا يمكن لهذه المقالة أيضًا أن تقدم دليلاً كاملاً لتحسين أداء تطبيقات الويب، حيث أن ذلك يتطلب طول كتاب. توفر هذه المقالة نقطة بداية جيدة فقط لتحسين أداء تطبيقات الويب. (الشيء الوحيد المتبقي هو أن ندرس ببطء بأنفسنا).
خارج العمل، غالبًا ما أذهب لتسلق الصخور، قبل كل تسلق للصخور، سأقوم بمراجعة خريطة طريق تسلق الصخور وقراءة نصائح متسلقي الصخور الناجحين السابقين. لأننا بحاجة إلى تجربتهم الناجحة. وبالمثل، عندما تحتاج إلى تعديل برنامج به مشاكل في الأداء أو تطوير موقع ويب عالي الأداء، فإنك تحتاج أيضًا إلى تعلم كيفية كتابة تطبيق ويب عالي الأداء.
تجربتي الشخصية تأتي بشكل أساسي من العمل كمدير برامج في مجموعة asp.net التابعة لشركة Microsoft، وتشغيل وإدارة موقع www.asp.net ، والمساعدة في تطوير Community Server (وهو نسخة متكاملة ومحدثة من منتديات asp.net والنصوص وبرنامج nGallery). أعتقد أن هذه التجارب يمكن أن تساعدني.
قد تفكر في تقسيم تطبيقك إلى طبقات منطقية مختلفة. ربما تكون قد سمعت أيضًا عن البنية الفيزيائية ثلاثية الطبقات أو بنية الطبقة N، وهي نموذج الهندسة الأكثر استخدامًا، فهي تقوم فعليًا بتعيين وظائف برامج مختلفة لمختلف الأجهزة للتنفيذ. بهذه الطريقة، إذا أردنا تحسين أداء التطبيق، فإن إضافة بعض الأجهزة يمكن أن يحقق الهدف. ومن المنطقي أن هذه الطريقة يمكن أن تحسن أداء التطبيق، ولكن يجب علينا تجنب استخدام هذه الطريقة. لذلك، كلما أمكن ذلك، يجب علينا وضع صفحة ASP.NET والمكونات التي تستخدمها في التطبيق.
بسبب النشر الموزع واستخدام خدمات الويب أو العمل عن بعد، سيؤدي ذلك إلى تقليل أداء التطبيق بنسبة 20% أو أكثر.
تختلف طبقة البيانات قليلاً، فمن الأفضل نشرها بشكل مستقل واستخدام جهاز منفصل لتشغيلها. وعلى الرغم من ذلك، لا تزال قاعدة البيانات تمثل عنق الزجاجة في أداء التطبيقات. لذلك، عندما تريد تحسين برنامجك، فإن أول ما يتبادر إلى ذهنك هو تحسين طبقة البيانات.
قبل أن تقوم بتعديل منطقة من تطبيقك تسبب مشاكل في الأداء، ستحتاج إلى التأكد من أن البرنامج الذي يسبب المشكلة يبدو محكمًا، حيث تعد ملفات تعريف الأداء مفيدة جدًا لمعرفة المكان الذي يستغرقه في تطبيقك والمدة التي يستغرقها. هذه أماكن لا يمكننا أن نشعر بها بشكل حدسي.
تتناول هذه المقالة نوعين من تحسينات الأداء: أحدهما عبارة عن تحسينات كبيرة للأداء (تحسينات كبيرة)، مثل استخدام ذاكرة التخزين المؤقت الخاصة بـ asp.net، والآخر عبارة عن تحسينات صغيرة للأداء (تحسينات صغيرة). قد تكون تحسينات الأداء الصغيرة مفيدة جدًا في بعض الأحيان. يمكنك إجراء تغيير بسيط على الكود الخاص بك واستدعاءه ألف أو عشرة آلاف مرة في المرة الواحدة. قم بإجراء تحسين كبير للأداء وسترى تحسنًا كبيرًا في سرعة التطبيق الخاص بك. قد يؤدي تحسين الأداء البسيط إلى تحسين ميكروثانية واحدة فقط لكل طلب، ولكن إذا كان عدد الطلبات يوميًا كبيرًا، فسيحصل التطبيق على تحسن كبير في الأداء.
أداء طبقة البيانات
عندما تريد تحسين أداء أحد التطبيقات، يمكنك العمل بالترتيب التالي: هل يحتاج الكود الخاص بك إلى الوصول إلى قاعدة البيانات؟ إذا كان الأمر كذلك، كم مرة يجب الوصول إلى قاعدة البيانات؟ وبالمثل، يمكن أيضًا استخدام طريقة الاختبار هذه في كود البرنامج الذي يستخدم خدمات الويب أو الاتصال عن بعد. لن تناقش هذه المقالة مسألة تحسين البرنامج باستخدام خدمات الويب والاتصال عن بعد.
إذا كان هناك طلب في التعليمات البرمجية الخاصة بك يجب أن يصل إلى قاعدة البيانات، ورأيت التعليمات البرمجية التي تنفذ نفس الوظيفة في مكان آخر، فأنت بحاجة إلى تحسينها أولاً. قم بالتعديل والتحسين ومواصلة الاختبار ما لم تكن لديك مشكلة كبيرة جدًا في الأداء، فمن الأفضل قضاء وقتك في تحسين الاستعلامات والاتصال بقاعدة البيانات وإرجاع حجم مجموعة البيانات والوقت المستغرق لإرجاع الاستعلام.
بناءً على ملخص التجارب، دعنا نلقي نظرة على عشر تجارب يمكنها مساعدتك في تحسين أداء تطبيقك، وسأشرحها بالترتيب من الأكبر إلى الأصغر من حيث مدى تحسينها للكفاءة.
1. قم بإرجاع مجموعات بيانات متعددة
تحقق من رمز الوصول إلى قاعدة البيانات الخاصة بك لمعرفة ما إذا كانت هناك أية طلبات يتم إرجاعها عدة مرات. تقلل كل رحلة ذهابًا وإيابًا من عدد الطلبات التي يمكن لتطبيقك الاستجابة لها في الثانية. من خلال إرجاع مجموعات نتائج متعددة في طلب قاعدة بيانات واحد، يمكنك تقليل الوقت المستغرق للاتصال بقاعدة البيانات، وجعل نظامك قابلاً للتطوير، وتقليل عبء العمل على خادم قاعدة البيانات للاستجابة للطلبات.
إذا كنت تستخدم عبارات SQL الديناميكية لإرجاع مجموعات بيانات متعددة، فإنني أوصي باستخدام الإجراءات المخزنة بدلاً من عبارات SQL الديناميكية. إن كتابة منطق الأعمال في الإجراءات المخزنة أمر مثير للجدل بعض الشيء. لكنني أعتقد أن كتابة منطق الأعمال في الإجراءات المخزنة يمكن أن يحد من حجم مجموعة النتائج التي يتم إرجاعها، ويقلل من حركة بيانات الشبكة، ويلغي الحاجة إلى تصفية البيانات في الطبقة المنطقية، وهذا أمر جيد.
استخدم الأسلوب ExecuteReader للكائن SqlCommand لإرجاع كائن أعمال مكتوب بقوة، ثم قم باستدعاء الأسلوب NextResult لتحريك مؤشر مجموعة البيانات لتحديد موقع مجموعة البيانات. يوضح المثال 1 مثالاً لإرجاع كائنات ArrayList متعددة مكتوبة بقوة. يمكن أن يؤدي إرجاع البيانات التي تحتاجها فقط من قاعدة البيانات إلى تقليل استهلاك ذاكرة الخادم الخاص بك بشكل كبير.
2. ترحيل البيانات
آسيا والمحيط الهادئ. تتمتع DataGrid الخاصة بـ NET بميزة مفيدة جدًا: الترحيل. إذا كانت DataGrid تسمح بالترحيل، فإنها ستقوم فقط بتنزيل بيانات صفحة معينة في وقت معين، بالإضافة إلى أنها تحتوي على شريط تنقل لترحيل البيانات، مما يسمح لك باختيار تصفح صفحة معينة، وتنزيل صفحة واحدة فقط منها. البيانات في وقت واحد.
لكن له عيبًا صغيرًا، وهو أنه يجب عليك ربط كافة البيانات بـ DataGrid. بمعنى آخر، يجب أن تقوم طبقة البيانات الخاصة بك بإرجاع كافة البيانات، ثم تقوم DataGrid بتصفية البيانات المطلوبة بواسطة الصفحة الحالية وعرضها. إذا كانت هناك مجموعة نتائج مكونة من 10000 سجل تحتاج إلى ترقيم الصفحات باستخدام DataGrid، بافتراض أن DataGrid يعرض فقط 25 قطعة من البيانات لكل صفحة، فهذا يعني أنه سيتم تجاهل 9975 قطعة من البيانات في كل طلب. يجب أن يقوم كل طلب بإرجاع مجموعة البيانات الكبيرة هذه، والتي لها تأثير كبير على أداء التطبيق.
الحل الجيد هو كتابة إجراء مخزن للترحيل. المثال 2 هو إجراء مخزن للترحيل لجدول الطلبات في قاعدة بيانات Northwind. ما عليك سوى تمرير رقم الصفحة الحالية وعدد العناصر المعروضة في كل صفحة، وسيقوم الإجراء المخزن بإرجاع النتائج المقابلة.
من جانب الخادم، قمت بكتابة عنصر تحكم ترحيل خصيصًا للتعامل مع ترحيل البيانات. هنا، استخدمت الطريقة الأولى وأعدت مجموعتي نتائج في إجراء مخزن: العدد الإجمالي لسجلات البيانات ومجموعة النتائج المطلوبة.
يعتمد العدد الإجمالي للسجلات التي يتم إرجاعها على الاستعلام الذي يتم تنفيذه، على سبيل المثال، يمكن أن يحد شرط المكان من حجم مجموعة النتائج التي يتم إرجاعها. نظرًا لأنه يجب حساب العدد الإجمالي للصفحات استنادًا إلى حجم سجلات مجموعة البيانات في واجهة الترحيل، فيجب إرجاع عدد السجلات في مجموعة النتائج. على سبيل المثال، إذا كان هناك إجمالي 1,000,000 سجل، إذا كنت تستخدم شرط المكان، فيمكنك التصفية لإرجاع 1000 سجل فقط، ويجب أن يعرف منطق الترحيل الخاص بالإجراء المخزن كيفية إرجاع البيانات التي يجب عرضها.
3. تجمع الاتصال
يعد استخدام TCP لتوصيل تطبيقك بقاعدة البيانات أمرًا مكلفًا (ويستغرق وقتًا طويلاً). يمكن لمطوري Microsoft استخدام تجمعات الاتصال لإعادة استخدام اتصالات قاعدة البيانات. بدلاً من استخدام TCP للاتصال بقاعدة البيانات لكل طلب، يقوم تجمع الاتصال بإنشاء اتصال TCP جديد فقط في حالة عدم وجود اتصال صالح. عند إغلاق الاتصال، سيتم وضعه في التجمع وسيظل محتفظًا بالاتصال بقاعدة البيانات، وبالتالي تقليل عدد اتصالات TCP بقاعدة البيانات.
بالطبع، يجب عليك الانتباه إلى تلك الاتصالات التي نسيت إغلاقها، ويجب عليك إغلاقها مباشرة بعد كل استخدام. ما أريد التأكيد عليه هو: بغض النظر عما يقوله أي شخص، فإن GC (مجمع البيانات المهملة) في إطار عمل .net سيستدعي دائمًا أسلوب الإغلاق أو التخلص من كائن الاتصال لإغلاق اتصالك بشكل صريح بعد الانتهاء من استخدام كائن الاتصال. لا تتوقع أن يغلق CLR الاتصال خلال الوقت الذي تتخيله، على الرغم من أن CLR سيدمر الكائن في النهاية ويغلق الاتصال، إلا أننا لسنا متأكدين من الوقت الذي سيفعل فيه هذه الأشياء.
لاستخدام تحسين تجمع الاتصالات، توجد قاعدتان أولاً، افتح الاتصال، وقم بمعالجة البيانات، ثم قم بإغلاق الاتصال. إذا كان عليك فتح الاتصال أو إغلاقه عدة مرات لكل طلب، فهذا أفضل من فتح اتصال جانبي طوال الوقت وتمريره إلى كل طريقة. ثانيًا، استخدم نفس سلسلة الاتصال (أو نفس معرف المستخدم، عند استخدام المصادقة المتكاملة). إذا كنت لا تستخدم نفس سلسلة الاتصال، على سبيل المثال، إذا كنت تستخدم سلسلة اتصال بناءً على المستخدم الذي قام بتسجيل الدخول، فلن يستفيد هذا من ميزات التحسين الخاصة بتجمع الاتصال. إذا كنت تستخدم وسائط متكاملة، فلن تتمكن من الاستفادة الكاملة من وظيفة التحسين الخاصة بتجمع الاتصال نظرًا لوجود العديد من المستخدمين. يوفر .NET CLR عدادًا لأداء البيانات، وهو أمر مفيد للغاية عندما نحتاج إلى تتبع خصائص أداء البرنامج، بما في ذلك تتبع تجمع الاتصالات.
عندما يتصل تطبيقك بمورد على جهاز آخر، مثل قاعدة البيانات، يجب عليك التركيز على تحسين الوقت الذي يستغرقه الاتصال بالمورد، والوقت الذي يستغرقه تلقي البيانات وإرسالها، وعدد مرات الرجوع . يعد تحسين كل خطوة عملية في تطبيقك هو نقطة البداية لتحسين أداء تطبيقك.
تحتوي طبقة التطبيق على منطق الاتصال بطبقة البيانات، ونقل البيانات إلى مثيلات الفئات المقابلة، ومعالجة الأعمال. على سبيل المثال، في Community Server، تحتاج إلى تجميع مجموعة المنتديات أو المواضيع، ثم تطبيق منطق الأعمال، مثل التفويض، والأهم من ذلك، أنك تحتاج إلى إكمال منطق التخزين المؤقت هنا.
4. أسب. NET ذاكرة التخزين المؤقت API
قبل كتابة تطبيق، أول شيء عليك القيام به هو جعل التطبيق يستخدم إمكانات التخزين المؤقت لـ ASP.NET إلى الحد الأقصى.
إذا كان سيتم تشغيل المكون الخاص بك في تطبيق Asp.net، فأنت تحتاج فقط إلى الإشارة إلى System.Web.dll في مشروعك. ثم استخدم خاصية HttpRuntime.Cache للوصول إلى ذاكرة التخزين المؤقت (يمكن الوصول إليها أيضًا من خلال Page.Cache أو HttpContext.Cache).
هناك عدة قواعد للتخزين المؤقت للبيانات. أولاً، يمكن استخدام البيانات بشكل متكرر ويمكن تخزين هذه البيانات مؤقتًا. ثانيًا، يكون تكرار الوصول إلى البيانات مرتفعًا جدًا، أو أن تكرار الوصول إلى جزء من البيانات ليس مرتفعًا، ولكن دورة حياتها طويلة جدًا، ومن الأفضل تخزين هذه البيانات مؤقتًا. المشكلة الثالثة هي مشكلة يتم تجاهلها غالبًا. في بعض الأحيان نقوم بتخزين الكثير من البيانات في ذاكرة التخزين المؤقت. عادة، إذا تجاوزت البيانات التي تريد تخزينها مؤقتًا 800 ميجا، فسيحدث خطأ في تجاوز سعة الذاكرة. لذا فإن ذاكرة التخزين المؤقت محدودة. بمعنى آخر، يجب عليك تقدير حجم مجموعة ذاكرة التخزين المؤقت وتحديد حجم مجموعة ذاكرة التخزين المؤقت بأقل من 10، وإلا فقد يتسبب ذلك في حدوث مشكلات. في Asp.net، إذا كانت ذاكرة التخزين المؤقت كبيرة جدًا، فسيتم الإبلاغ عن خطأ تجاوز سعة الذاكرة، خاصة إذا تم تخزين كائن DataSet كبير مؤقتًا.
فيما يلي بعض آليات التخزين المؤقت المهمة التي يجب عليك فهمها. أولاً، تطبق ذاكرة التخزين المؤقت مبدأ "الأحدث استخدامًا" (خوارزمية الأقل استخدامًا مؤخرًا)، وعندما يكون هناك عدد قليل من ذاكرة التخزين المؤقت، فإنها ستقوم تلقائيًا بمسح ذاكرة التخزين المؤقت غير المفيدة بالقوة. ثانيًا، مبدأ "التبعيات المشروطة" هو الإزالة القسرية (تبعيات انتهاء الصلاحية)، وقد تكون الشروط هي الوقت والكلمات الرئيسية والملفات. الوقت كشرط هو الأكثر استخدامًا. تمت إضافة شرط أقوى في asp.net2.0، وهو شرط قاعدة البيانات. عندما تتغير البيانات الموجودة في قاعدة البيانات، يتم مسح ذاكرة التخزين المؤقت بشكل إجباري. لإلقاء نظرة أكثر تعمقًا على التبعيات الشرطية لقاعدة البيانات، راجع العمود المتطور لـ Dino Esposito في عدد يوليو 2004 من مجلة MSDN. تظهر بنية ذاكرة التخزين المؤقت لـ Asp.net في الشكل أدناه:
5. التخزين المؤقت للطلب المسبق
لقد ذكرت سابقًا أنه حتى لو قمنا فقط بإجراء تحسين بسيط في الأداء في بعض الأماكن، فيمكننا الحصول على تحسين كبير في الأداء. أحب حقًا استخدام التخزين المؤقت للطلب المسبق لتحسين أداء البرنامج.
على الرغم من أن واجهة برمجة تطبيقات ذاكرة التخزين المؤقت مصممة لحفظ البيانات لفترة زمنية معينة، إلا أن ذاكرة التخزين المؤقت للطلب المسبق تحفظ فقط محتوى طلب معين لفترة زمنية معينة. إذا كان تكرار الوصول لطلب معين مرتفع، ولا يحتاج هذا الطلب إلا إلى استخراج البيانات أو تطبيقها أو تعديلها أو تحديثها مرة واحدة. ومن ثم يمكن تخزين الطلب مؤقتًا مسبقًا. دعونا نعطي مثالا للتوضيح.
في تطبيق منتدى CS، يتطلب التحكم في الخادم لكل صفحة بيانات مخصصة لتحديد مظهرها، وتحديد ورقة الأنماط التي سيتم استخدامها والأشياء المخصصة الأخرى. قد يلزم حفظ بعض البيانات هنا لفترة طويلة، ولكن في بعض الأحيان قد لا يلزم حفظها. على سبيل المثال، يجب تطبيق بيانات السطح الخاصة بعنصر التحكم مرة واحدة فقط ويمكن استخدامها طوال الوقت.
لتنفيذ التخزين المؤقت للطلب المسبق، استخدم فئة HttpContext الخاصة بـ Asp.net. يتم إنشاء مثيل لفئة HttpContext في كل طلب ويمكن الوصول إليه من خلال خاصية HttpContext.Current في أي مكان أثناء الطلب. تحتوي فئة HttpContext على خاصية مجموعة العناصر، وتتم إضافة كافة الكائنات والبيانات إلى هذه المجموعة وتخزينها مؤقتًا أثناء الطلب. مثلما تستخدم ذاكرة التخزين المؤقت لتخزين البيانات التي يتم الوصول إليها بشكل متكرر، يمكنك استخدام HttpContext.Items لتخزين البيانات الأساسية المستخدمة في كل طلب. المنطق الكامن وراء ذلك بسيط: نضيف بيانات إلى HttpContext.Items، ثم نقرأ البيانات منها.
6. معالجة الخلفية
باستخدام الطريقة المذكورة أعلاه، يجب أن يعمل تطبيقك بسرعة كبيرة، أليس كذلك؟ ولكن في مرحلة ما، قد يتم تنفيذ مهمة تستغرق وقتًا طويلاً جدًا في طلب في البرنامج. مثل إرسال رسائل البريد الإلكتروني أو التحقق من صحة البيانات المقدمة وما إلى ذلك.
عندما قمنا بدمج الإصدار 1.0 من منتديات asp.net في CS، وجدنا أن إرسال مشاركة جديدة سيكون بطيئًا للغاية. في كل مرة تتم إضافة منشور جديد، يجب على التطبيق أولاً التحقق مما إذا كان المنشور مكررًا، ثم تصفيته باستخدام مرشح "الكلمة السيئة"، والتحقق من رمز مرفق الصورة، وفهرسة المنشور، وإضافته إلى قائمة الانتظار المناسبة، والتحقق من صحته مرفقه، وأخيرًا، أرسل البريد الإلكتروني إلى صندوق بريد المشترك الخاص به. من الواضح أن هذا يتطلب الكثير من العمل.
والنتيجة هي أنه يقضي الكثير من الوقت في فهرسة وإرسال رسائل البريد الإلكتروني. فهرسة المنشورات هي عملية تستغرق وقتًا طويلاً، وإرسال رسائل البريد الإلكتروني للمشتركين يتطلب الاتصال بخدمة SMTP ثم إرسال بريد إلكتروني إلى كل مشترك، ومع زيادة عدد المشتركين، سيزداد الوقت المستغرق لإرسال رسائل البريد الإلكتروني.
لا يلزم تشغيل فهرسة رسائل البريد الإلكتروني وإرسالها عند كل طلب، ومن الناحية المثالية، نرغب في معالجة هذه العمليات على دفعات، وإرسال 25 رسالة بريد إلكتروني فقط في المرة الواحدة أو إرسال جميع رسائل البريد الإلكتروني الجديدة كل 5 دقائق. قررنا استخدام نفس الكود المستخدم في ذاكرة التخزين المؤقت لنموذج قاعدة البيانات، لكنه فشل، لذا كان علينا العودة إلى VS.NET 2005.
نجد فئة Timer ضمن مساحة الاسم System.Threading. هذه الفئة مفيدة جدًا، لكن القليل من الناس يعرفونها، وعدد أقل من مطوري الويب يعرفونها. بمجرد إنشاء مثيل لهذه الفئة، ستقوم فئة Timer باستدعاء وظيفة رد الاتصال المحددة من مؤشر ترابط في تجمع مؤشرات الترابط في كل وقت محدد. وهذا يعني أنه يمكن تشغيل تطبيق ASP.NET الخاص بك حتى في حالة عدم وجود طلبات. هذا هو الحل الذي سنتعامل معه لاحقا. يمكنك تشغيل أعمال الفهرسة وإرسال البريد الإلكتروني في الخلفية بدلاً من الاضطرار إلى تنفيذها عند كل طلب.
هناك مشكلتان في تقنية التشغيل في الخلفية. الأولى هي أنه عند إلغاء تثبيت مجال التطبيق الخاص بك، سيتوقف مثيل فئة Timer عن العمل. أي أنه لن يتم استدعاء أسلوب رد الاتصال. بالإضافة إلى ذلك، نظرًا لوجود العديد من الخيوط التي تعمل في كل عملية من عمليات CLR، سيكون من الصعب عليك الحصول على مؤشر ترابط لينفذه Timer، أو سيتمكن من تنفيذه، لكنه سيتأخر. يجب أن تستخدم طبقة Asp.net هذه التقنية بأقل قدر ممكن لتقليل عدد سلاسل العمليات في العملية، أو السماح فقط للطلبات باستخدام جزء صغير من سلاسل الرسائل. بالطبع، لا يمكنك استخدامه إلا إذا كان لديك الكثير من العمل غير المتزامن.
لا توجد مساحة كافية لنشر الكود هنا. يمكنك تنزيل نموذج البرنامج من http://www.rob-howard.net/ . يرجى تنزيل نموذج برنامج Blackbelt TechEd 2004.
7. التخزين المؤقت لمخرجات الصفحة وخدمات الوكيل
Asp.net هي طبقة الواجهة الخاصة بك (أو ينبغي أن تكون كذلك)، فهي تحتوي على الصفحات وعناصر تحكم المستخدم وعناصر تحكم الخادم (HttpHandlers وHttpModules) والمحتوى الذي ينشئونه. إذا كانت لديك صفحة Asp.net تقوم بإخراج بيانات html أو xml أو imgae أو بيانات أخرى، وتستخدم التعليمات البرمجية لإنشاء نفس محتوى الإخراج لكل طلب، فمن الضروري أن تفكر في استخدام التخزين المؤقت لمخرجات الصفحة.
يمكنك القيام بذلك ببساطة عن طريق نسخ سطر التعليمات البرمجية التالي إلى صفحتك:
<%@ PageOutputCache VaryByParams=”none” Duration=”60” %>
يمكنك استخدام الصفحة التي تم إنشاؤها في الطلب الأول بشكل فعال لإخراج المحتوى المخبأ وإعادة إنشاء محتوى الصفحة بعد 60 ثانية. يتم تنفيذ هذه التقنية فعليًا باستخدام واجهة برمجة تطبيقات ذاكرة التخزين المؤقت ذات المستوى المنخفض. هناك العديد من المعلمات التي يمكن تكوينها للتخزين المؤقت لمخرجات الصفحة، مثل معلمة VaryByParams المذكورة أعلاه. تشير هذه المعلمة إلى وقت تشغيل شروط إعادة الإخراج. يمكنك أيضًا تحديد التخزين المؤقت للإخراج في وضع طلب Http Get أو Http Post. على سبيل المثال، عندما نقوم بتعيين هذه المعلمة إلى VaryByParams="Report"، سيتم تخزين الإخراج المطلوب بواسطة default.aspx?Report=1 أو default.aspx?Report=2 مؤقتًا. يمكن أن تكون قيمة المعلمة عبارة عن معلمات متعددة مفصولة بفواصل منقوطة.
لا يدرك الكثير من الأشخاص أنه عند استخدام التخزين المؤقت لمخرجات الصفحة، سيقوم ASP.NET أيضًا بإنشاء مجموعة رؤوس HTTP (رأس HTTP) وحفظها في خادم ذاكرة التخزين المؤقت المتلقي للمعلومات، ويمكن استخدام هذه المعلومات لأمان إنترنت Microsoft ولتسريع عملية سرعة استجابة الخادم. عند إعادة تعيين رأس ذاكرة التخزين المؤقت لـ HTTP، سيتم تخزين المحتوى المطلوب مؤقتًا في مورد الشبكة. عندما يطلب العميل المحتوى مرة أخرى، لن يحصل بعد ذلك على المحتوى من الخادم الأصلي، بل سيحصل على المحتوى مباشرة من ذاكرة التخزين المؤقت.
على الرغم من أن استخدام التخزين المؤقت لمخرجات الصفحة لا يؤدي إلى تحسين أداء التطبيق الخاص بك، إلا أنه يقلل من عدد مرات تحميل محتوى الصفحة المخزنة مؤقتًا من الخادم. وبطبيعة الحال، يقتصر هذا على صفحات التخزين المؤقت التي يمكن للمستخدمين المجهولين الوصول إليها. لأنه بمجرد تخزين الصفحة مؤقتًا، لن يكون من الممكن إجراء عمليات الترخيص.
8. استخدم التخزين المؤقت لـ Kernel لـ IIS6.0
إذا كان التطبيق الخاص بك لا يعمل في IIS 6.0 (Windows Server 2003)، فقد فقدت بعض الطرق الرائعة لتحسين أداء التطبيق. في الطريقة السابعة تحدثت عن كيفية استخدام التخزين المؤقت لمخرجات الصفحة لتحسين أداء التطبيق. في IIS5.0، عندما يأتي طلب إلى IIS، سيقوم IIS بنقله إلى asp.net. عند تطبيق ذاكرة التخزين المؤقت لإخراج الصفحة، سيتلقى HttpHandler في ASP.NET الطلب، وسيقوم HttpHandler بنقل المحتوى من ذاكرة التخزين المؤقت. أخرجه وأرجعه .
إذا كنت تستخدم IIS6.0، فهو يتمتع بميزة جيدة جدًا تسمى Kernel Caching، ولا يلزمك تعديل أي كود في برنامج asp.net. عندما يتلقى asp.net طلبًا مخبأً، ستحصل ذاكرة التخزين المؤقت Kernel الخاصة بـ IIS على نسخة منه من ذاكرة التخزين المؤقت. عندما يأتي طلب من الشبكة، ستحصل طبقة Kernel على الطلب إذا تم تخزين الطلب مؤقتًا، فسوف تقوم بإرجاع البيانات المخزنة مؤقتًا مباشرةً، وبذلك تكون قد انتهيت. وهذا يعني أنه عند استخدام IIS Kernel Caching للتخزين المؤقت لمخرجات الصفحة، سوف تحصل على تحسينات مذهلة في الأداء. عند تطوير asp.net لـ VS.NET 2005، كنت مدير برنامج مسؤولًا بشكل خاص عن أداء asp.net. استخدم المبرمجون لدي هذه الطريقة، وبحثت في جميع بيانات التقارير اليومية ووجدت نتائج استخدام التخزين المؤقت لنموذج kernel الأسرع. ومن السمات المشتركة بينها أن طلبات الشبكة واستجاباتها كبيرة، لكن IIS يستهلك 5% فقط من موارد وحدة المعالجة المركزية. هذا مذهل. هناك العديد من الأسباب التي تجعلك تستخدم IIS 6.0، لكن صرف kernel هو الأفضل.
9. ضغط البيانات باستخدام Gzip
ما لم يكن استخدام وحدة المعالجة المركزية لديك مرتفعًا جدًا، فمن الضروري استخدام تقنيات لتحسين أداء الخادم. يمكن أن يؤدي استخدام gzip لضغط البيانات إلى تقليل كمية البيانات التي ترسلها إلى الخادم، وتحسين سرعة تشغيل الصفحة، وكذلك تقليل حركة مرور الشبكة. تعتمد كيفية ضغط البيانات بشكل أفضل على البيانات التي تريد إرسالها، وما إذا كان متصفح العميل يدعمها (يرسل IIS بيانات مضغوطة بـ gzip إلى العميل، ويجب أن يدعم العميل gzip لتحليلها، وIE6.0 وFirefox). بهذه الطريقة، يمكن لخادمك الاستجابة لمزيد من الطلبات في الثانية، وبالمثل، يمكنك أيضًا تقليل كمية البيانات المرسلة في الاستجابة، ويمكنك إرسال المزيد من الطلبات.
أخبار جيدة، تم دمج ضغط gzip في IIS6.0، وهو أفضل من gzip في IIS5.0. لسوء الحظ، لتمكين ضغط gzip في IIS 6.0، لا يمكنك تعيينه في مربع حوار الخصائص الخاص بـ IIS 6.0. قام فريق تطوير IIS بتطوير وظيفة ضغط gzip، لكنهم نسوا تسهيل الأمر على المسؤولين لتمكينها في نافذة المسؤول. لتمكين ضغط gzip، يمكنك فقط تعديل تكوينه في ملف تكوين IIS6.0 xml.
بالإضافة إلى قراءة هذه المقالة، يجب أن أقرأ المقالة <<IIS6 Compression>> التي كتبها براد ويلسون ( http://www.dotnetdevs.com/articles/IIS6compression.aspx )؛ وهناك أيضًا مقالة تقدم المعرفة الأساسية من ضغط aspx. تمكين ضغط ASPX في IIS. لكن انتبه إلى أن الضغط الديناميكي وصرف kernel يتعارضان في IIS6.
10. عرض حالة عناصر تحكم الخادم
ViewState هي ميزة في asp.net تُستخدم لحفظ قيمة الحالة المستخدمة لإنشاء صفحة في حقل مخفي. عند إعادة نشر الصفحة مرة أخرى إلى الخادم، يقوم الخادم بتحليل البيانات الموجودة في ViewState والتحقق منها وتطبيقها لاستعادة شجرة التحكم الخاصة بالصفحة. تعد ViewState ميزة مفيدة جدًا يمكنها الحفاظ على حالة العميل دون استخدام ملفات تعريف الارتباط أو ذاكرة الخادم. تستخدم معظم عناصر التحكم في الخادم ViewState للاحتفاظ بقيم حالة العناصر التي تتفاعل مع المستخدم على الصفحة. على سبيل المثال، لحفظ رقم الصفحة الحالية للترحيل.
سيؤدي استخدام ViewState إلى بعض الآثار السلبية. أولاً، يزيد من استجابة الخادم وأوقات الطلب. ثانيًا، تضيف كل عملية إعادة نشر وقتًا لتسلسل البيانات وإلغاء تسلسلها. وأخيرًا، فإنه يستهلك أيضًا المزيد من الذاكرة على الخادم.
تميل العديد من عناصر تحكم الخادم إلى استخدام ViewState، مثل DataGrid المعروف، وفي بعض الأحيان لا تكون هناك حاجة لاستخدامه. يتم تمكين ViewState افتراضيًا إذا كنت لا تريد استخدام ViewState، فيمكنك إيقاف تشغيله على مستوى عنصر التحكم أو الصفحة. في عنصر التحكم، ما عليك سوى تعيين خاصية EnableViewState على False، ويمكنك أيضًا تعيينها في الصفحة لتوسيع نطاقها ليشمل الصفحة بأكملها:
<%@ الصفحة EnableViewState=”false” %>
إذا كانت الصفحة لا تتطلب إعادة النشر أو تم عرض الصفحة مع عناصر التحكم في كل مرة يتم طلبها فيها. يجب عليك إيقاف تشغيل ViewState على مستوى الصفحة.
تلخيص
أنا فقط أقدم بعض النصائح التي أعتقد أنها ستساعد في تحسين كتابة تطبيقات ASP.NET عالية الأداء. إن النصائح الخاصة بتحسين أداء ASP.NET المذكورة في هذه المقالة هي مجرد نقطة بداية. لمزيد من المعلومات، يرجى الرجوع إلى "تحسين ASP. كتاب "الأداء" NET. فقط من خلال ممارستك الخاصة يمكنك العثور على التقنيات التي ستكون مفيدة للغاية لمشروعك. ومع ذلك، يمكن أن تكون هذه النصائح بمثابة دليل في رحلة التطوير الخاصة بك. في تطوير البرمجيات، لا شيء من هذا مفيد تمامًا لأن كل مشروع مختلف عن الآخر.
