تاريخ جاري سيستم را در خروجي نشان مي دهد ، بررسي مي نمائيم .
%@ OutputCache Duration=”20″ VaryByParam=”None” %


متداولترين روش caching يك صفحه ASP.NET ، درج دايركتيو OutputCache در ابتداي فايل aspx . است . كد زير نحوه استفاده از دايركتيو فوق را نشان مي دهد :
%@ OutputCache Duration=”20″ VaryByParam=”None” %
در دايركتيو فوق از دو خصلت Duration و VaryByParam استفاده شده است . خصلت Duration به ASP.NET اعلام مي نمايد كه صفحه را به مدت 20 ثانيه cache نمايد. خصلت VaryByParam ميزان وابستگي فرآيند caching را به يك و يا چندين پارامتر مشخص مي نمايد . در برخي موارد ممكن است اين وابستگي مهم نباشد و مقدار آن None در نظر گرفته شود ( همانند مثال فوق ) .
پس از ذخيره كد فوق در فايلي با نام CacheExample1.aspx و اجراء آن ، نتايج جالب و قابل توجه اي را مشاهده خواهيم كرد . اولين مرتبه اي كه صفحه درخواست مي گردد ، تاريخ و زمان جاري در خروجي نمايش داده مي شود .در صورتي كه پس از گذشت مدت زمان بسيار كوتاهي صفحه را refresh نمائيم ، خروجي صفحه بهنگام نخواهد شد . در مقابل ، ASP.NET بطور اتوماتيك خروجي نسخه cache شده را ارسال خواهد كرد . وضعيت فوق به مدت 20 ثانيه ادامه خواهد يافت و پس از اتمام تاريخ مصرف نسخه cache شده ، ASP.NET مجددا” كد صفحه را اجراء و يك نسخه جديد cache را ايجاد و از آن به مدت 20 ثانيه ديگر استفاده خواهد كرد .
شايد بنظر 20 ثانيه زمان زيادي نباشد ولي براي سايتي كه حاوي اطلاعات گسترده اي جهت ارائه به كاربران متعدد است ، اين موضوع مي تواند كاملا” متفاوت باشد. به عنوان نمونه ، فرض كنيد مي خواهيم ليستي از محصولات قابل عرضه به كاربران را در يك صفحه نمايش دهيم . با caching صفحه به مدت 20 ثانيه ، دستيابي به بانك اطلاعاتي محدود به سه عمليات در يك دقيقه مي گردد . بدون caching ، براي هر كاربري كه متقاضي مشاهده ليست محصولات است ، مي بايست فرآيند ارتباط با بانك اطلاعاتي و نمايش محصولات در يك ساختار نمايشي مناسب ( نظير Gridview ) انجام شود . بديهي است با caching صفحه به مدت 20 ثانيه امكان پاسخگوئي به ده ها درخواست در مدت زمان فوق و بدون نياز به دنبال كردن فرآيند ارتباط با بانك اطلاعاتي و نمايش داده انجام مي شود .
توجه داشته باشيد كه اگر مدت زمان حضور يك نسخه cache در حافظه 20 ثانيه تعيين شده باشد ، اين بدان معني نخواهد بود كه واقعا” در طي مدت زمان فوق نسخه cache شده در حافظه وجود خواهد داشت . صفحه مورد نظر ممكن است در اولين فرصتي كه سيستم به منظور انجام كارهاي اساسي تر خود با كمبود حافظه مواجه شود از آن خارج گردد . بدين ترتيب ، پياده كنندگان مي توانند با خيالي آسوده از cache استفاده نمايند بدون اين كه نگران تاخير در اجراي برنامه به دليل استفاده از عنصر حياتي حافظه توسط cache باشند.
زماني كه يك صفحه cache شده مجددا” ترجمه مي گردد ، ASP.NET بطور اتوماتيك صفحه را از cache خارج مي نمايد . بدين ترتيب از بروز مسائلي نظير عدم وجود نسخه بهنگام شده در cache ممانعت بعمل مي آيد .
در زمان تست برنامه بهتر است كه caching غير فعال گردد . در زمان استفاده از روش ها و تكنيك هاي اشكال زدائي نظير متغيرهاي watch و يا ايجاد نقاط breakpoint ممكن است با مشكلاتي‌ مواجه شويم . در چنين مواردي در صورتي كه يك نسخه cache شده از صفحه در دسترس باشد ، كد مرتبط با آن در زمان اشكال زدائي اجراء نخواهد شد .
Caching سمت سرويس گيرنده
يكي ديگر از گزينه ها ، cache صفحه در سمت سرويس گيرنده است . در اين روش ، مرورگر نسخه اي از صفحه را ذخيره و بطور اتوماتيك از آن در مواردي كه دكمه back مرورگر كليك و يا آدرس URL صفحه مجددا” تايپ شود، استفاده مي نمايد . در صورتي كه كاربر دكمه Refresh را فعال نمايد ، از نسخه cache شده صرفنظر و صفحه مجددا” از سرويس دهنده درخواست مي گردد .
براي cache يك صفحه در سمت سرويس گيرنده از خصلت Location در دايركتيو OutputCache استفاده مي گردد . مقدار پيش فرض اين خصلت server است و مي تواند مقادير ديگر نظير Client ، None و Any را به آن نسبت داد .
%@ OutputCache Duration=”20″ VaryByParam=”None” Location=”Client” %
استفاده از caching سمت سرويس گيرنده بمراتب كمتر از caching سمت سرويس دهنده است چراكه صفحه همچنان براي هر كاربر خاص مجددا” ايجاد خواهد شد . در روش فوق ، شاهد كاهش مدت زمان اجراء كد و يا دستيابي به بانك اطلاعاتي در جهت بهبود كارآئي برنامه نخواهيم بود . از روش caching سمت سرويس گيرنده در موارد خاصي نظير زماني كه صفحه cache شده حاوي داده سفارشي و مختص به يك كاربر است ، استفاده مي گردد .
در صورتي كه هر كاربر در يك session مجزاء فعاليت مي نمايد ، صفحه يك مرتبه ايجاد و تمامي سرويس گيرندگان از آن استفاده خواهند كرد . در چنين وضعيتي ممكن است عملكرد يك صفحه با مشكل مواجه گردد ( نظير نمايش يك پيام خوش آمدگوئي به كاربر و بر اساس نام آن ) . در مقابل ، مي توان از fragment caching براي caching بخش هائي خاص از صفحه و يا caching سمت سرويس گيرنده به منظور ذخيره نسخه مختص يك كاربر بر روي كامپيوتر هر يك از سرويس گيرندگان استفاده نمود.
دربخش پنجم به بررسي ساير روش هاي موجود براي output caching خواهيم پرداخت .

