28 قاعدة لتحسين أداء ASP موصى بها من قبل Microsoft

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

توضح هذه المقالة تقنيات تحسين تطبيقات ASP وإصدار البرمجة النصية Visual Basic® (VBScript). تتناول هذه المقالة عددًا من المزالق. لقد تم اختبار الاقتراحات المذكورة في هذه المقالة على http://www.microsoft.com ومواقع أخرى، وكانت النتائج هامة للغاية. تفترض هذه المقالة أن لديك بالفعل فهمًا أساسيًا لتطوير ASP، بما في ذلك VBScript و/أو JScript وتطبيق ASP وجلسة ASP والكائنات الأخرى المتأصلة في ASP (الطلب والاستجابة والخادم).

عادةً ما يعتمد أداء ASP بشكل أساسي على العديد من العوامل غير رمز ASP نفسه. بدلاً من إدراج كافة المعلومات في مقالة واحدة، نقوم بإدراج الموارد المتعلقة بالأداء في نهاية المقالة. تغطي هذه الارتباطات موضوعات ASP وغير ASP، بما في ذلك كائنات بيانات ActiveX® (ADO) ونموذج كائن المكون (COM) وقواعد البيانات وتكوين خادم معلومات الإنترنت (IIS). هذه بعض الروابط المفضلة لدينا - تأكد من التحقق منها.

نصيحة 1: تخزين البيانات المستخدمة بشكل متكرر على خادم الويب

تقوم صفحة ASP النموذجية باسترداد البيانات من مخزن البيانات الخلفي ثم تحويل النتائج إلى لغة توصيف النص التشعبي (HTML). بغض النظر عن سرعة قاعدة البيانات، فإن استرداد البيانات من الذاكرة يكون دائمًا أسرع بكثير من استرداد البيانات من مخزن البيانات الخلفي. تعد قراءة البيانات من محرك الأقراص الثابتة المحلي أسرع بشكل عام من استرداد البيانات من قاعدة البيانات. لذلك، غالبًا ما يمكن تحسين الأداء عن طريق تخزين البيانات مؤقتًا على خادم الويب (المخزنة في الذاكرة أو على القرص).

التخزين المؤقت هو الطريقة التقليدية لاستبدال المساحة بالوقت. إذا قمت بتخزين المحتوى الصحيح مؤقتًا، يمكنك رؤية تحسن كبير في الأداء. لكي يكون التخزين المؤقت فعالاً، يجب حفظ البيانات التي يتم إعادة استخدامها بشكل متكرر، وتتطلب إعادة حساب هذه البيانات حملًا كبيرًا (معتدلًا). إذا كانت ذاكرة التخزين المؤقت تحتوي على جميع البيانات القديمة، فسوف يتسبب ذلك في إهدار الذاكرة.

تعد البيانات التي تتغير بشكل غير متكرر مرشحًا جيدًا للتخزين المؤقت لأنه لا داعي للقلق بشأن مزامنة تلك البيانات مع قاعدة البيانات بمرور الوقت. تعد قوائم مربعات التحرير والسرد، والجداول المرجعية، وأجزاء DHTML، وسلاسل لغة التوصيف القابلة للتوسيع (XML)، وعناصر القائمة، ومتغيرات تكوين الموقع (بما في ذلك أسماء مصادر البيانات (DSNs)، وعناوين بروتوكول الإنترنت (IP)، ومسارات الويب) كلها ذاكرات تخزين مؤقت جيدة. محتوى. لاحظ أنه يمكنك تخزين "تمثيل" البيانات مؤقتًا دون تخزين البيانات نفسها مؤقتًا. إذا كانت صفحة ASP نادرًا ما تتغير وكان تخزينها مؤقتًا مكلفًا (على سبيل المثال، كتالوج المنتج بأكمله)، فيجب عليك إنشاء HTML مقدمًا بدلاً من إعادة عرضه استجابة لكل طلب.

أين يجب تخزين البيانات مؤقتًا وما هي استراتيجيات التخزين المؤقت الموجودة؟ عادةً ما يتم تخزين البيانات مؤقتًا في ذاكرة أو قرص خادم الويب. تغطي النصيحتان التاليتان كلتا الطريقتين.

نصيحة 2: تخزين البيانات المستخدمة بشكل متكرر في التطبيق أو كائنات الجلسة.

توفر كائنات تطبيق ASP وجلسة العمل حاويات مناسبة للتخزين المؤقت للبيانات في الذاكرة. يمكنك تعيين البيانات إلى كائنات التطبيق والجلسة، وتظل البيانات في الذاكرة بين مكالمات HTTP. يتم تخزين بيانات الجلسة بشكل منفصل لكل مستخدم، بينما تتم مشاركة بيانات التطبيق بين جميع المستخدمين.

متى يجب تحميل البيانات في التطبيق أو الجلسة؟ عادةً، يتم تحميل البيانات عند بدء تشغيل التطبيق أو الجلسة. لتحميل البيانات أثناء بدء تشغيل التطبيق أو الجلسة، قم بإضافة التعليمات البرمجية المناسبة إلى Application_OnStart() أو Session_OnStart() على التوالي. يجب أن تكون هذه الوظائف في Global.asa، ​​إذا لم يكن الأمر كذلك، يمكنك إضافتها. يمكن أيضًا تحميل هذه البيانات عند الحاجة إليها لأول مرة. للقيام بذلك، أضف بعض التعليمات البرمجية إلى صفحة ASP (أو اكتب وظيفة برنامج نصي قابلة لإعادة الاستخدام) للتحقق من وجود البيانات، وإذا لم يكن الأمر كذلك، قم بتحميل البيانات. هذه تقنية أداء تقليدية تسمى "التقييم البطيء" - عدم حساب القيمة حتى تعرف أنك بحاجة إليها. على سبيل المثال:

<%
وظيفة GetEmploymentStatusList
خافت د
د = التطبيق (؟ قائمة حالة التوظيف؟)
إذا د =؟؟ثم
' الدالة FetchEmploymentStatusList (غير معروضة)
'جلب البيانات من قاعدة البيانات، وإرجاع صفيف
د = FetchEmploymentStatusList()
التطبيق (؟EmploymentStatusList؟) = د
نهاية إذا
GetEmploymentStatusList = د
وظيفة النهاية
%>
يمكن كتابة وظائف مماثلة لكل كتلة بيانات مطلوبة.

بأي تنسيق يجب تخزين البيانات؟ يمكن تخزين أي نوع متغير لأن كافة متغيرات البرنامج النصي هي أنواع مختلفة. على سبيل المثال، يمكنك تخزين السلاسل أو الأعداد الصحيحة أو المصفوفات. عادةً، سوف تقوم بتخزين محتويات مجموعة سجلات ADO في أحد أنواع المتغيرات هذه. للحصول على البيانات من مجموعة سجلات ADO، يمكنك نسخ البيانات يدويًا إلى متغيرات VBScript، حقل واحد في كل مرة. من الأسرع والأسهل استخدام إحدى وظائف ثبات مجموعة سجلات ADO GetRows() أو GetString() أو Save() (ADO 2.5). التفاصيل خارج نطاق هذه المقالة، ولكن فيما يلي مثال لوظيفة تستخدم GetRows() لإرجاع صفيف من بيانات مجموعة السجلات:

' Get Recordset, return as a Array
الدالة FetchEmploymentStatusList
خافتات
تعيين rs = CreateObject(?ADODB.Recordset?)
rs.Open ؟اختر اسم الحالة، معرف الحالة من حالة الموظف؟، _
?dsn=employees;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GetRows() ؟ إرجاع البيانات كمصفوفة
إغلاق
سيترز = لا شيء

وظيفة النهاية

على تحسين المثال أعلاه عن طريق تخزين HTML مؤقتًا كقائمة بدلاً من مصفوفة. فيما يلي مثال بسيط:

'احصل على مجموعة السجلات، وارجع كقائمة خيارات HTML
الدالة FetchEmploymentStatusList
خافت روبية، fldName، s
تعيين rs = CreateObject(?ADODB.Recordset?)
rs.Open ؟اختر اسم الحالة، معرف الحالة من حالة الموظف؟،_
?dsn=employees;uid=sa;pwd=;?
s = ?<select name=??EmploymentStatus??>?&vbCrLf
قم بتعيين fldName = rs.Fields(?StatusName?) 'ربط حقل ADO
افعل حتى rs.EOF
'السطر التالي ينتهك عدم القيام بسلسلة Concats،
"ولكن لا بأس لأننا نقوم ببناء ذاكرة تخزين مؤقت
s = s & <option>? & fldName & ?</option>?
rs.MoveNext
حلقة
s = s & ?</select>?
إغلاق
Set rs = Nothing 'راجع الإصدار مبكرًا
FetchEmploymentStatusList = s ' إرجاع البيانات كسلسلة
وظيفة النهاية
في ظل الظروف المناسبة، يمكن تخزين مجموعة سجلات ADO نفسها مؤقتًا في نطاق التطبيق أو جلسة العمل. هناك تحذيران:

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

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

