بخشی از مقاله

افزايش كارآئی برنامه های وب در ASP.NET 2.0


( بخش اول )
يكی از ملزومات كليدی در هر نوع برنامه كامپيوتری ميزان كارائی و قابليت پاسخگوئی سريع آن به كاربران است . طراحان و پياده كنندگان برنامه های كامپيوتری می بايست در زمان طراحی ، پياده سازی و نوشتن كد به اين موضوع توجه جدی داشته باشند.
برنامه های وب با توجه به ماهيت و رسالت خود می بايست قادر به ارائه خدمات مورد نياز به صدها و يا هزاران متقاضی همزمان به سادگی و با سرعت مطلوب باشند. به عبارت ديگر ، همزمان با افزايش كاربران نمی بايست شاهد افت سرعت و كارآئی يك برنامه وب باشيم .


با ارائه فريمورك دات نت و به دنبال آن ASP.NET ، پياده سازی يك برنامه وب بطرز ناباورانه ای ساده شده است . همين موضوع باعث شده است كه طراحان و پياده كنندگان بيشتر در انديشه طراحی و پياده سازی سريع برنامه های وب باشند و به مسائل مربوط به كارآئی برنامه كمتر توجه نمايند .
پياده كنندگان برنامه های وب با استفاده از فناوری ASP.NET می بايست با بكارگيری مجموعه ای از ترفندها ، فناوری ها و رعايت برخی نكات كليدی اقدام به پياده سازی برنامه های وب با كارآئی بالا نمايند .


در اين مقاله و ساير مقالاتی كه در آينده منتشر خواهد شد قصد داريم به برخی از روش های موجود به منظور طراحی و پياده سازی يك برنامه وب كارآ اشاره نمائيم . بدين منظور بر روی سه محور اساسی زير متمركز خواهيم شد :
• طراحی برای كارآئی : در اين رابطه به مجموعه ای از نكات كليدی اشاره خواهيم كرد كه رعايت آنها در زمان طراحی می تواند زمينه پياده سازی يك برنامه وب كارآ را فراهم نمايد .


• تست برنامه قبل از عملياتی شدن آن : يكی از مسائل مهم در ارتباط با برنامه های وب ، عدم تست آنها با شرايط مشابه و يا نزديك به محيط واقعی است . در اين راستا می توان از نرم افزارها و يا ابزارهای مختلفی استفاده كرد تا بتوان عملكرد و سرويس دهی يك برنامه وب را قبل از زير بار رفتن واقعی مشاهده و بررسی نمود . شركت مايكروسافت در اين رابطه ابزارها و برنامه های متعددی را ارائه نموده است كه به بررسی آنها خواهيم پرداخت .
• پياده سازی سيستم caching : با پياده سازی سيستم caching در سطوح متفاوت و caching داده می توان كارآئی برنامه های وب را بطرز كاملا" محسوسی افزايش داد. در اين بخش به نحوه پياده سازی سيستم caching در برنامه های وب اشاره خواهيم كرد .
در ادامه بر روی اولين محور متمركز و به بررسی مسائل مرتبط با آن خواهيم پرداخت .


طراحی برای كارآئی
توجه و رعايت موارد زير پياده كنندگان را در جهت پياده سازی برنامه های وب با كارآئی بالا كمك خواهد كرد :
مكانيزم ترجمه كد در ASP.NET
برنامه های نوشته شده با استفاده از ASP.NET دارای كارآئی بمراتب بيشتری نسبت به برنامه های نوشته شده با استفاده از ASP كلاسيك می باشند . اين دستاورد ناشی از ترجمه اتوماتيك كد در ASP.NET است . در صفحات قديمی نوشته شده با استفاده از ASP كلاسيك ، كدها و يا اسكريپت های موجود در يك صفحه برای هر يك از درخواست های كاربران پردازش می گرديد . در ASP.NET ، هر كلاس صفحه در اولين مرتبه دستيابی كمپايل و برای درخواست های آتی cache می گردد .