افزايش كارآئي برنامه هاي وب در ASP.NET 2.0 (بخش پنجم)
آنچه تاكنون گفته شده است :
بخش هاي اول و دوم : اشاره به مجموعه اي از نكات كه رعايت آنها در زمان طراحي مي تواند زمينه پياده سازي يك برنامه وب كارآ را فراهم نمايد .
بخش سوم : معرفي برخي ابزارها براي تست برنامه هاي وب
بخش چهارم : مفاهيم اوليه caching ، روش هاي caching در ASP.NET ، نحوه استفاده از output caching
در اين بخش بحث خود را در ارتباط با output caching ادامه داده و بر روي Caching و Query string متمركز خواهيم شد.
Caching و Query string
يكي از نكات مهم در خصوص caching ، تصميم در خصوص زمان استفاده مجدد از صفحه و صحت اطلاعات است . اغلب پياده كنندگان تمايل زيادي در ارائه اطلاعات به صورت بلادرنگ دارند و كمتر در انديشه استفاده بهينه از سيستم caching مي باشند . پياده كنندگان مي توانند بدون نگراني در موارد متعددي از caching استفاده نمايند تا كارآئي برنامه هاي وب را افزايش دهند .
در مواردي كه اطلاعات به صورت پويا توليد مي گردد وضعيت caching و يا استراتژي ايجاد و بكارگيري مجدد آن تا اندازه اي متفاوت خواهد بود . به عنوان نمونه ، در صورتي كه در صفحه اي از session كاربر جاري استفاده مي شود تا بر اساس آن رابط كاربر سازماندهي گردد ، caching تمام صفحه مناسب نخواهد بود چراكه يك صفحه مشابه نمي تواند براي ساير كاربران مفيد و قابل استفاده مجدد باشد . يك نمونه ديگر ، صفحه اي است كه اطلاعات دريافتي خود را از يك صفحه ديگر و از طريق query string دريافت مي نمايد . در چنين مواردي صفحه به صورت پويا ايجاد و براي caching آن مي بايست از راهكارهائي ديگر استفاده گردد.
در مثال اشاره شده در بخش چهارم به خصلت VaryByParam دايركتيو OutputCache ، مقدار None نسبت داده شده بود . بدين ترتيب به ASP. NET اعلام شده است كه صرفا” يك نسخه از صفحه را cache نمايد تا بتوان از آن در تمامي حالات استفاده مجدد نمود . در چنين مواردي اگر درخواست صفحه به همراه اضافه كردن آرگومان هاي query string به URL باشد ، صرفا” از همان يك نسخه cache شده بدون توجه به مقدار آرگومان هاي دريافتي استفاده مي گردد ( تا زماني كه تاريخ مصرف نسخه cache شده به اتمام نرسيده باشد ) . شما مي توانيد اين موضوع را با اضافه كردن يك آرگومان query string بطور دستي در مرورگر انجام دهيد . مثلا” سعي كنيد صفحه را با افزودن a=b ? در انتهاي URL اجراء نمائيد. مشاهده خواهيد كرد كه خروجي cache شده همچنان يكسان خواهد بود .
با توجه به نتايج فوق ممكن است اينگونه برداشت شود كه output caching براي صفحه اي كه از آرگومان هاي query string استفاده مي نمايد ، مناسب نباشد . در اين رابطه ASP.NET يك راه حل ديگر را ارائه نموده است . در چنين مواردي مي توان خصلت VaryByParam را “*” در نظر گرفت تا مشخص گردد كه صفحه از query string استفاده مي نمايد و به ASP.NET اعلام گردد كه نسخه هاي cache مجزاء را براي مقادير مختلف آرگومان query string ذخيره نمايد .
%@ OutputCache Duration=”20″ VaryByParam=”*” %
بدين ترتيب زماني كه صفحه به همراه اطلاعات query string درخواست شود ، در ابتدا ASP.NET مقدار query string را بررسي مي نمايد . در صورتي كه رشته دريافتي با درخواست قبلي مطابقت نمايد و يك نسخه cache شده از صفحه موجود باشد ، از آن استفاده خواهد كرد . در غير اينصورت يك نسخه جديد از صفحه ايجاد و بطور جداگانه cache مي گردد براي آشنائي بهتر با نحوه عملكرد فرآيند فوق ، فرض كنيد مجموعه اي از درخواست ها به ترتيب زير دريافت گردد:
كاربري صفحه اي را بدون پارامتر query string درخواست و نسخه A صفحه را دريافت مي نمايد .
كاربري صفحه را با پارامتر ProductID=1 درخواست و نسخه B صفحه را دريافت مي نمايد .
كاربر ديگر صفحه را با پارامتر ProductID=2 درخواست و نسخه C صفحه را دريافت مي نمايد .
كاربر ديگر صفحه را با پارامتر ProductID=1 درخواست مي نمايد . در صورتي كه تاريخ اعتبار نسخه B كه قبلا” cache شده است به اتمام نرسيده باشد ، اين نسخه براي وي ارسال مي گردد.
كاربر ديگر صفحه را بدون پارامتر درخواست مي نمايد . در صورتي كه تاريخ اعتبار نسخه A كه قبلا” cache شده است به اتمام نرسيده باشد ، اين نسخه براي وي ارسال مي گردد.
براي تست فوق و دريافت نتايج بهتر مي توان مدت زمان اعتبار نسخه cache شده را زياد كرد .
در صورتي كه صفحه اي صرفا” در ارتباط با داده سمت سرويس دهنده ( نظير داده موجود در يك بانك اطلاعاتي ) و يا داده موجود در query string باشد ،‌ بدون نگراني مي توان از روش output caching استفاده كرد .
در صورتي كه خروجي صفحه وابسته به اطلاعات خاص و مرتبط با كاربر نظير داده session و يا كوكي باشد ، از روش output caching نمي توان استفاده نمود چراكه مكانيزمي وجود ندارد كه بر اساس آن بتوان تفاوت caching را بر اساس session و يا كوكي تشخيص داد. output caching همچنين با صفحات پويائي كه محتويات خود را در پاسخ به رويدادهاي مرتبط با كنترل ها تغيير مي دهند كار نمي كند . در چنين مواردي ، مي توان از fragment caching براي caching يك بخش خاص از صفحه و يا از data caching براي caching اطلاعات خاص استفاده كرد.
caching با پارامترهائي خاص
بندرت مقدار VaryByParam معادل “*” در نظر گرفته مي شود و در اكثر موارد بهتر است كه يك متغير query string مهم را با نام مشخص كرد . كد زير نحوه انجام اين كار را نشان مي دهد.
%@ OutputCache Duration=”20″ VaryByParam=”ProductID” %
در چنين مواردي ، ASP.NET مقدار query string را بررسي و به دنبال پارامتر ProductID مي گردد . درخواست هائي با پارامترهاي مختلف ProductID بطور جداگانه cache و از ساير پارامترها صرفنظر خواهد شد .
در صورت لزوم مي توان چندين پارامتر را كه توسط semicolon از يكديگر جدا شده اند به خصلت VaryByParam نسبت داد . كد زير نحوه انجام اين كار ر

دیدگاهتان را بنویسید