<%
"لم تظهر معالجة الخطأ..."
Const UPDATE_INTERVAL = 300 'فاصل التحديث، بالثواني

' وظيفة لإرجاع قائمة حالة التوظيف
وظيفة GetEmploymentStatusList
تحديث حالة التوظيف
GetEmploymentStatusList = التطبيق(؟EmploymentStatusList؟)
وظيفة النهاية

' قم بتحديث البيانات المخزنة مؤقتًا بشكل دوري
التحديث الفرعي قائمة حالة التوظيف
خافت د، strLastUpdate
strLastUpdate = التطبيق(؟LastUpdate؟)
إذا (strLastUpdate = ؟؟) أو _
(UPDATE_INTERVAL < DateDiff(?s?, strLastUpdate, Now)) ثم

ملاحظة: قد يتم إجراء مكالمتين أو أكثر هنا، وهذا أمر جيد وسيحدث ببساطة
' يؤدي إلى بعض عمليات الجلب غير الضرورية (يوجد حل بديل لهذا)

' وظيفة FetchEmploymentStatusList (غير معروضة)
'جلب البيانات من قاعدة البيانات، وإرجاع صفيف
d = FetchEmploymentStatusList()

' قم بتحديث كائن التطبيق استخدم Application.Lock().
" لضمان بيانات متسقة
التطبيق.القفل
Application(?EmploymentStatusList?) = Events
التطبيق(؟LastUpdate؟) = CStr(الآن)
التطبيق.فتح
نهاية إذا
نهاية الفرعية
راجع أسرع ListBox في العالم مع بيانات التطبيق، والذي يحتوي أيضًا على مثال.

انتبه إلى أن التخزين المؤقت للصفائف الكبيرة في جلسة العمل أو كائنات التطبيق ليس ممارسة جيدة. يتطلب بناء جملة لغة البرمجة النصية نسخ المصفوفة بأكملها مؤقتًا قبل الوصول إلى أي عنصر في المصفوفة. على سبيل المثال، إذا قمت بتخزين مصفوفة مكونة من 100000 عنصر من السلاسل التي تقوم بتعيين الرموز البريدية الأمريكية لمحطات الطقس المحلية في كائن تطبيق، فيجب على ASP أولاً نسخ جميع محطات الطقس البالغ عددها 100000 إلى صفيف مؤقت، وعندها فقط يمكن استخراج سلسلة. في هذه الحالة، سيكون من الأفضل إنشاء مكون مخصص بطريقة مخصصة لتخزين محطة الطقس - أو استخدام مكون القاموس.

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

نصيحة 3: تخزين البيانات وHTML مؤقتًا على قرص خادم الويب

في بعض الأحيان قد يكون هناك الكثير من البيانات التي يمكن تخزينها مؤقتًا في الذاكرة. "عدد كبير جدًا" هو مجرد وسيلة للقول أن الأمر يعتمد على مقدار الذاكرة التي تريد استهلاكها، بالإضافة إلى عدد العناصر التي تحتاج إلى تخزينها مؤقتًا وعدد المرات التي تريد استردادها فيها. على أية حال، إذا كانت البيانات كبيرة جدًا بحيث لا يمكن تخزينها مؤقتًا في الذاكرة، ففكر في تخزين البيانات مؤقتًا على القرص الصلب لخادم الويب كنص أو ملف XML. يمكن تخزين البيانات مؤقتًا على القرص وفي الذاكرة في نفس الوقت لإنشاء استراتيجية التخزين المؤقت الأكثر ملاءمة لموقعك.

لاحظ أنه عند قياس أداء صفحة ASP واحدة، قد لا يكون استرداد البيانات من القرص بالضرورة أسرع من استرداد البيانات من قاعدة البيانات. لكن التخزين المؤقت يقلل الحمل على قاعدة البيانات والشبكة. وفي ظل الأحمال الثقيلة، يمكن أن يؤدي ذلك إلى تحسين الإنتاجية الإجمالية بشكل كبير. يعد هذا فعالاً للغاية عند التخزين المؤقت لنتائج الاستعلامات الباهظة الثمن (مثل صلات الجداول المتعددة أو الإجراءات المخزنة المركبة) أو مجموعات النتائج الكبيرة. كما هو الحال دائمًا، اختبر إيجابيات وسلبيات العديد من الخيارات.

يوفر ASP وCOM أدوات لإعداد حلول التخزين المؤقت المستندة إلى القرص. تقوم الدالتان Save() وOpen() لمجموعة سجلات ADO بحفظ مجموعات السجلات وتحميلها من القرص. يمكنك استخدام هذه الطرق لإعادة كتابة مثال التعليمات البرمجية في تقنية التخزين المؤقت لبيانات التطبيق أعلاه، باستخدام Save() للملف بدلاً من كتابة التعليمات البرمجية إلى كائن التطبيق.

هناك بعض المكونات الأخرى التي تعمل مع الملفات:

يتيح لك Scripting.FileSystemObject إنشاء الملفات وقراءتها وكتابتها.
يدعم محلل Microsoft® XML (MSXML) المتوفر مع Internet Explorer حفظ مستندات XML وتحميلها.
يعد كائن LookupTable (المستخدم في MSN، على سبيل المثال) هو الخيار الأفضل لتحميل قوائم بسيطة من القرص.
وأخيرًا، فكر في التخزين المؤقت لتمثيل البيانات الموجودة على القرص بدلاً من البيانات نفسها. يمكن تخزين HTML المحول مسبقًا على القرص في ملفات .htm أو .asp، ويمكن أن تشير الارتباطات التشعبية مباشرةً إلى هذه الملفات. يمكنك استخدام الأدوات التجارية، مثل XBuilder، أو ميزة النشر عبر الإنترنت Microsoft® SQL Server® لأتمتة عملية إنشاء HTML. وبدلاً من ذلك، يمكنك وضع مقتطف التعليمات البرمجية لـ HTML في ملف .asp. يمكنك أيضًا استخدام FileSystemObject لقراءة ملفات HTML من القرص، أو استخدام XML لتحويلها مبكرًا.

نصيحة 4: تجنب التخزين المؤقت للمكونات غير السريعة في التطبيق أو كائنات الجلسة

على الرغم من أن التخزين المؤقت للبيانات في كائنات التطبيق أو الجلسة يعد ممارسة جيدة، إلا أن التخزين المؤقت لكائنات COM ينطوي على مخاطر خطيرة. عادةً ما يميل الأشخاص إلى تخزين كائنات COM المستخدمة بشكل متكرر في كائنات التطبيق أو الجلسة. لسوء الحظ، تتسبب العديد من كائنات COM (بما في ذلك كافة الكائنات المكتوبة في Visual Basic 6.0 أو إصدار سابق) في حدوث اختناقات خطيرة عند تخزينها في كائنات التطبيق أو جلسة العمل.

على وجه التحديد، عندما يتم تخزين أي مكون غير رشيق مؤقتًا في كائن الجلسة أو التطبيق، فسيؤدي ذلك إلى اختناق في الأداء. المكون السريع هو مكون يحمل علامة ThreadingModel=Both، والذي يقوم بتجميع منظم ذو ترابط حر (FTM)؛ أو مكون يحمل علامة ThreadingModel=محايد. (النموذج المحايد جديد لنظام التشغيل Windows® 2000 وCOM+.) المكونات التالية ليست سريعة:

المكونات الحرة (ما لم يتم تجميع FTM).
مكونات موضوع الشقة.
مكون مترابطة واحدة.
المكونات التي تم تكوينها (مكتبات Microsoft Transaction Server (MTS)/COM+ وحزم/تطبيقات الخادم) ليست سريعة إلا إذا كانت مؤشرات ترابط محايدة. تعتبر المكونات المترابطة والمكونات الأخرى غير السريعة أكثر ملاءمة لنطاق الصفحة (أي، يتم إنشاؤها وتدميرها على صفحة ASP واحدة).

في IIS 4.0، تعتبر المكونات التي تحمل علامة ThreadingModel=Both سريعة الحركة. في IIS 5.0، هذا وحده لا يكفي. يجب ألا يتم وضع علامة "كلاهما" على المكونات فحسب، بل يجب أيضًا تجميع FTM. توضح المقالة الخاصة بالسرعة كيفية تجميع FTM مع مكونات C++ المكتوبة في مكتبة النماذج النشطة. انتبه إلى أنه إذا قام أحد المكونات بتخزين مؤشرات الواجهة مؤقتًا، فيجب أن تكون هذه المؤشرات نفسها سريعة الحركة أو يجب تخزينها في جدول الواجهة العامة لـ COM (GIT). إذا لم تتمكن من إعادة ترجمة مكون مؤشر ترابط كلا لتجميع FTM، يمكنك وضع علامة على المكون باستخدام ThreadingModel=Neutral. وبدلاً من ذلك، إذا كنت لا تريد أن يقوم IIS بإجراء اختبارات السرعة (وبالتالي، يمكنك السماح بتخزين المكونات غير السريعة في نطاق التطبيق أو الجلسة)، يمكنك تعيين AspTrackThreadingModel إلى True في قاعدة التعريف. لا يوصى بتغيير AspTrackThreadingModel.