زمانی كه اولين مرتبه يك كاربر صفحه ای را درخواست می نمايد ( و يا اولين مرتبه دستيابی پس از ايجاد تغييرات در صفحه ) ، يك تاخير قابل ملاحظه در زمان پاسخ به درخواست خود را مشاهده می نمايد ( تاخير ناشی از ترجمه صفحه ) . برای برخورد با اين موضوع می توان از روش precompilation استفاده نمود . با استفاده از روش فوق پس از استقرار صفحات بر روی سرويس دهنده وب ، بلافاصله امكان درخواست و بازيابی سريع آنها برای متقاضيان فراهم می گردد .
كنترل های سرويس دهنده
كنترل های سرويس دهنده عناصر اصلی در يك صفحه ASP.NET می باشند و load زيادی را به برنامه تحميل نخواهند كرد . اين نوع كنترل ها معمولا" دارای كارآئی بمراتب بهتری نسبت به زمانی می باشند كه يك صفحه به صورت پويا و با استفاده از ترفندهائی نظير متد Response. Write خروجی خود را توليد می نمايد.


در برخی موارد ضرورتی به استفاده از كنترل های سرويس دهنده ASP.NET در يك صفحه وب نخواهيم داشت . به عنوان نمونه ،‌ در صورتی كه دارای يك متن ايستا می باشيم كه هرگز ضرورتی به دستيابی و تغيير آن در زمان اجراء و از طريق كد نداريم ، لزومی به استفاده از كنترلی نظير label نخواهيم داشت . در چنين مواردی می توان به سادگی متن مورد نظر را با استفاده از امكانات HTML در فايل aspx. قرار داد . در ويژوال استوديو می توان از كنترل DIV ( موجود در بخش HTML ، منوی Toolbox) استفاده كرد. در واقع ما تكليف متن مورد نظر جهت نمايش در يك صفحه aspx . را نه در زمان اجراء بلكه در زمان طراحی مشخص كرده ايم .


يكی ديگر از نكات مهم در زمان استفاده از كنترل های سرويس دهنده در صفحات وب ، توجه به رفتار آنها در ارتباط با نگهداری داده پس از ارسال مجدد به سرويس دهنده می باشد . به صورت پيش فرض ، مقادير مرتبط با كنترل های سرويس دهنده نظير مقدار درج شده در يك TextBox ، پس از postback بطور اتوماتيك در view state ذخيره می گردد . در واقع ، view state مكانيزمی برای نگهداری داده كنترل های سرويس دهنده است كه هدف آن غلبه بر محدوديت پروتكل HTTP است ( ماهيت stateless ) .


view state ، يك نام مناسب برای ذخيره داده در يك فيلد ورودی مخفی درون صفحه است . پس از post back ( ارسال مجدد برای‌ سرويس گيرنده ) يك صفحه ، سرويس دهنده قادر به بررسی مقادير نگهداری شده در view state و استفاده از آنها با توجه به شرايط حاكم بر برنامه می باشد . view state يك قابليت عالی است چراكه اجازه نگهداری وضعيت را با استفاده از امكانات سرويس گيرنده فراهم می نمايد و در اين رابطه از كوكی و حافظه سرويس دهنده برای ذخيره وضعيت استفاده نمی گردد .


