شبکه و آنتی ویروس و نرم افزار و زبانهای برنامه نویسی

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

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

• پياده سازی سيستم 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 غير فعال نمود . دستور زير نحوه انجام اين كار را نشان می دهد  :

برای غير فعال كردن 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 مصرف می كند آگاهی يافت . 
در بخش دوم به بررسی ساير نكات به منظور افزايش كارآئی‌ برنامه های وب با تمركز بر روی بانك های اطلاعاتی در زمان طراحی خواهيم پرداخت .