سوف يلقي IIS 5.0 خطأ إذا كنت تريد تخزين مكون غير سريع تم إنشاؤه باستخدام Server.CreateObject في كائن التطبيق. يمكنك تجنب هذا الخطأ باستخدام <object runat=serverscope=application...> في Global.asa، ​​ولكن هذا غير مستحسن لأنه قد يؤدي إلى التجميع والتسلسل، الموضح أدناه.

ماذا يحدث إذا قمت بتخزين مكونات غير رشيقة؟ تقوم المكونات غير السريعة المخزنة مؤقتًا في كائن الجلسة بتأمين الجلسة على مؤشر ترابط عامل ASP. يحتفظ ASP بمجموعة من مؤشرات الترابط العاملة للتعامل مع الطلبات. عادةً، تتم معالجة الطلب الجديد دائمًا بواسطة أول مؤشر ترابط عامل متوفر. إذا كانت الجلسة مقفلة على مؤشر ترابط، فيجب أن ينتظر الطلب حتى يصبح مؤشر الترابط المرتبط بها متاحًا. إليك تشبيه قد يساعدك: تذهب إلى السوبر ماركت، وتختار بعض العناصر، وتدفع عند شباك الخروج #_3. بعد ذلك، عندما تدفع مقابل عنصر ما في هذا السوبر ماركت، يتعين عليك دائمًا الدفع عند الخروج رقم _3، حتى لو كانت هناك طوابير أقل أو لا توجد طوابير عند نقاط الخروج الأخرى.

إن تخزين المكونات غير الرشيقة في نطاق التطبيق له تأثير أسوأ على الأداء. يجب أن يقوم ASP بإنشاء مؤشر ترابط خاص لتشغيل المكونات غير السريعة المخزنة في نطاق التطبيق. وهذا له نتيجتان: يجب أن يتم توجيه كافة المكالمات إلى مؤشر الترابط هذا، ويتم وضع كافة المكالمات في قائمة الانتظار. "التجميع" يعني أنه يجب تخزين المعلمات في منطقة مشتركة من الذاكرة؛ وإجراء تبديل سياق باهظ الثمن إلى مؤشر ترابط خاص؛ وتنفيذ طريقة المكون؛ وتنفيذ تبديل سياق آخر باهظ الثمن؛ إلى الموضوع الأصلي. "التسلسل" يعني أنه يتم تشغيل أسلوب واحد فقط في كل مرة. لا يمكن لمؤشرات ترابط عامل ASP مختلفة تنفيذ أساليب متعددة على مكون مشترك في وقت واحد. وهذا يلغي التزامن، خاصة على أجهزة الكمبيوتر متعددة المعالجات. ومما يزيد الطين بلة، أن جميع المكونات غير المتعلقة بنطاق التطبيق Agile تشترك في مؤشر ترابط واحد (المضيف STA)، وبالتالي فإن تأثير التسلسل يكون أكثر أهمية.

ماذا يمكنني أن أفعل؟ وهنا بعض القواعد العامة. إذا كنت تكتب كائنات باستخدام Visual Basic (6.0) أو إصدار سابق، فلا تقم بتخزينها مؤقتًا في كائنات التطبيق أو جلسة العمل. إذا كنت لا تعرف نموذج الترابط الخاص بالكائن، فلا تقم بتخزينه مؤقتًا. لا تقم بتخزين كائنات غير رشيقة مؤقتًا، بل قم بإنشائها وتحريرها في كل صفحة. يتم تشغيل الكائنات مباشرة على مؤشر ترابط عامل ASP، لذلك لا يوجد تجميع أو تسلسل. إذا كانت كائنات COM تعمل على خادم IIS، يكون الأداء مقبولاً إذا لم تستغرق وقتًا طويلاً للتهيئة والحذف. لاحظ أنه لا ينبغي استخدام الكائنات ذات الخيوط المفردة بهذه الطريقة. كن حذرًا - يمكن لـ VB إنشاء كائنات ذات ترابط واحد! إذا كان يجب عليك استخدام كائن ذو ترابط واحد (مثل جدول بيانات Microsoft Excel) مثل هذا، فلا تتوقع إنتاجية عالية.

عندما يتم وضع علامة على ADO كمؤشر ترابط حر، يمكن تخزين مجموعات سجلات ADO مؤقتًا بشكل آمن. لوضع علامة على ADO على أنه ذو ترابط حر، استخدم الملف Makfre15.bat، الموجود عادة في الدليل \Program FilesCommonSystemADO.

تحذير إذا كنت تستخدم Microsoft Access كقاعدة بيانات، فيجب عدم وضع علامة على ADO على أنها ذات ترابط حر. يجب أيضًا قطع اتصال مجموعة سجلات ADO. بشكل عام، إذا كنت لا تتحكم في تكوين ADO في موقعك (على سبيل المثال، أنت بائع برامج مستقل [ISV] تبيع تطبيقات الويب للعملاء الذين يديرون التكوينات الخاصة بهم)، فمن الأفضل عدم تخزين مجموعات السجلات مؤقتًا.

مكونات القاموس هي أيضًا كائنات رشيقة. يقوم LookupTable بتحميل بياناته من ملف بيانات ويمكن استخدامه لبيانات مربع التحرير والسرد ومعلومات التكوين. يوفر كائن PageCache في Duwamish Books بناء جملة القاموس، كما يفعل قاموس Caprock. يمكن أن تشكل هذه الكائنات أو الكائنات المشتقة منها أساسًا لاستراتيجية التخزين المؤقت الفعالة. لاحظ أن كائنات Scripting.Dictionary ليست سريعة ولا يجب تخزينها في نطاقات التطبيق أو الجلسة.

نصيحة 5: لا تقم بتخزين اتصالات قاعدة البيانات مؤقتًا في التطبيق أو كائن الجلسة

. يعد التخزين المؤقت لاتصالات ADO بمثابة إستراتيجية سيئة بشكل عام. إذا تم تخزين كائن اتصال في كائن التطبيق واستخدامه في جميع الصفحات، فستتنافس جميع الصفحات على هذا الاتصال. إذا تم تخزين كائن الاتصال في كائن جلسة ASP، فسيتم إنشاء اتصال قاعدة بيانات لكل مستخدم. سيؤدي هذا إلى إبطال مزايا تجميع الاتصالات ويضع ضغطًا غير ضروري على خادم الويب وقاعدة البيانات.

بدلاً من تخزين اتصالات قاعدة البيانات مؤقتاً، يمكنك إنشاء كائنات ADO وحذفها في كل صفحة ASP تستخدم ADO. يعد هذا فعالاً لأن IIS لديه تجمع اتصال قاعدة البيانات المضمن. لكي نكون أكثر دقة، يقوم IIS تلقائيًا بتمكين تجمع اتصال OLEDB وODBC. وهذا يضمن أن الاتصالات التي تم إنشاؤها وحذفها في كل صفحة ستكون صالحة.

نظرًا لأن مجموعة السجلات المتصلة تقوم بتخزين مرجع لاتصال قاعدة البيانات، يجب عدم تخزين مجموعة السجلات المتصلة مؤقتًا في كائن التطبيق أو جلسة العمل. ومع ذلك، يمكنك تخزين مجموعات السجلات المنفصلة التي لا تحتوي على مرجع لاتصال البيانات الخاص بها بشكل آمن. لقطع اتصال مجموعة سجلات، قم بتنفيذ الخطوتين التاليتين:

Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient ' الخطوة 1

' قم بملء مجموعة السجلات بالبيانات
rs.Open strQuery, strProv

' الآن افصل مجموعة السجلات عن موفر البيانات ومصدر البيانات
rs.ActiveConnection = لا شيء ' الخطوة 2
يمكن العثور على معلومات أكثر تفصيلاً حول تجمع الاتصالات في المواد المرجعية لـ ADO وSQL Server.

نصيحة 6: استخدام كائنات الجلسة بشكل صحيح

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

باختصار، يقوم ASP تلقائيًا بإنشاء جلسة لكل مستخدم يصل إلى خادم الويب. تتطلب كل جلسة حوالي 10 كيلو بايت من الذاكرة الزائدة (الشيء الرئيسي هو أن البيانات مخزنة في الجلسة)، مما يؤدي إلى إبطاء جميع الطلبات. تظل الجلسة صالحة حتى انقضاء فترة المهلة التي تم تكوينها (عادةً 20 دقيقة).

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

تتضمن استراتيجيات تحقيق الجلسات اللزجة حلول الأجهزة والبرامج. يمكن لحلول مثل Network Load Balancing في Windows 2000 Advanced Server وCisco's Local Director تنفيذ جلسات ثابتة على حساب درجة معينة من قابلية التوسع. هذه الحلول غير كاملة. لا يُنصح بنشر حل البرنامج الخاص بك في الوقت الحالي (كنا نستخدم مرشحات ISAPI وتحويلات URL، وما إلى ذلك).

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

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