تعداد زيادی از كنترل های سرويس دهنده ASP.NET از view state برای نگهداری تنظميات خود در زمان تعامل با عناصر موجود بر روی صفحه استفاده می نمايند ( مثلا" ذخيره صفحه جاری در زمان استفاده از ويژگی paging در كنترل سرويس دهنده gridview ) .
در زمان استفاده از view state توجه به موارد زير ضروری است :
• playload صفحه را در زمان درخواست و ارائه افزايش می دهد .
• افزايش overhead در زمان serializing و deserializing داده ذخيره شده در view state كه برای سرويس دهنده post-back شده است .


• افزايش تخصيص حافظه بر روی سرويس دهنده
كنترل های سرويس دهنده علاقه زيادی به استفاده از view state دارند حتی در مواردی كه به وجود آن نياز نمی باشد . به صورت پيش فرض viewstate فعال است و در صورت عدم نياز می بايست آن را در سطح صفحه و يا كنترل غيرفعال نمود . در رابطه با يك كنترل كافی است كه خصلت EnableViewState را false و يا می توان آن را به صورت سراسری و در سطح page غير فعال نمود . دستور زير نحوه انجام اين كار را نشان می دهد :
<%@ Page EnableViewState="false" %>


برای غير فعال كردن view state در سطح صفحه و يا كنترل از قوانين زير می توان استفاده نمود :
• در صورتی كه در صفحه ای post back انجام نمی گيرد و يا صفحه می بايست همواره برای هر يك از كنترل های موجود بر روی صفحه و به ازاء هر درخواست مجددا" توليد گردد ، می بايست view state را در سطح page غير فعال نمود .
• در صورتی كه ضرورتی به نگهداری داده مرتبط با يك كنترل سرويس دهنده در view state نمی باشد می بايست آن را برای كنترل مورد نظر غير فعال نمود . بدين منظور لازم است كه مقدار EnableViewState مربوط به كنترل معادل False در نظر گرفته شود .
• در صورتی كه كنترل در زمان طراحی مقداردهی شده است و در زمان اجراء مقدار آن تغيير نمی يابد ، خصلت EnableViewState آن می بايست false در نظر گرفته شود .


• در صورتی كه كنترل با هر post back ، مجددا" خوانده شده و refresh می گردد و ضرورتی به نگهداری مقدار داده قبلی وجود نداشته باشد ، خصلت EnableViewState آن می بايست false در نظر گرفته شود .
• در صورتی كه لازم است انتخاب كاربر پس از postback صفحه بازيابی گردد ، می بايست view state را برای كنترل مورد نظر فعال كرد.
view state ، عموما" كند شدن سرويس دهنده را به دنبال نخواهد داشت بلكه حجم صفحه را افزايش داده و مدت زمان ارسال صفحه برای سرويس گيرنده را زياد خواهد كرد . در چنين مواردی كاربران اين برداشت را خواهند داشت كه برنامه كند و قادر به ارائه پاسخ سريع به آنان نمی باشد ، خصوصا" در مواردی كه ارتباط بين سرويس گيرنده و سرويس دهنده از طريق يك خط با سرعت پائين برقرار شده باشد .


عدم استفاده صحيح از view state در برخی موارد می تواند ادامه حيات موثر يك برنامه وب را با چالش جدی مواجه نمايد . اين موضوع در برنامه هائی كه از كنترل های زيادی در يك صفحه استفاده و حجم بالائی از داده را در خود نگهداری می نمايند، مضاعف می گردد. در چنين مواردی داده دو مرتبه به صفحه وب اضافه می گرد : مستقيما" در كد HTML مرتبط با كنترل و مجددا" در يك فيلد مخفی برای view state . داده فوق با هر post back بين سرويس گيرنده و سرويس دهنده مبادله می گردد .
با استفاده از page tracing می توان از تعداد بايتی كه view state مصرف می كند آگاهی يافت .
در بخش دوم به بررسی ساير نكات به منظور افزايش كارآئی‌ برنامه های وب با تمركز بر روی بانك های اطلاعاتی در زمان طراحی خواهيم پرداخت .
________________________________________
افزايش كارآئی برنامه های وب در ASP.NET 2.0 (بخش دوم)
در بخش اول به اين موضوع اشاره گرديد كه برای طراحی و پياده سازی يك برنامه وب كارآ از روش ها ، ترفندها و فناوری های مختلفی استفاده می گردد . بدين منظور بحث خود را با معرفی سه محور اساسی زير آغاز و با تمركز بر روی اولين محور ادامه داديم .
• طراحی برای كارآئی : در اين رابطه به مجموعه ای از نكات كليدی اشاره خواهيم كرد كه رعايت آنها در زمان طراحی می تواند زمينه پياده سازی يك برنامه وب كارآ را فراهم نمايد .


• تست برنامه قبل از عملياتی شدن آن : يكی از مسائل مهم در ارتباط با برنامه های وب ، عدم تست آنها با شرايط مشابه و يا نزديك به محيط واقعی است . در اين راستا می توان از نرم افزارها و يا ابزارهای مختلفی استفاده كرد تا بتوان عملكرد و سرويس دهی يك برنامه وب را قبل از زير بار رفتن واقعی مشاهده و بررسی نمود . شركت مايكروسافت در اين رابطه ابزارها و برنامه های متعددی را ارائه نموده است كه به بررسی آنها خواهيم پرداخت .
• پياده سازی سيستم caching : با پياده سازی سيستم caching در سطوح متفاوت و caching داده می توان كارآئی برنامه های وب را بطرز كاملا" محسوسی افزايش داد. در اين بخش به نحوه پياده سازی سيستم caching در برنامه های وب اشاره خواهيم كرد .
در اين بخش همچنان بر روی اولين محور متمركز و به بررسی مسائل در ارتباط با بانك های اطلاعاتی و تاثير آنها در كارآئی يك برنامه وب اشاره خواهيم كرد .


دستيابی به بانك اطلاعاتی
قوانين دستيابی به بانك های اطلاعاتی خيلی سرراست و مشخص است ولی به دليل عدم رعايت برخی نكات توسط طراحان و پياده كنندگان ممكن است كارآئی برنامه های وب كاهش و همزمان با افزايش كاربران امكان استفاده بهينه و مطلوب از برنامه وجود نداشته باشد .
قبل از بررسی اهم مطالب مرتبط با بكارگيری بانك های اطلاعاتی در برنامه های وب لازم است به اين نكته مهم اشاره گردد كه می بايست يك اتصال به بانك اطلاعاتی را صرفا" در زمانی كه به وجود آن نياز است ايجاد و در اولين فرصت ممكن آن را close كرد چراكه اولا" تعداد اتصالات به يك بانك اطلاعاتی محدود و ثانيا" مديريت آنها كار اضافه ای را نيز به سرويس دهنده تحميل خواهد كرد ( استفاده بهينه از يك منبع محدود ) .


با رعايت موارد زير می توان كارآئی برنامه های وب را بهبود بخشيد :
• استفاده از stored procedure : سيستم های مديريت بانك های اطلاعاتی رابطه ای نظير SQL server پيچيدگی های خاص خود را دارند . سيستم های فوق، قادر به انجام كارهای متنوعی هستند كه با استفاده از ASP.NET نمی توان آنها را انجام داد . بكارگيری اين نوع پتانسيل ها می تواند تاثيرات گسترده ای را بر روی برنامه های وب به دنبال داشته باشد . به عنوان نمونه ، استفاده از stored procedure در مقابل Query های توليد شده پويا می تواند تاثير غيرقابل انكاری بر روی كارآيی برنامه های وب داشته باشد چراكه stored procedure را می توان برای استفاده آتی ترجمه و بهينه سازی كرد . تاثير استفاده از stored procedure در مواردی كه لازم است چندين عمليات مرتبط به هم در يك لحظه انجام شود ، بسيار مشهود و ملموس می باشد .


• استفاده از پروفايلينگ و ايندكس : تعريف ايندكس ها بگونه ای كه با نوع جستجو و خواسته های مورد نياز در يك سيستم مطابقت نمايد ، می تواند نتايج مورد نظر را با سرعت قابل قبولی در اختيار كاربران قرار دهد . برای بهينه سازی بی عيب ايندكس ها در يك بانك اطلاعاتی لازم است كه آنها را با استفاده از يك ابزار profiling ارزيابی كرد ( نظير SQL Server Profiler ) . اين نوع ابزارها فعاليت بانك اطلاعاتی را در يك لاگ خاص ثبت می نمايند و در ادامه می توان آن را بررسی ، آناليز و بر اساس نتايج بدست آمده در ايندكس ها تجديد نظر نمود . ابزارهای فوق می توانند مسائلی نظير اجرای كند query را شناسائی و حتی مجموعه ای جديد از ايندكس ها را كه دارای كارآئی بمراتب بهتری می باشند ، پيشنهاد دهند . برای پروفايل بهتر بانك اطلاعاتی لازم است كه يك لود فرضی را بر روی برنامه شبيه سازی كرد.


• بازيابی صرفا" اطلاعات مورد نياز : يكی از ساده ترين روش هائی كه باعث بهبود هر نوع كد بانك اطلاعاتی می گردد ، كاهش حجم اطلاعات بازيابی شده از بانك اطلاعاتی است . اين كار باعث كاهش لود شبكه ، مدت زمان لازم برای باز شدن اتصال و حجم نهائی صفحه می گردد . به عنوان نمونه با استفاده از فيلترينگ مناسب در query ( نظير استفاده از تاريخ ) و بازيابی صرفا" فيلدهای ضروری ، می توان حجم داده بازيابی شده را حتی المقدور كاهش داد .


• استفاده از connection pooling : در يك برنامه وب عمومی ، سيستم مديريت بانك اطلاعاتی درخواست های بيشماری را از طرف سرويس گيرندگان برای صفحات وب متعدد دريافت می نمايد . معمولا" اين اتصالات برای مدت زمان كوتاهی فعال و ايجاد آنها يكی از مراحل وقت گير در زمان پياده سازی است . در صورتی كه هر صفحه وب از connection string مشابه استفاده نمايد ، بانك های اطلاعاتی نظير SQL server قادر به استفاده از connection pooling تعبيه شده در خود برای استفاده مجدد از يك اتصال برای بيش از يك سرويس گيرنده متوالی می باشند . بدين ترتيب امكان استفاده از connection string به دفعات فراهم می گردد. اين كار بطرز چشمگيری باعث بهبود سرعت می گردد . در چنين مواردی می توان از فايل web.config برای ذخيره connection string استفاده تا امكان بكارگيری آنها در صفحات متعدد يك برنامه وب فراهم گردد.


• استفاده از date binding : سريعترين روش بازيابی و نمايش اطلاعات از يك بانك اطلاعاتی ، استفاده از يك DataReader و يا Dataset و نسبت دهی مستقيم آن به يك كنترل داده است . رويكرد فوق ممكن است به عمليات بيشتری جهت استفاده از تمپليت های سفارشی نياز داشته باشد ولی اين وضعيت بمراتب بهتر از حالتی است كه بطور دستی بين سطرها ( ركوردها ) حركت و آنها را در صفحه مورد نظر قرار داد.
• استفاده از caching : در صورتی كه مجموعه ای خاص از داده متناوبا" درخواست و بندرت تغيير می يابد ، می توان آنها را جهت استفاده آتی cache نمود . با استفاده از سيستم caching ، در اولين مرتبه ای كه يك سرويس گيرنده درخواست اطلاعات را می نمايد ، اطلاعات درخواستی از بانك اطلاعاتی خوانده شده و در حافظه موقت قرار می گيرند . بدين ترتيب امكان استفاده مستقيم از اطلاعات cache شده بدون ضرورت دستيابی به بانك اطلاعاتی فراهم می گردد . در بخش های بعدی به بررسی Output caching و data caching خواهيم پرداخت .


session state
session state يكی از بزرگترين محدوديت های تاثير گذار در خصوص كارآئی برنامه های نوشته شده با استفاده از ASP كلاسيك است . با اين كه در ASP.NET ويژگی های جديدی به منظور بهبود كاركرد session state ارائه شده است ولی همچنان لازم است كه از آن با دقت استفاده گردد .
اگر صرفا" ID يك خريدار كالا را در session state ذخيره كرده باشيم، درگير مسائلی خاص نخواهيم شد . در چنين مواردی می توان يك سبد خريد كالای الكترونيكی را با ذخيره ليستی از محصولات انتخابی توسط خريدار ايجاد نمود . در صورتی كه قصد ذخيره حجم بالائی از اطلاعات نظير يك Dataset را داشته باشيم ، می بايست در اين رابطه دقت و تاثير آن را بر روی موفقيت برنامه بررسی كرد . به عنوان نمونه ، در صورتی كه هر session فضائی به ميزان يك مگابايت را استفاده نمايد ، يكصد session همزمان باعث استفاده 100 مگابايت از حافظه خواهد شد .


برای حل اين نوع از مشكلات ، در زمان طراحی می توان بر اساس يكی از دو گزينه های زير تصميم گيری نمود :
• ذخيره تمامی اطلاعات مورد نياز در يك ركورد بانك اطلاعاتی و ذخيره ID ركورد مورد نظر در يك session . روش فوق باعث صرفه جوئی در مصرف حافظه می گردد ولی سرعت برنامه را كاهش خواهد داد ( با توجه به فرآيند دستيابی به بانك اطلاعاتی كه يكی از عناصر مهم و تاثيرگذار در خصوص كارآئی برنامه های وب است ) .


• به عنوان يك راه حل بهتر می توان اطلاعات مورد نظر را در يك ركورد بانك اطلاعاتی ذخيره و در ادامه برخی از اطلاعات را در حافظه cache نمود . بدين ترتيب ، امكان بازيابی اطلاعات با سرعت بيشتری فراهم می گردد . در بخش های بعدی با data caching بيشتر آشنا خواهيم شد .
بهترين روش و يا گزينه برای ذخيره session ، استفاده از روش in-process است كه به صورت پيش فرض در نظر گرفته می شود . برای ذخيره session می توان از روش های ديگری نظير يك بانك اطلاعاتی SQL نيز استفاده نمود . استفاده از روش فوق پردازش های بيشتری را به سيستم تحميل و صرفا" در مواردی كه وب سايت مورد نظر در يك web farm به همراه چندين سرويس دهنده هاست شده باشد ، توصيه می گردد .


محور دوم : تست برنامه قبل از عملياتی شدن آن و يا پروفايلنگ ( Profiling )
برای قضاوت در خصوص تلاش های انجام شده در ارتباط با بهبود كارآئی يك برنامه وب ، می بايست قادر به سنجش كارآئی آن در عمل باشيم . در مواردی كه كارآئی يك برنامه كند و نااميد كننده است ، می بايست بر اساس اطلاعات كافی اقدام به شناسائی گره ها و عوامل تاثير گذار بر روی كارآئی برنامه های وب نمائيم تا از اين رهگذر بتوانيم مشكل و يا مشكلات را برطرف و يك برنامه وب كارآ را آماده استفاده عملياتی و نهائی نمائيم .
در بخش سوم به بررسی امكانات و ابزارهای موجود برای تست برنامه های وب خواهيم پرداخت .
________________________________________
افزايش كارآئی برنامه های وب در ASP.NET 2.0 (بخش سوم)
در بخش های اول و دوم به مجموعه ای از نكات اشاره گرديد كه رعايت آنها در زمان طراحی می تواند زمينه پياده سازی يك برنامه وب كارآ را فراهم نمايد . در اين بخش به بررسی امكانات و ابزارهای موجود برای تست برنامه های وب خواهيم پرداخت .
يكی از مسائل مهم در ارتباط با برنامه های وب ، عدم تست آنها با شرايط مشابه و يا نزديك به محيط واقعی است . در اين راستا می توان از نرم افزارها و يا ابزارهای مختلفی استفاده كرد تا بتوان عملكرد و سرويس دهی يك برنامه وب را قبل از زير بار رفتن واقعی مشاهده و بررسی نمود .


برای قضاوت در خصوص تلاش های انجام شده در ارتباط با بهبود كارآئی يك برنامه وب ، می بايست قادر به سنجش كارآئی آن در عمل باشيم . در مواردی كه كارآئی يك برنامه كند و نااميد كننده است ، می بايست بر اساس اطلاعات كافی اقدام به شناسائی گره ها و عوامل تاثير گذار بر روی كارآئی برنامه های وب نمائيم تا از اين رهگذر بتوان مشكل و يا مشكلات را برطرف و يك برنامه وب كارآ را آماده استفاده عملياتی و نهائی كرد .
شركت مايكروسافت در اين رابطه ابزارها و برنامه های متعددی را ارائه نموده است كه در ادامه به بررسی آنها خواهيم پرداخت .

Stress Testing
پياده كنندگان برنامه های وب می توانند از ابزارهای تست متعدد به همراه برخی امكانات ارائه شده در فريمورك دات نت برای پروفايل كردن برنامه های ASP.NET استفاده نمايند . اغلب ، گذر از مرحله تست و اعمال يك پل ارتباطی بين نتايج تست و برنامه وب كار زمان گيری است . به عنوان نمونه ممكن است در مرحله تست بتوان اطلاعات مهمی نظير TTFB ( برگرفته شده از Average Time to first byte ) كه نشان دهنده مدت زمان ارسال درخواست و دريافت اولين بايت از سرويس دهنده است و يا TTLB ( برگرفته شده از Average Time to last byte ) كه نشان دهنده زمان ارسال درخواست و دريافت آخرين بايت از سرويس دهنده است را ركورد و ثبت نمود . ولی بدون استفاده از يك روش دقيق و صحيح اندازه گيری ، تشخيص پارامترهای تاثيرگذار در كاهش كارآئی يك برنامه وب كار مشكلی خواهد بود .


به عنوان مثال ، كاهش كارآئی يك برنامه وب ممكن است مربوط به سرعت پائين هارد ديسك ، تنظيمات ضعيف ASP.NET ، عدم طراحی صحيح بانك اطلاعاتی و يا عدم طراحی مناسب برنامه باشد . در واقع‌، تست كارآئی علم و دانش مختص به خود را دارد .
برای انجام اكثر تست های اوليه ، می توان از يك سرويس دهنده اختصاصی و مجموعه ای از سرويس گيرندگان استفاده نمود كه از طريق يك شبكه سريع ايزوله شده با سرويس دهنده وب تعامل برقرار می نمايند . بدين منظور می توان از يك ابزار توليد load كه بطور اتوماتيك مجموعه ای ‌از صفحات را از سرويس دهنده درخواست می نمايد استفاده كرد تا يك لود سنگين شبيه سازی گردد . ACT ( برگرفته شده از Application Center Test ) و WAST ( برگرفته شده از Web Applications Stress Tool ) دو نمونه متداول در اين زمينه می باشند .


با استفاده از ابزارهای فوق می توان شرايط حاكم بر يك برنامه وب در دنيای واقعی را شبيه سازی نمود ( تداوم درخواست صفحات از طريق چندين اتصال همزمان ) . اكثر ابزارهای توليد load ، فعاليت ها و كارهائی را كه انجام می دهند ثبت می نمايند تا امكان بررسی آنها توسط طراحان و پياده كنندگان وجود داشته باشد .
علاوه بر برنامه های فوق ، می توان نتايج را با استفاده از Windows performance counters ثبت و مشاهده كرد .


performance counter
برنامه performance counters ويندوز يكی از ابزارهای متداول موجود برای اندازه گيری كارآئی يك برنامه می باشد . با استفاده از برنامه فوق می توان به تعداد دلخواه counter را اضافه و يا مستقيما" كارآئی را از طريق جعبه محاوره ای system performance اندازه گيری كرد .
برای فعال كردن برنامه فوق می توان از مسير Settings|Control Panel |Administrative Tools |Performance استفاده كرد. اين برنامه به صورت پيش فرض صرفا" كارآئی پردازشگر اصلی سيستم و ديسك را اندازه گيری می نمايد .


پس از نصب ASP.NET ، مجموعه ای counter مفيد برای رديابی و ارزيابی كارآئی برنامه های وب نيز نصب می گردد . برای اضافه كردن counter ، با كليك (سمت راست) بر روی ليست counter و انتخاب properties ، می توان گزينه های مختلفی را پيكربندی نمود ( نظير تغيير شكل ظاهری نمودار و نحوه ثبت اطلاعات در قالب يك گزارش ) .
يكی از مهمترين گزينه ها بخش مربوط به Data است كه با استفاده از آن می توان به ليست موجود يك counter را اضافه و يا از آن حذف نمود . برای شروع ، می توان تمامی كانتر های پيش فرض را حذف و با استفاده از گزينه Add موارد دلخواه را به ليست اضافه نمود .

شكل 1 : اضافه كردن يك counter جديد
در جعبه محاوره ای Add Counter ، چندين ويژگی مهم از جمله امكان مشخص كردن نام كامپيوتر وجود دارد . به عبارت ديگر ، شما می توانيد كارآئی يك كامپيوتر راه دور را مانيتور نمائيد . مانيتورينگ كارآئی سرويس دهنده وب از طريق يك سرويس گيرنده ايده آل است چراكه احتمال تاثير عملكرد مانيتورينگ بر روی سرويس دهنده از بين خواهد رفت . ويژگی مهم بعدی ، performance object است كه با استفاده از آن می توان يك گروه counter را متناسب با شی مورد نظر انتخاب نمود . گروه ASP.NET اطلاعات كاملی را در خصوص كارآئی كلی برنامه های ASP.NET ارائه می نمايد . اين در حالی است كه گروه ASP.NET Application اطلاعاتی را در رابطه با يك برنامه وب خاص ارائه می نمايد .


برخی از انواع مفيد كانترها به همراه گروه ، نام counter و عملكرد هر يك از آنها در جدول 1 نشان داده شده است .
سطرهای ستاره دار، كانترهائی را مشخص می نمايد كه با استفاده از آنها می توان اشكال زدائی يك مسئله را انجام داد . ساير سطرها ، كانترهائی را نشان می دهد كه استفاده از آنها همواره مفيد می باشد .
گروه counter عملكرد
processor % CPU Utilization درصد استفاده از CPU را نشان می دهد . در صورتی كه استفاده از CPU در يك بازه زمانی صرفنظر از load سرويس گيرنده ثابت باقی بماند ، نشان دهنده انتظار يك برنامه برای استفاده از يك منبع محدود است .
ASP.NET Requests Queued تعداد درخواست های در انتظار پردازش را مشخص می نمايد . از counter فوق برای مشخص كردن حداكثر load سرويس دهنده وب استفاده می گردد .


ASP.NET * Application Restarts ,
Worker Process Restarts تعداد دفعاتی كه پردازه ASP.NET راه اندازی مجدد و يا reset می گردد را مشخص می نمايد . اين counter نشاندهنده بروز مسائل ناخواسته است.
ASP.NET Applications Requests/Sec حداكثر توان عملياتی برنامه وب را مشخص می نمايد .
ASP.NET Applications * Errors Total تعداد خطاء توليد شده توسط يك برنامه وب را مشخص می نمايد . مقدار اين counter در عمل می بايست صفر و يا نزديك به صفر باشد .
ASP.NET Applications Pipeline Instance Count تعداد درخواست pipeline يك برنامه را مشخص می نمايد و از آن برای مشخص شدن حداكثر درخواست همزمانی كه می توان به آنها پاسخ داده شود ، استفاده می گردد .
در صورتی كه مقدار اين counter تحت يك load پائين باشد ، نشان دهنده استفاده مطلوب از CPU است .
System * Context Switches/sec پارامتر فوق تعداد دفعات سوئيچينگ thread context را نشان می دهد . در صورتی كه مقدار اين پارامتر زياد باشد ، thread های مختلف برای استفاده از يك منبع محدود با يكديگر رقابت می نمايند .


جدول 1 : ليست برخی كانترهای مفيد
دستيابی به كلاس های performance counters از طريق كد
با توجه به اين كه ASP.NET بخشی از فريمورك دات نت است ، پياده كنندگان برنامه های وب می توانند در صفحات وب نوشته شده با استفاده از فناوری ASP.NET به تمامی كلاس های موجود در فريمورك دات نت دستيابی داشته باشند .

اين بدان معنی است كه از طريق يك صفحه وب ASP.NET می توان عمليات متعددی نظير پردازش تصاوير ، نوشتن در event log و يا خواندن و انعكاس performance counters در خروجی را انجام داد . گرچه استفاده از امكاناتی از اين قبيل ممكن است چالش های امنيتی مختص به خود را دارا باشد ولی با رعايت نكات ايمنی می توان پتانسيل برنامه های وب را در جهت ارائه خدمات مطلوب و بهينه به كاربران افزايش داد .

در متن اصلی مقاله به هم ریختگی وجود ندارد. برای مطالعه بیشتر مقاله آن را خریداری کنید