إذا كنت لا تستخدم الجلسات، فتأكد من إغلاقها. يمكنك القيام بذلك لتطبيق من خلال Internet Services Manager (راجع وثائق ISM). إذا قررت استخدام الجلسات، فهناك طرق يمكنك من خلالها تخفيف تأثيرها على الأداء.

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

<% @EnableSessionState=False %>

سبب وجيه لاستخدام هذا التوجيه هو أن هذه الجلسة بها مشكلة مثيرة للاهتمام مع مجموعات الإطارات. يضمن ASP تنفيذ طلب واحد فقط في الجلسة في أي وقت. وهذا يضمن أنه إذا طلب المتصفح صفحات متعددة للمستخدم، فإن طلب ASP واحد فقط يلمس الجلسة في المرة الواحدة، وبالتالي تجنب مشكلات الخيوط المتعددة التي تحدث عند الوصول إلى كائن الجلسة. لسوء الحظ، سيتم عرض كافة الصفحات الموجودة في مجموعة الإطارات بشكل تسلسلي، واحدة تلو الأخرى، وليس في وقت واحد. قد يضطر المستخدمون إلى الانتظار لفترة طويلة لرؤية جميع الإطارات. المغزى من القصة: إذا كانت بعض صفحات مجموعة الإطارات لا تعتمد على الجلسة، فتأكد من إخبار ASP باستخدام التوجيه @EnableSessionState=False.

هناك العديد من الطرق لإدارة حالة الجلسة التي يمكن أن تحل محل استخدام كائنات الجلسة. بالنسبة للكميات الصغيرة من الحالة (أقل من 4 كيلوبايت)، نوصي عمومًا باستخدام ملفات تعريف الارتباط ومتغيرات QueryString والمتغيرات الضمنية. بالنسبة لأحجام البيانات الكبيرة، مثل عربات التسوق، تعد قاعدة البيانات الخلفية هي الخيار الأنسب. لقد كتب الكثير عن تقنيات إدارة الحالة في مزارع خوادم الويب. لمزيد من المعلومات، راجع مرجع حالة الجلسة.

نصيحة 7: تغليف التعليمات البرمجية في كائنات COM

إذا كان لديك الكثير من VBScript أو JScript، فيمكنك غالبًا تحسين الأداء عن طريق نقل التعليمات البرمجية الخاصة بك إلى كائنات COM المترجمة. عادةً ما تعمل التعليمات البرمجية المجمعة بشكل أسرع من التعليمات البرمجية المفسرة. يمكن لكائنات COM المترجمة الوصول إلى كائنات COM الأخرى من خلال "الربط المبكر"، وهو أسلوب أكثر فعالية لاستدعاء كائنات COM من "الربط المتأخر" الذي تستخدمه البرامج النصية.

يحتوي تغليف التعليمات البرمجية في كائنات COM على العديد من المزايا (إلى جانب الأداء):

تساعد كائنات COM على فصل منطق العرض التقديمي عن منطق الأعمال.
تضمن كائنات COM إعادة استخدام التعليمات البرمجية.
يجد العديد من المطورين أن التعليمات البرمجية المكتوبة بلغة VB أو C++ أو Visual J++ أسهل في التصحيح من ASP.
كائنات COM لها أيضًا عيوب، بما في ذلك وقت التطوير الأولي وتتطلب مهارات برمجة مختلفة. لاحظ أن تغليف كمية صغيرة من ASP قد يؤدي إلى انخفاض الأداء دون تحسين الأداء. يحدث هذا الموقف عادةً عندما يتم تغليف كمية صغيرة من تعليمات ASP البرمجية في كائن COM. في هذه الحالة، يفوق مقدار الحمل لإنشاء كائن COM واستدعاءه مزايا التعليمات البرمجية المترجمة. يجب استخدام التجربة والخطأ لتحديد أي مجموعة من البرنامج النصي ASP والتعليمات البرمجية لكائن COM تنتج أفضل أداء. لاحظ أن هناك تحسينات كبيرة في البرمجة النصية وأداء ADO في Windows 2000/IIS 5.0 مقارنةً بـ Microsoft Windows NT&reg; لذلك، مع تقديم IIS 5.0، انخفضت ميزة أداء التعليمات البرمجية المترجمة عبر تعليمات ASP البرمجية.

للحصول على مناقشة تفصيلية حول مزايا وعيوب استخدام COM في ASP، راجع إرشادات مكونات ASP وبرمجة التطبيقات الموزعة باستخدام Microsoft Visual Basic 6.0. إذا قمت بنشر مكونات COM، فمن المهم بشكل خاص اختبارها تحت التحميل. في الواقع، يجب اختبار تحميل كافة تطبيقات ASP كأمر طبيعي.

نصيحة 8: احصل على الموارد لاحقًا وقم بإصدارها مبكرًا،

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

يتم استخدام أسلوب التحسين هذا بشكل أساسي لاتصالات ADO ومجموعات السجلات. عند الانتهاء من استخدام مجموعة السجلات، على سبيل المثال بعد عرض الجدول وبياناته، يجب عليك تحريره على الفور بدلاً من الانتظار حتى نهاية الصفحة. من الأفضل تعيين متغير VBScript على لا شيء. لا تدع مجموعة السجلات تخرج عن النطاق. قم أيضًا بتحرير أي كائنات أوامر أو اتصال ذات صلة (لا تنس الاتصال بـ Close() قبل تعيين مجموعة السجلات أو الاتصال على = Nothing). يؤدي هذا إلى تقليل الوقت الذي تستغرقه قاعدة البيانات لإعداد الموارد لك وتحرير اتصال قاعدة البيانات إلى تجمع الاتصال في أسرع وقت ممكن.

نصيحة 9: أداء عمليات التنفيذ خارج العملية لتحقيق الموثوقية

يتمتع كل من ASP وMTS/COM+ بخيارات تكوين تسمح لك باستبدال الموثوقية بالأداء. عند إنشاء التطبيقات ونشرها، يجب أن تعرف كيفية موازنة الأداء مع كليهما.

تقوم خيارات ASP بتكوين تطبيقات ASP لتعمل بإحدى الطرق الثلاث. في IIS 5.0، تم تقديم المصطلح "مستوى العزل" لوصف هذه الخيارات. مستويات العزل الثلاثة هي المستوى المنخفض، المستوى المتوسط، والمستوى العالي:

مستوى العزل المنخفض. يتم دعم هذا في كافة إصدارات IIS وهو الأسرع. يقوم بتشغيل ASP في Inetinfo.exe، وهي عملية IIS الرئيسية. إذا تعطل تطبيق ASP، فسيتعطل IIS أيضًا. (لإعادة تشغيل IIS ضمن IIS 4.0، يجب على مسؤول موقع الويب مراقبة الموقع باستخدام أداة مثل InetMon وتمكين ملف دفعي لإعادة تشغيل الخادم في حالة فشل الخادم. قدم IIS 5.0 إعادة تشغيل موثوقة، وهي طريقة إعادة تشغيل الخادم الفاشل تلقائيًا ).
العزلة المتوسطة. لقد قدم IIS 5.0 هذا المستوى الجديد، والذي يسمى مستوى خارج العملية لأن ASP يعمل خارج عملية IIS. في العزل المتوسط، تشترك كافة تطبيقات ASP التي تم تكوينها للتشغيل كعزل متوسط ​​في مساحة العملية. يؤدي هذا إلى تقليل عدد العمليات المطلوبة لتشغيل تطبيقات ASP متعددة خارج العملية على خادم واحد. العزل المتوسط ​​هو مستوى العزل الافتراضي في IIS 5.0.
العزلة المتقدمة يتم دعم هذا المستوى في IIS 4.0 وIIS 5.0، كما أن العزل المتقدم خارج المعالجة أيضًا. في حالة تعطل ASP، لا يتعطل خادم الويب. سيتم إعادة تشغيل تطبيق ASP تلقائيًا في المرة التالية التي يتم فيها تقديم طلب ASP. في العزل المتقدم، يتم تشغيل كل تطبيق ASP تم تكوينه ليعمل كعزل متقدم في مساحة العملية الخاصة به. يؤدي القيام بذلك إلى حماية تطبيقات ASP من التداخل مع بعضها البعض. العيب هو أنه يتطلب عملية منفصلة لكل تطبيق ASP. عندما يجب تشغيل العديد من التطبيقات على خادم واحد، يزيد حمل النظام بشكل ملحوظ.
ما هو الخيار الأفضل؟ في IIS 4.0، سيؤدي نفاد العملية إلى تقليل الأداء بشكل ملحوظ. في IIS 5.0، تم إجراء العديد من التحسينات لتقليل الحمل الناتج عن تشغيل تطبيقات ASP خارج العملية. في الواقع، في الغالبية العظمى من الاختبارات، تم تشغيل تطبيقات ASP خارج المعالجة في IIS 5.0 بشكل أسرع من التطبيقات قيد التشغيل في IIS 4.0. بغض النظر، على كلا النظامين الأساسيين، يكون الأداء قيد التشغيل (مستوى العزل المنخفض) هو الأفضل. ومع ذلك، إذا كان معدل الوصول منخفضًا نسبيًا أو كان الحد الأقصى للإنتاجية منخفضًا، فإن مزايا مستوى العزل المنخفض تكون أقل وضوحًا. لذلك، قد يكون تعيين مستوى عزل منخفض ضروريًا فقط إذا كنت تحتاج إلى مئات أو آلاف الصفحات في الثانية لكل خادم ويب. كما هو الحال دائمًا، اختبر تكوينات متعددة لتحديد التسوية التي تريد القيام بها.

لاحظ أنه عند تشغيل تطبيقات ASP خارج العملية (عزل متوسط ​​أو عالي)، فإنها تعمل في MTS في NT4 وفي COM+ في Windows 2000. أي أنه في NT4 يتم تشغيلها في Mtx.exe؛ وفي نظام التشغيل Windows 2000، يتم تشغيلها في DllHost.exe. يمكنك رؤية هذه العمليات قيد التشغيل في إدارة المهام. يمكنك أيضًا مشاهدة كيفية قيام IIS بتكوين حزمة MTS أو تطبيق COM+ لتطبيق ASP خارج العملية.

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

يمكنك أن ترى أن المكونات غير المكونة لها مزايا طفيفة مقارنة بتطبيقات المكتبة. تتمتع تطبيقات المكتبة بمزايا أداء أكبر من تطبيقات الخادم. وذلك لأن تطبيقات المكتبة تعمل بنفس عملية ASP، بينما تعمل تطبيقات الخادم في عملياتها الخاصة. تعد المكالمات بين العمليات أكثر تكلفة من المكالمات داخل العمليات. علاوة على ذلك، عند تمرير البيانات مثل مجموعات السجلات بين العمليات، يجب نسخ كافة البيانات بين العمليتين.

فخ! عند استخدام تطبيق خادم COM، إذا قمت بتمرير كائنات بين ASP وCOM، فتأكد من أن الكائنات تؤدي "حزمة حسب القيمة" أو MBV. تقوم الكائنات التي تنفذ MBV بنسخ نفسها من عملية إلى أخرى. يعد هذا أفضل من الأسلوب الذي يظل فيه الكائن في عملية المنشئ وتستدعي عملية أخرى عملية الإنشاء بشكل متكرر لاستخدام الكائن. سيتم "تجميع مجموعة سجلات ADO المنفصلة حسب القيمة"، ولن يتم تجميع مجموعة السجلات المتصلة. لا يقوم Scripting.Dictionary بتنفيذ MBV ولا يتم تمريره بين العمليات. أخيرًا، ملاحظة لمبرمجي VB: لا يتم الحصول على MBV عن طريق تمرير المعلمة ByVal. يتم تنفيذ MBV بواسطة مؤلف المكون الأصلي.

ما يجب القيام به؟
إذا طُلب منا اقتراح تكوين معقول يوازن بين الأداء والموثوقية، فسيكون كما يلي:

في IIS 4.0، استخدم مستوى عزل منخفض لـ ASP واستخدم حزمة خادم MTS.
في IIS 5.0، استخدم مستوى العزل المتوسط ​​لـ ASP واستخدم تطبيق مكتبة COM+.
هذه مبادئ عامة جدًا؛ عادةً ما تقوم شركات الاستضافة بتشغيل ASP بمستويات عزل متوسطة أو عالية، بينما يمكن لخوادم الويب ذات الغرض الواحد أن تعمل بمستويات عزل منخفضة. وازن بين الإيجابيات والسلبيات وقرر بنفسك التكوين الذي يناسب احتياجاتك بشكل أفضل.

نصيحة 10: استخدم

خيار الخيارات الصريحة يجب استخدام صريح في ملفات .asp. يتم وضع هذا التوجيه في الجزء العلوي من ملف .asp ويجبر المطور على إعلان جميع المتغيرات التي سيتم استخدامها. يجد العديد من المبرمجين هذه الطريقة مفيدة في تطبيقات تصحيح الأخطاء لأنها تتجنب إمكانية وضع أسماء متغيرة وإنشاء متغيرات جديدة عن طريق الخطأ (على سبيل المثال ، myxmlString =) بدلاً من myxlmstring = ....

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

نصيحة 11: استخدم المتغيرات المحلية في الروتين الفرعي والوظائف

المتغيرات المحلية هي تلك المتغيرات المعلنة في الروتين الفرعي والوظائف. ضمن وظيفة أو روتين فرعي ، يكون الوصول المتغير المحلي أسرع من الوصول المتغير العالمي. سيؤدي استخدام المتغيرات المحلية أيضًا إلى جعل الكود أكثر وضوحًا ، لذلك يجب استخدام المتغيرات المحلية كلما أمكن ذلك.

نصيحة 12: نسخ البيانات بشكل متكرر في متغيرات البرنامج النصي

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

بشكل عام ، إذا كنت تخطط للوصول إلى بيانات الكائن أكثر من مرة ، فيجب عليك وضع البيانات في متغيرات البرنامج النصي. الهدف الرئيسي لهذا التحسين هو متغيرات الطلب (النموذج ومتغيرات QueryString). على سبيل المثال ، يمكن لموقعك تمرير متغير QueryString اسمه UserD. دعنا نقول أن هذا المستخدم يشير إلى 12 مرة على صفحة معينة. بدلاً من استدعاء طلب (؟ UserD؟) 12 مرة ، يمكنك تعيين userId لمتغير في أعلى صفحة ASP. ثم استخدم هذا المتغير خلال الصفحة. هذا يحفظ 11 مكالمات COM.

في الواقع ، فإن الوصول إلى خصائص كوم أو الأساليب ليس باهظ الثمن. إليك مثال على بعض الكود الشائع إلى حد ما (من الناحية النحوية):

foo.bar.blah.baz = foo.bar.blah.qaz (1)
إذا foo.bar.blah.zaq = foo.bar.blah.abc ثم '...
عند تشغيل هذا الرمز ، إليك ما يحدث:

يتم حل المتغير FOO إلى كائن عالمي.
يتم حل الشريط المتغير كعضو في FOO. هذه في الواقع مكالمة COM.
يتم حل بلاه المتغير كعضو في foo.bar. هذه هي مكالمة أخرى COM.
يتم حل المتغير Qaz كعضو في foo.bar.blah. هذا صحيح ، لا يزال هذا استدعاء طريقة com.
اتصل بـ foo.bar.blah.quaz (1). مكالمة طريقة أخرى COM. فهمتها؟
قم بتنفيذ الخطوات من 1 إلى 3 مرة أخرى إلى PARSE BAZ. لا يعرف النظام ما إذا كان الاتصال Qaz يغير نموذج الكائن ، لذلك يجب تنفيذ الخطوات من 1 إلى 3 مرة أخرى لحل BAZ.
حل باز كعضو في foo.bar.blah. تعيين السمات.
قم بتنفيذ الخطوات من 1 إلى 3 مرة أخرى لتحرير ZAQ.
إجراء الخطوات من 1 إلى 3 مرة أخرى لتحليل ABC.
كما ترون ، فإن الكفاءة سيئة للغاية (وبطيئة). طريقة سريعة لكتابة هذا الرمز في vbscript هي:

set myobj = foo.bar.blah 'القيام بدقة بلاه مرة واحدة
myobj.baz = myobj.qaz (1)
إذا myobj.zaq = myobj.abc ثم '...
إذا كنت تستخدم VBScript 5.0 أو أعلى ، فيمكنك كتابة هذا الرمز باستخدام العبارة مع:

مع foo.bar.blah
.baz = .Qaz (1)
إذا .zaq = .abc ثم '...
...
انتهى مع

ملاحظة أن هذه التقنية تنطبق أيضًا على برمجة VB.

نصيحة 13: تجنب إعادة تجنب صفيفات إعادة

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

يوضح لك الرمز التالي استخدامًا غير مناسب لـ Dim و Redim.

<%
Dimmyarray ()
Redimmyarray (2)
myarray (0) =؟ مرحبًا؟
myarray (1) =؟ وداعا؟
myarray (2) =؟ وداع؟
...
'بعض التعليمات البرمجية الأخرى حيث ينتهي بك الأمر إلى حدوث مساحة أكبر ، ثم ...
Redim Preserve Myarray (5)
myarray (3) =؟ المزيد من الأشياء؟
myarray (4) =؟ حتى المزيد من الأشياء؟
myarray (5) =؟ بعد المزيد من الأشياء؟
٪>

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

نصيحة 14: استخدم الاستجابة للتخزين المؤقت ،

يمكنك تخزين صفحة كاملة من الإخراج عن طريق تمكين "الاستجابة التخزين المؤقت". هذا يقلل من مقدار الكتابة إلى المتصفح ، مما يؤدي إلى تحسين الأداء العام. تتحمل كل عملية كتابة عامة كبيرة (سواء في IIS أو من حيث مقدار البيانات المرسلة عبر الشبكة) ، وبالتالي فإن أقل يكتب كلما كان ذلك أفضل. نظرًا لبدء تشغيله البطيء واستخدامها لخوارزمية nagling (المستخدمة في تخفيف احتقان الشبكة) ، يكون TCP/IP أكثر كفاءة عند إرسال بعض القطع الكبيرة من البيانات مما كان يجب عليه إرسال العديد من القطع الصغيرة.

هناك طريقتان لتمكين الاستجابة للتخزين المؤقت. أولاً ، يمكنك استخدام مدير خدمات الإنترنت لتمكين الاستجابة للتخزين المؤقت للتطبيق بأكمله. نوصي بهذا النهج ، مما يتيح الاستجابة للتخزين المؤقت افتراضيًا لتطبيقات ASP الجديدة في IIS 4.0 و IIS 5.0. ثانياً ، يمكنك تمكين الاستجابة للتخزين المؤقت عن طريق إضافة السطر التالي من التعليمات البرمجية بالقرب من الجزء العلوي من كل صفحة من ASP:

<٪ reponse.buffer = true ٪>
يجب تنفيذ سطر الكود هذا قبل كتابة أي بيانات استجابة إلى المتصفح (أي قبل ظهور أي HTML في البرنامج النصي ASP وقبل تعيين أي ملفات تعريف الارتباط باستخدام مجموعة Response.Cookies). بشكل عام ، من الأفضل تمكين الاستجابة للتخزين المؤقت للتطبيق بأكمله. وبهذه الطريقة ، ليس عليك كتابة السطر المذكور أعلاه من الكود في الجزء العلوي من كل صفحة.

الاستجابة. فلوش
هناك شكوى شائعة حول التخزين المؤقت للاستجابة هي أن المستخدمين يرون أن صفحات ASP بطيئة في الاستجابة (على الرغم من تحسين وقت الاستجابة الإجمالية) لأنه يتعين عليهم الانتظار حتى يتم إنشاء الصفحة بأكملها قبل أن يتمكنوا من رؤية أي شيء. بالنسبة للصفحات طويلة الأجل ، يمكنك تعيين استجابة. buffer = خطأ لتعطيل التخزين المؤقت للاستجابة. ومع ذلك ، فإن الإستراتيجية الأفضل هي استخدام طريقة الاستجابة. ترسل هذه الطريقة جميع HTML التي تم تحويلها بواسطة ASP إلى المتصفح. على سبيل المثال ، بعد تحويل 100 صف من طاولة 1000 صف ، يمكن لـ ASP الاتصال بالاستجابة. تجمع هذه التقنية تمامًا بين التخزين المؤقت للاستجابة مع المتصفح الذي يعرض البيانات تدريجياً.

(لاحظ أنه في مثال جدول 1000 صف أعلاه ، لن تبدأ العديد من المتصفحات في عرض الجدول حتى يروا علامة الإغلاق </table> عدد أقل من الصفوف والاتصال بالاستجابة بعد كل جدول. عرض المحتوى لكل خلية.) هناك

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

النصيحة 15: الدفعة المدمجة البرامج النصية والاستجابة. إعادة صياغة

VBScript Syntax <٪ = Expression ٪> اكتب قيمة "التعبير" إلى دفق إخراج ASP. إذا لم يتم تمكين التخزين المؤقت للاستجابة ، فسيقوم كل عبارة يتم تنفيذها بكتابة البيانات إلى المتصفح في العديد من الحزم الصغيرة عبر الشبكة. هذا بطيء جدا. علاوة على ذلك ، فإن التنفيذ المتخلل لكمية صغيرة من البرامج النصية و HTML سيؤدي إلى التبديل بين محرك البرنامج النصي و HTML ، وبالتالي تقليل الأداء. لذلك ، استخدم الخدعة التالية: استخدم الاستجابة. المكالمات بدلاً من التعبيرات المضمنة بإحكام. على سبيل المثال ، في المثال التالي ، هناك كتابة واحدة إلى دفق الاستجابة لكل حقل لكل صف ، وهناك العديد من المفاتيح بين VBScript و HTML لكل صف:

<جدول>
<٪ لكل FLD في Rs.Fields ٪>
<h> <٪ = fld.name ٪> </h>
<%
التالي
بينما لا rs.eof
%>
<تر>
<٪ لكل FLD في Rs.Fields ٪>
<td> <٪ = fld.value ٪> </td>
<٪ التالي
</tr>
<٪ Rs.Movenext
وند٪>
</الجدول>
الكود أدناه أكثر كفاءة ، مع كتابة واحد إلى دفق الاستجابة لكل سطر. جميع التعليمات البرمجية موجودة داخل كتلة vbscript:

<جدول>
<%
لكل FLD في RS.Fields
respons.write (؟ <th>؟ & fld.name &؟ </h>؟ & vbcrlf)
التالي
بينما لا rs.eof
الرد. write (؟ <tr>؟)
لكل FLD في RS.Fields ٪>
repress.write (؟ <td>؟ & fld.value &؟ </td>؟ & vbcrlf)
التالي
الرد. write؟ </tr>؟
ويند
%>
</الجدول>
تعمل هذه الخدعة بشكل جيد بشكل خاص عندما يتم تعطيل التخزين المؤقت للاستجابة. من الجيد تمكين الاستجابة للتخزين المؤقت ومعرفة ما إذا كان الاستجابة للتجديد. يساعد الكتابة على تحسين الأداء.

(في هذا المثال بالذات ، يمكن استبدال الحلقة المتداخلة التي تبني جسم الجدول (على الرغم من عدم وجود rs.eof ...) بعناية بنيت بعناية

. افعل إذا كان المستخدمون غير صبور قبل استخدام الاستجابة. iSclientConnected

، فقد يتخلىون عن صفحة ASP قبل البدء في تنفيذ طلبهم. إذا انقروا على التحديث أو الانتقال إلى صفحة أخرى على الخادم ، فهناك طلب جديد ينتظر في نهاية قائمة انتظار طلب ASP ، وطلب منفصل في منتصف قائمة الانتظار. يحدث هذا في كثير من الأحيان عندما يكون الحمل على الخادم مرتفعًا (وبالتالي فإن قائمة انتظار الطلب طويلة وتكون أوقات الاستجابة طويلة في المقابل) ، مما يجعل الموقف أسوأ فقط. لا يوجد أي فائدة في تنفيذ صفحات ASP (خاصة صفحات ASP البطيئة) إذا لم يعد المستخدم متصلاً. يمكنك التحقق من ذلك باستخدام خاصية Response.isclientConnected. إذا عادت false ، فيجب استدعاء. في الواقع ، لدى IIS 5.0 هذا السلوك المبرمج فيه - في كل مرة يكون فيها ASP على وشك تنفيذ طلب جديد ، يتحقق من المدة التي قضاها الطلب في قائمة الانتظار. إذا كانت تنتظر هناك لأكثر من 3 ثوانٍ ، فسيتحقق ASP ما إذا كان العميل لا يزال متصلاً ، وإذا لم يكن الأمر كذلك ، قم بإنهاء الطلب على الفور. يمكنك ضبط المهلة من 3 ثوانٍ إلى قيمة أخرى باستخدام إعداد AspquoNeconNectionTestTime في عملية التمثيل.

يمكنك أيضًا التحقق من Response.isclientConnected من وقت لآخر إذا استغرقت الصفحة وقتًا طويلاً لإكمالها. عندما يتم تمكين الاستجابة للتخزين المؤقت ، من الجيد أداء الاستجابة. flush من وقت لآخر لإعلام المستخدم بما يحدث.

لاحظ أنه في IIS 4.0 ، لن يعمل Response.isclientConnected بشكل صحيح ما لم يتم تنفيذ Response.write أولاً. إذا تم تمكين التخزين المؤقت ، فيجب عليك أيضًا إجراء Response.flush. في IIS 5.0 ، ليست هناك حاجة للقيام بذلك - استجابة. على أي حال ، سيكون للاستجابة. تُظهر التجربة أنه يجب ألا تسميها في كل مرة يتم فيها تنفيذ حلقة ضيقة بشكل متكرر ، كما هو الحال عند عرض العديد من صفوف الجدول - قد يكون تسميته كل عشرين أو خمسين صفًا مناسبًا.

نصيحة 17: استخدم علامة <Object> للكائنات التي تم إنشاؤها

إذا كنت ترغب في الرجوع إلى كائن غير مستخدم في جميع مسارات الرموز (وخاصة الكائنات الخادم أو التطبيق) ، استخدم <كائن Runat = معرف الخادم = objname> علامة إعلان في Global.asa لهم بدلاً من استخدام طريقة corderObject. Server.CreateBject ينشئ كائنات على الفور. إذا لم تستخدم الكائن في المستقبل ، فقد أهدرت الموارد. تعلن العلامة <كائن = objname> objName ، ولكن لا يتم إنشاء ObjName حتى يتم استخدام طريقته أو خاصته لأول مرة.

هذا مثال آخر على التقييم الكسول.

نصيحة 18: استخدم إعلانات typelib الخاصة بـ ADO والمكونات الأخرى

عند استخدام ADO ، وغالبًا ما يضيف المطورون Adovbs.txt للوصول إلى ثوابت ADO المختلفة. يجب تضمين هذا الملف في كل صفحة حيث يتم استخدام الثوابت. هذا الملف الثابت كبير جدًا ، ويضيف الكثير من النفقات العامة إلى وقت التجميع وحجم البرنامج النصي لكل صفحة ASP.

قدم IIS 5.0 القدرة على ربط مكتبات نوع المكون. يتيح لك ذلك الرجوع إلى مكتبة النوع مرة واحدة واستخدامها في كل صفحة ASP. لا يوجد أي عام من تجميع الملفات الثابتة لكل صفحة ، ولا يتعين على مطورو المكونات إنشاء ملفات VBScript#_include للاستخدام على ASP.

للوصول إلى ADO Typelib ، ضع البيان التالي في Global.asa.

<!- ​​اسم البيانات الوصفية =؟ مكتبة بيانات Microsoft ActiveX 2.5؟
نوع = typelib؟
أو

<!- نوع البيانات الوصفية =؟ typelib؟

Program

Files Common System ado

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

لقد ذهب الكثير من العمل إلى تطوير "HTML" المستقلة عن المستعرض. بسبب هذا القلق ، يحجم المطورون في استخدام ميزات المتصفح الشائعة التي يمكن أن تحسن الأداء. بالنسبة لبعض المواقع عالية الأداء حقًا ، يجب أن تكون مشكلات "الوصول" للمتصفح ، والاستراتيجية الجيدة هي تحسين الصفحة لتكييفها مع المتصفحات الشائعة. يمكن اكتشاف قدرات المتصفح بسهولة في ASP باستخدام مكون إمكانات المتصفح. أدوات مثل Microsoft Frontpage Design Code التي تناسب المتصفح وإصدار محدد من HTML. انظر متى يكون أفضل أسوأ؟ وزن المفاضلات التكنولوجية لمزيد من المناقشة.

نصيحة 20: تجنب استخدام سلسلة متسلسل في حلقة

يقوم العديد من الأشخاص بإنشاء سلسلة في حلقة ، مثل هذا:

S =؟ <Table>؟
لكل FLD في RS.Fields
S = S &؟
التالي

بينما لا Rs.eof
s = s & vbcrlf &؟
لكل FLD في RS.fields
S = S &؟
التالي
S = S &؟
rs.MoveNext
Wend

S = S & vbcrlf &؟ </table>؟
استجابة. write s
بعض المشاكل تنشأ مع هذا النهج. المشكلة الأولى هي أن الأوتار المتسلسلة مرارًا وتكرارًا تستغرق وقتًا طويلاً. مثال أبسط سيوضح هذه المشكلة بشكل أكثر وضوحًا.

s = ؟؟
لأني = asc (؟ a؟) إلى ASC (؟ z؟)
s = s & chr (i)
التالي
في التكرار الأول ، يمكنك الحصول على سلسلة أحادية واحدة؟ A؟. في التكرار الثاني ، يجب على vbscript إعادة تخصيص السلسلة ونسخ حرفين (؟ ab؟) إلى s. في التكرار الثالث ، يجب أيضًا إعادة تخصيص S مرة أخرى ونسخ ثلاثة أحرف إلى S. على التكرارات n (26) ، يجب إعادة تخصيص ونسخ أحرف n إلى s. المجموع هو 1+2+3+...+n ، أي ، n*(n+1)/2 نسخة.

في مثال مجموعة السجل أعلاه ، إذا كان هناك 100 سجل و 5 حقول ، فسيتم تنفيذ الحلقة الداخلية 100*5 = 500 مرة ، والوقت الذي يقضيه في جميع النسخ وإعادة التخصيص يتناسب مع 500*500 = 250،000. هذا عدد كبير جدًا من عمليات النسخ لمجموعة سجلات معتدلة.

في هذه الحالة ، يمكن تحسين الكود باستخدام Response.write () أو البرمجة النصية المضمّنة (<٪ = fld.value ٪>) بدلاً من تسلسل السلسلة. إذا تم تمكين التخزين المؤقت للاستجابة (ينبغي) ، فسيكون ذلك أسرع لأن الاستجابة. إن الكتابة فقط إلحاق البيانات إلى نهاية المخزن المؤقت للاستجابة. لا يوجد إعادة تخصيص ، لذلك فهو فعال للغاية.

في الحالة المحددة لتحويل مجموعة سجل ADO إلى جدول HTML ، يجب عليك التفكير في استخدام Getrows أو GetString.

إذا كنت متسلسلًا في JScript ، فمن المستحسن بشكل خاص استخدام += المشغل ، أي استخدام S +=؟

نصيحة 21: تمكين المتصفح والتخزين المؤقت للوكالة

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

ما هي الصفحة الديناميكية التي يمكن استخدامها كصفحة ليتم تخزينها مؤقتًا؟ فيما يلي بعض الأمثلة:

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

يتم التحكم في التخزين المؤقت للمتصفح بواسطة رأس "انتهاء الصلاحية" HTTP ، والذي يتم إرساله إلى المتصفح بواسطة خادم الويب. يوفر ASP آليتين بسيطتين لإرسال هذا الرأس. لتعيين عدد الدقائق التي ستنتهي صلاحيتها بعدها ، قم بتعيين خاصية Response.expires. يخبر المثال التالي المتصفح بأن المحتوى ينتهي في 10 دقائق:

<٪ reponse.expires = 10 ٪>

إعداد استجابة. تأكد من استخدام رقم سالب كبير ، مثل -1000 (أكثر من يوم بقليل) لتجنب عدم التوافق بين ساعات الخادم والمتصفح. ستتيح لك الخاصية الثانية ، Response.expiresabsolute ، تعيين الوقت المحدد عندما ينتهي المحتوى:

<٪ reponse.expiresabsolute = #May 31،2001 13: 30: 15 # ٪>
بدلاً من استخدام كائن الاستجابة لتعيين وقت انتهاء الصلاحية ، يمكنك كتابة علامة <TECA> في HTML ، وعادةً ما تكون في قسم <Head> من ملف HTML. ستحترم بعض المتصفحات هذا التوجيه ، في حين أن الوكلاء لن يفعلوا ذلك.

<meta http-equiv =؟ تنتهي؟
أخيرًا ، يمكنك استخدام خاصية Response.CacheControl للإشارة إلى ما إذا كان يمكن تخزين محتوىه بواسطة وكيل HTTP. يتيح تعيين هذه الخاصية على "عام" للوكيل ذاكرة التخزين المؤقت لهذا المحتوى.

<٪ استجابة
بشكل افتراضي ، تم تعيين هذه الخاصية على "الخاص". لاحظ أنه لا ينبغي تمكين التخزين المؤقت للوكالة للصفحات التي تعرض البيانات الخاصة بالمستخدم ، حيث أن الوكيل قد يخدم صفحات المستخدم التي تنتمي إلى مستخدمين آخرين.

نصيحة 22: استخدم server.transfer بدلاً من الاستجابة

. تُستخدم هذه الوظيفة بشكل شائع لإعادة توجيه المستخدم إلى صفحة تسجيل الدخول أو خطأ. نظرًا لأن إعادة التوجيه يفرض طلبًا للحصول على صفحة جديدة ، فإن النتيجة هي أن المتصفح يجب أن يقوم برحلتين مستديرتين إلى خادم الويب ، ويجب على خادم الويب التعامل مع طلب آخر. يقدم IIS 5.0 خادم دالة جديد. هذا يتجنب رحلات مستديرة متصفح زائدة عن الحاجة ، مما يؤدي إلى تحسين أداء النظام العام ووقت استجابة المستخدم. تحقق من "الاتجاه الجديد" في "Redirect" ، يجب أن يكون server.transfer و server.execute.

راجع أيضًا الاستفادة من ASP في IIS 5.0 للحصول على قائمة كاملة بالميزات الجديدة في IIS 5.0 و ASP 3.0.

نصيحة 23: استخدم عصرًا خلفيًا في عناوين URL للدليل ،

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

على سبيل المثال ، اكتب:

<a href =؟ http: //msdn.microsoft.com/workshop/؟ title =؟ msdn web
ورشة العمل؟> http://msdn.microsoft.com/workshop </a>
ينطبق هذا أيضًا على عناوين URL التي تشير إلى الصفحة الرئيسية على موقع الويب: استخدم ما يلي: <a href =؟ http: //msdn.microsoft.com/؟> بدلاً من <a href =؟ http: //msdn.microsoft كوم؟

نصيحة 24: تجنب استخدام متغيرات الخادم

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

لا تصل أبدًا إلى كائن طلب غير مؤهل (على سبيل المثال ، طلب ("بيانات")). request.ServerVariables يسمى ضمنيًا للعناصر غير الموجودة في الطلب. مجموعة request.servervariables أبطأ بكثير من المجموعات الأخرى.

النصيحة 25: يعد الترقية إلى أحدث وأكبر

مكونات النظام ثابتًا ، ونوصي بترقيتها إلى أحدث وأكبر التكوينات. من الأفضل الترقية إلى Windows 2000 (وبالتالي IIS 5.0 و ADO 2.5 و MSXML 2.5 و Internet Explorer 5.0 و VBSCRIPT 5.1 و JScript 5.1). على أجهزة الكمبيوتر متعددة المعالجات ، يمكن لتطبيق IIS 5.0 و ADO 2.5 تحسين الأداء بشكل كبير. تحت Windows 2000 ، يقوم ASP بتوسيع نطاق أربعة معالجات أو أكثر ، بينما تحت IIS 4.0 ، لا يتجاوز ASP معالجتين. كلما زادت رمز البرمجة النصية واللوح الذي تستخدمه في التطبيق الخاص بك ، زادت تحسينات الأداء التي ستختبرها بعد الترقية إلى Windows 2000.

إذا لم تتمكن من الترقية إلى Windows 2000 حتى الآن ، فيمكنك الترقية إلى أحدث إصدارات SQL Server و ADO و VBScript و JScript و MSXML و Internet Explorer و NT 4. كلاهما يحسن الأداء والموثوقية.

نصيحة 26: تحسين خادم الويب ،

هناك العديد من معلمات تحسين IIS التي يمكن أن تحسن أداء الموقع. على سبيل المثال ، مع IIS 4.0 ، غالبًا ما نجد أن زيادة معلمة ASP ProcessOrthReadMax (انظر وثائق IIS) يمكن أن تحسن بشكل كبير من الأداء ، لا سيما على المواقع التي تميل إلى انتظار الموارد الخلفية (مثل قواعد البيانات) أو غيرها من المنتجات الوسيطة (مثل هذا كما فرش الشاشة). في IIS 5.0 ، قد تجد أن تمكين بوابات مؤشر ترابط ASP أكثر كفاءة من العثور على إعداد مثالي لـ ASPProcessorTorDMax ، وهو الآن معروف جيدًا.

للحصول على مرجع جيد ، راجع تحسين IIS أدناه.

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

نصيحة 27: إجراء اختبار الأداء

كما قلنا من قبل ، الأداء مميز. إذا كنت ترغب في تحسين أداء موقعك ، فقم بتعيين هدف الأداء وتحسينه تدريجياً حتى تصل إليه. لا ، لن يتم إجراء اختبار الأداء. في كثير من الأحيان ، بحلول نهاية المشروع ، فات الأوان لإجراء التغييرات الهيكلية اللازمة ، وسوف يخيب عميلك. إجراء اختبار الأداء كجزء من روتين الاختبار الخاص بك. يمكنك إجراء اختبار الأداء على المكونات الفردية بشكل فردي ، مثل صفحات ASP أو كائنات COM ، أو على الموقع ككل.

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

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

المدرجة أدناه هي بعض أدوات اختبار تحميل الويب الجيدة. نوصي بشكل خاص بمجموعة أدوات تطبيق Microsoft Web Application. كان يمكّنك من تسجيل البرامج النصية للاختبار ثم محاكاة مئات أو الآلاف من المستخدمين الذين يصلون إلى خادم ويب. كانت تقارير عدد من الإحصائيات ، بما في ذلك الطلبات في الثانية ، وتوزيع وقت الاستجابة ، وعدد الأخطاء. كان متاحًا في كل من واجهة العميل الغنية وواجهة قائمة على الويب تمكنك من إجراء الاختبارات عن بُعد.

تأكد من قراءة دليل ضبط IIS 5.0.

نصيحة 28: قراءة روابط الموارد

أدناه هي روابط لبعض الموارد الرائعة المتعلقة بالأداء. إذا كنت ترغب في معرفة ذلك ، فاقرأ تطوير تطبيقات الويب القابلة للتطوير.

تحسين

الموارد البرامج النصية ASP تطوير تطبيقات ويب قابلة للتطوير

أي

ذاكرة التخزين

المؤقت

؟

وموارد السرعة والتحسين

من تأليف نانسي وينيك كلوتس

وتحسين IIS

فن وعلوم خادم الويب لضبط خدمات الإنترنت

5.0

الاستفادة

أداء الخادم من قبل Michael Stephenson

والتنقل في متاهة الإعدادات لتحسين أداء خادم الويب

من قبل Mike Moore

وإدارة معلومات الإنترنت الخادم 4.0 للأداء من قبل Todd Wanke و

ADO و SQL Server

Top Ten Tips: الوصول إلى SQL من خلال ADO

وتحسين أداء تطبيق MDAC الخاص بك بواسطة

JD Meier

تجمع في مكونات الوصول إلى بيانات Microsoft من قبل Suresh Kannan ،

SQL Server: معايير الأداء والأدلة من قبل

تحسين أداء مكونات الوصول إلى البيانات مع IIS 4.0 ،

مكونات Microsoft Data للبيانات ( MDAC) و ActiveX Data Objects (ADO) نصائح الأداء من قبل Leland Ahlbeck ،

Microsoft

SQL Server 7.0 ضبط الأداء العملي وتحسينه - منظور الخادم من قبل Leland Ahlbeck ،

Microsoft SQL Server 7.0 توليف الأداء والتحسين العملي - The Server By Server Lindauer - The Damien Lindauer. منظور التطبيق من قبل Damien Lindauer

الوصول إلى المسلسلات عبر الإنترنت بواسطة Dino Esposito

ASP

إرشادات مكونات من قبل JD Meier

Q243548: معلومات: إرشادات التصميم لمكونات VB ضمن

نماذج

التي أوضحها Nancy Winnick Cluts

معًا

مكونات خادم نشطة مع ATL من قبل

Nancy Winnick Cluts

وبناء مكونات متوسطة عالية الأداء مع C ++ من

نيل ألان

صفحات الخادم النشط و COM من قبل Jon Flanders Apartments ، من قبل DON BOX ،

House of Com: صفحات خادم نشطة ، من قبل Don Box ،

House of Com: Counsts ، by ​​Don Box ،

House of Com: مقايضات الأداء لبيئة تنفيذ مكونات Windows 2000 ، بواسطة Don Box ،

بناء مكونات COM التي تستفيد بالكامل من Visual Basic and Scripting ، بقلم IVO Salmre ،

مكون

MTS

، إنشاء كائن ذاكرة التخزين المؤقت للصفحة ، بقلم روبرت كولريدج ،

يختتم

كائن القاموس: ينشئ فريق ASP كائنًا للبحث عن طاولة البحث ، بواسطة روبرت كارتر

Caprock

Senter Commerce Edition

Q175167: Howto: استمرار القيم بدون جلسات

Q157906

Howto

: كيفية الحفاظ على الحالة عبر الصفحات مع

سلوكيات الثبات المستندة إلى XML FELS FINCEL FINCER WEB FARRACHES بواسطة AARON SKONNARD

HOUSE OF COM.

المواقع التي تستخدم أداء خادم Microsoft Windows DNA Platform

و Killers ، من قبل George Reilly

Microsoft

Visual Studio Center

Fitch & Mather Stocks 2000

Tuning the FMStocks Application Application

Visual

Pasic

وكيفية منعهم من قبل Gary Geiger و Jon Pulsipher

Building من HTML ثابتة إلى مزرعة ويب عالية الأداء بواسطة

أداة إجهاد تطبيق Shawn Bice Microsoft

يمكنني

التأكيد عليها بما فيه الكفاية-قم بتحميل اختبار ASP الخاص بك ، بواسطة JD Meier

Windows DNA

أدوات الأداء

في التطبيقات الموزعة باستخدام Visual Studio Analyzer ، بواسطة Mai-Lan Tomsen

Bibliography

Professional Server Pages 3.0 ، Wrox Press (خاصة الفصل 26: تحسين أداء ASP ، جورج رايلي مع Matthew Gibbs).

Microsoft Internet Information Services 5.0 Guide Resource (مع Windows 2000 Server Resource Kit) ، Microsoft Press.

Microsoft Internet Internet Server Server Kit (لـ IIS 4.0) ، Microsoft Press.

برمجة التطبيقات الموزعة مع COM و Microsoft Visual Basic 6.0 ، بقلم Ted Pattison ، Microsoft Press.

كوم فعال ، من دون بوكس ​​، كيث براون ، تيم إيوالد ، وكريس يبيعون ؛

تطوير قابلية استخدام الويب: ممارسة البساطة ، بقلم جاكوب نيلسن ، الدراجين الجدد.

ASP Web Sitesmicrosoft

Technet لـ IIS

LearnAsp.com

4GuySfromRolla.com

15Seconds.com

asptoday.com

asp101.com

asplists.com. تشمل العديد من القوائم البريدية المهنية:

رمز سريع!
ASP المتقدمة
ليس Newbiestate الإدارة
قابلية التوسع
مكونات Visual Basic
XML
C ++/ATL Component Building
useit.com: قابلية استخدام الويب على الويب

ASP

ASP أفضل ممارسات George Reilly

ASP الدروس السريعة من قبل Charles Carroll

Planning لـ ASP John Meade

XML

بواسطة JD Meier

داخل أداء XML بواسطة Chris Lovett

داخل أداء MSXML3 بواسطة Chris Lovett