نه داداش من گفتم اصول کلی کش ها. منظورم یه برنامه خاص نبوده.اگر دقت کرده باشین اینجا بیشتر دوستان در مورد نحوه تنظیم و رفع مشکل کش ها صحبت میکردند من یه انجور مطلبی میخواستم :
1-مقدمه:
Cache بخشي از فضاي يك سخت ديسك است كه نقش يك بافر با ويژگيهاي خاص را ايفا مي كند و محتويات آن مرتب در حال تغيير است. Caching اطلاعات واژه اي است كه امروزه به صورتي بسيار گسترده براي توصيف راه حلهايي كه بر اساس مفهوم Cache ارائه مي شوند، استفاده مي شود. اين راه حلها در مجموع افزايش كارآيي (Performance) و قابليت توسعه پذيري (Scalability) وب سايتهاي اينترنتي را درپي دارند.
دو دليل عمده براي استفاده از Web Cache ها در اينترنت وجود دارد:
كاهش تاخير : اين كاهش تاخير از آنجا ناشي ميشود كه cache ها به Client نزديكترند و لذا وقتي كه درخواستي براي يك فايل HTML توسط Cache پاسخ داده ميشود، زمان كمتري براي دريافت پاسخ توسط Client مصرف ميشود (نسبت به حالتي كه اين درخواست توسط Server پاسخ داده ميشود).
كاهش ترافيك: در اين مورد نيز با توجه به اينكه هر درخواست براي يك Object تنها يك بار توسط Server پاسخ داده ميشود، لذا استفاده از پهناي باند كمتر توسط Client را در پي دارد.
اين دو پارامتر در مجموع كارآيي بيشتر و بهتر يك Web site ودر نتيجه تحمل پذيري وب سايتها توسط كاربران و بازديدكنندگان را در پي دارند. (اصطلاح تحمل پذيري شايد واژه اي مناسب براي توصيف user experience باشد).
دلايل مختلفي ممكن است سبب گردند تا يك سايت براي بازديدكنندگان قابل تحمل نباشد.برخي از اين دلايل عبارتند از:
افزايش مدت زمان لازم براي پاسخدهي به درخواستها به علت افزايش تعداد درخواستهاي رسيده به HTTP Server در واحد زمان
افزايش مدت زمان لازم براي پاسخدهي به درخواستها به علت افزايش درخواستهاي روي بانكهاي اطلاعاتي
سرعت پايين خطوط مخابراتي
خطاهاي ناخواسته موجود در سايتها به دليل استفاده از نرم افزارها يا سرويسهاي جديد
بروز رخدادهاي ناخواسته نظير Hack شدن سايتها
و ...
شكل1: چرخه حيات سايتهاي اينترنتي
شكل1: چرخه حيات سايتهاي اينترنتي
شكل1: چرخه حيات سايتهاي اينترنتي
شكل1: چرخه حيات سايتهاي اينترنتي
به همين دليل فرآيند توسعه و رشد يك سايت فرآيندي گام به گام و داراي يك چرخه تكاملي است كه با طي كردن آن مي توان به داشتن يك سايت موفق در اينترنت اميدوار بود. در شكل 1 جايگاه Cache و Caching اطلاعات را در اين فرآيند مي توانيد مشاهده كنيد
راه حلهايي كه در حيطه Caching اطلاعات در وب ارائه مي شوند را مي توان به سه گروه دسته بندي كرد: Proxy Caching , Server-side Caching , Client-side Caching. نوع اطلاعاتي كه د ر web cacheها بايد ذخيره شوند، نخستين و مهمترين عامل براي تعيين نوع Caching انتخابي براي يك Web site هستند. در حاليكه امروزه Proxy Cacheها يك تكنيك متعارف و پر استفاده در اين حيطه محسوب مي شوند، Server-side Cachingها نيز به عنوان يك شيوه Caching پوياي اطلاعات با اقبال عمومي تكنيسين ها و طراحان سايتها روبرو مي شوند و بر محبوبيت آنها افزوده مي شود.
اما عليرغم مزاياي فوق مساله وجود Cache در اينترنت مشكلاتي را سبب شده است كه بيشتر ناشي از فهم نادرست عملكرد آنها و قدرت مديران سايتها در كنترل آنها ست. نگراني‌هايي در ارتباط با وجود Cache در ميانه راه ميان Client و Server وجود دارد:
نخست:نگراني مديران سايت ها در از دست دادن كنترل سايتها
مساله دوم: مساله به روز بودن Object هاي درخواستي از جانب Client
براي بررسي بيشتر مساله بايد جوانب مختلف مساله Caching اطلاعات را مورد بررسي قرار دهيم. نوع محتويات وب، انواع Cacheها، تدابير انديشيده شده براي مساله Caching در پروتكلها و نحوه كار آنها، تكنولوژيهاي مختلف مورد استفاده در طراحي سايتهاي با محتواي پويا و ابزارهاي موجود در آنها براي استفاده و كنترل قدرت Cacheها ، معرفي برخي ابزارهاي مورد استفاده براي تحليل سايتها از نظر ميزان Cacheپذيري و ...مسائلي هستند كه در ادامه اين مقاله به بررسي آنها خواهيم پرداخت.
انواع Web siteها از نظر محتوا:
2-انواع Web Cacheها: <LI>Browser Caches:مرورگرهاي مدرن امروزي بخش هايي براي تنظيمات مربوط به Cache دارند. اين تنظيمات به مرورگر اجازه مي دهند که بخشي از فضاي سخت ديسک کامپيوتر را براي نگهداري Object ها و اشيا دريافت شده (و مشاهده شده توسط کاربر) مورد استفاده قرار دهد. اين نوع از Cache به خصوص براي مواردي مفيد است که استفاده کننده از سيستم از کليد Back براي مشاهده صفحاتي که قبلا ديده است استفاده مي کند.
Clearing the Cache
In Internet Explorer 6.0:
- Choose Internet Options from the Tools menu.
- On the General tab, choose Delete Files.
- Select Delete all offline content.
- Click OK.
In Netscape Communicator 6.2:
Choose Preferences from the Edit menu.
Under the list marked Category, click on the Advanced option.
Click on the option marked Cache.
Select Clear Memory Cache and Clear Disk Cache.
Under the section marked "Document Cache is compared to the document on the network:" choose Every Time.
Click OK.
Turning Off Caching
In Internet Explorer 6.0:
Choose Internet Options from the Tools menu.
On the General tab, choose Settings in the area marked Temporary Internet Files.
Under the option "Check for newer versions of stored pages:" choose the "Every visit to the page" option.
Click OK.
In Netscape Communicator 6.2:
Choose Preferences from the Edit menu.
Under the list marked Category, click on the Advanced option.
Click on the option marked Cache.
Under the section marked "Document Cache is compared to the document on the network:" choose Every Time.
Click OK.
شكل///عملكرد web browser cacheها
Proxy Caches
Web Proxy Cacheها نيز با همان مجموعه قواعد فعاليت مي كنند، منتها در يك مقياس وسيعتر. پروكسي ها به صورت همزمان صدها يا هزاران كاربران را سرويس مي دهند
نظر به اينكه Proxy Cacheها تعداد زيادي كاربر را در پشت سر خود دارند، لذا تاثير استفاده از آنها در كاهش تاخير و ترافيك بسيار مشهود است. دليل اين امر نيز بسيار ساده است. اشيايي كه يك بار و توسط يك كاربر درخواست شده اند مي توانند در پاسخ به درخواستهاي تعداد زيادي از كاربران كه درخواستي براي آن شيء دارند مورد استفاده قرار گيرند.
اكثر Proxy Cacheها توسط شركتها يا ISPهاي بزرگ مورد استفاده قرار مي گيرند تا پهناي باند اينترنت مورد استفاده توسط خودشان را كاهش دهند. استفاده اشتراكي از Proxy Cacheها باعث بالا رفتن نسبت Hit در Cacheها مي شود كه اين نيز به نوبه خود كارآيي بيشتر و بهتر اين سيستم ها را در مقايسه با Browser Cacheها در پي دارد
3-مشکلات Web Cacheها :
اصولا مساله Cache در اينترنت و واسطه بودن آن ميان Client و Server مشکلاتي را به همراه دارد که بيشتر ناشي از فهم نادرست عملکرد Cache ها در اينترنت است. يکي از مشکلاتي که در اين ارتباط وجود دارد مساله از دست دادن کنترل سايت توسط مديران سايت ها (Web master) است. در اين مورد مديران سايتها خصوصا نگران از دست دادن کنترلشان بر سايت هستند. Cache ها مي توانند بينندگان سايت را ار ديد مدير سايت مخفي کنند.
نگراني ديگري که در اين مورد وجود دارد مساله به روز بودن (Uptodate) اشياء درخواستي توسط مرورگر يا کاربر است. Cache ها مي توانند محتوياتي را در پاسخ به يک درخواست مرورگر ارسال کنند که ديگر اعتبار ندارند و از رده خارج شده اند.
با توجه به آنچه که گفتيم متوجه شده ايد که Cache ها از يک سو باعث تسريع در زمان بارگذاري سايتها و در نتيجه سرعت بيشتر سايتها مي شوند. اين مساله مطلوب کاربران است و محبوبيت سايت را نيز در پي دارد (حداقل) و نيز باعث مصرف پهناي باند کمتري از Server مي شود. اما به نظر مي رسد وجود Cache ها مشکلاتي را در زمينه حفظ جامعيت و به روز بودن اطلاعات سايت سبب مي گردد. همچنين باعث بروز اختلالات در مديريت سايتها مي گردد. بنابر اين وجود Cache در اينترنت نوعي تناقض را به همراه دارد.
براي استفاده بهتر از ويژگيهاي Cache که به نوعي محبوبيت يک سايت را نيز به دنبال دارند (اقلا از ديد سرعت در بارگذاري سايتها) بايد با نحوه کار Cache ها از نزديک آشنا شويم تا بتوانيم استفاده بهتري از ويژگيهاي Cache ها ببريم.
هدرهاي HTTP:
هدرهای Http اطلاعاتی هستند كه در پی درخواست يك صفحه وب، از سرويس گيرنده به سرويس دهنده و برعكس فرستاده می شود. به عبارت ديگر وقتی شما يك URL را درخواست می كنيد سرويس گيرنده شما به جز آدرس اينترنتی يك سری اطلاعات ديگر را كه شامل نوع مرورگر، IP ، نوع سيستم عامل و ... ميباشد را به سرويس دهنده ارسال می كند. همچنين وقتی سرويس دهنده درخواست شما را پس می فرستد يك مجموعه از اطلاعات مربوط به سرويس دهنده شامل مسير فيزيكی صفحه درخواست شده، نام نرم افزار سرويس دهنده وب، QueryString، و ...نيز همراه آن ارسال می كند كه به آنها متغيرهای محيطی يا Enviromnental Variables می گويند.
نمونه اي از يك درخواست در قالب پروتكل HTTP را در زير مشاهده مي كنيد:
نمونه اي از سرآيند پاسخ ارسال شده از Server در قالب پرونكل استاندارد HTTP را در زير مشاهده مي كنيد: HTTP/1.1 200 OK Date: Fri, 30 Oct 1998 13:19:41 GMT Server: Apache/1.3.3 (Unix) Cache-Control: max-age=3600, must-revalidate Expires: Fri, 30 Oct 1998 14:19:41 GMT Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT ETag: "3e86-410-3596fbbc" Content-Length: 1040 Content-Type: text/html
HTTP_USER_AGENT: نوع مرورگر و نوع سيستم عامل سرويس گيرنده
REMOTE_ADDR: IP كاربری كه صفحه را درخواست كرده است
HTTP_REFERER: URL صفحه ای كه از آنجا به صفحه شما Link شده است
SERVER_NAME: DOMAIN NAME سايتی كه صفحه شما در آن قرار دارد.
HTTP_HOST: نام كامل ميزبان وب
HTTP_COOKIE: كوكی هايی كه به مرورگر ارسال ميشود
HTTP_ACCEPT_LANGUAGE: زبانهايی كه مرورگر پشتيبانی ميكند
URL: URL صفحه مابين DOMAIN NAME و QueryString
PATH_PHYSICAL_PATH: آدرس فيزيكی دايركتوری ريشه WEB
PATH_TRANSLATED: مسير فيزيكی صفحه ASP شما
QUERY_STRING: دقيقا QueryString را بر می گرداند.
SERVER_SOFTWARE: نرم افزار سرويس دهنده وب مثل Microsoft-IIS/4.0
در زبان ASP به كمك كد زير مي توانيد ليست كاملي از HTTP Headerها و متغيرهاي محيطي را مشاهده كنيد. <%
Dim strName
For Each
strName in Request.ServerVariables
Response.Write "<Font Color=blue><B>" & strName & ": " & "</B></Font>" & _
Request.ServerVariables (strName)& "<BR>"
Next
%>
اما در زبان PHP اين كار با تابع phpinfo() صورت مي گيرد. به كمك اين دستور ليستي از متغيرهاي محيطي مورد استفاده در زبان PHP را مشاهده مي كنيد.
براي استفاده از مقادير اين متغيرها در برنامه هاي به زبان PHPبايد از آرايه هايي كه براي اين منظور تدارك ديده شده است استفاده كرد (گرچه به صورت Global و تنها با نام نيز قابل دستيابي هستند). مثلا براي اطلاع از نوع مرورگر درخواست كننده اطلاعات مي توان از متغير "$HTTP_USER_AGENT" استفاده كرد و نوع مرورگر را تشخيص داد.
در زبان PHP به كمك كد زير مي توانيد ليست كاملي از HTTP Headerها را مشاهده كنيد $headers = getallheaders();while (list ($header, $value) = each ($headers)) { echo "$header: $value<br>\n";}
پرونكل HTTP و مكانيسم هاي كنترل رفنار و عملكرد Cacheها:
Validation Model
هنگاميكه Cache يك مدخل فاسد داشته باشد، در پاسخگويي به درخواستهاي ارسالي از جانب Client ها براي آن شيء، نخستين كاري كه بايد انجام دهد مطابقت دادن نسخه موجود در Cache (نسخه Stale) با نسخه اصلي موجود در Server است. (و يا با نسخه اي معتبر در يكي از Cacheهاي مياني)، تا ببيند كه آيا نسخه موجود در Cache هنوز قايليت استفاده دارد يا خير؟ اين عمليات را عمليات معتبرسازي (Validating) مدخل موجود در Cache مي نامند و يكي از مكانيسم هاي اصلي مورد استفاده توسط Cache براي بهبود بخشيدن به عملكرد سايتهاست.
توجه داريم كه به صورت بالقوه دونوع هزينه و سربار در اين فرآيند مي تواند نهفته باشد. نخست سربار مربوط به ارسال پاسخ كامل از سوي Server در حالتيست كه نسخه موجود در Cache هنوز قابل استفاده است و ديگري هزينه رفت و برگشتهاي اضافي در حالتيست كه نسخه موجود در Cache فاقد اعتبار لازم است. براي جلوگيري از پرداخت اين هزينه ها پروتكل HTTP1.1 از يك مكانيسم شرطي براي اين مورد سود جسته است. در حقيقت با استفاده از مكانيسم اعتبارسنجي مي توان پهناي باند مورد استفاده را كاهش داد.
ويژگي كليدي استفاده شده در اين پروتكل استفاده از مفهوم Cache Validator است. هنگاميكه Server اصلي يك پاسخ كامل در جواب يك درخواست توليد و ارسال مي كند، گونه هاي مختلفي از Validator ها نيز به همراه آن ارسال مي گردند كه به همراه شيء درخواستي در Cache ذخيره مي شوند. هرگاه Client (اعم از web browser يا proxy cache) درخواست شرطي براي منبعي داشته باشد كه مدخل ناظر در Cache نيز دارد، Validatorهايي به نيز به همراه اين درخواست ارسال مي كند. server اصلي در ابتدا Validatorها ي ارسالي را با Validatorهاي منبع مورد درخواست مقايسه مي كند. اگر اين Validatorها با يكديگر منطبق باشند، در پاسخ تنها يك سرآيند (بدون هيچ بدنه اي) ارسال مي كند. اين سرآيند معمولا حاوي يك كد وضعيت (Status Code) ويژه است (معمولا كد 304, Not modified). اما اگر Validatorها بر يكديگر منطبق نباشند، Server در پاسخ به درخواست Client پاسخ كامل (حاوي سرآيند و بدنه) ارسال مي كند.
با اعمال اين مكانيسم از ارسال پاسخ كامل توسط Server اصلي در حالتي كه نسخه موجود در Cache هنوز معتبر است (Validatorها با يكديگر برابرند) ، و نيز از رفت و برگشتهاي اضافي در حالتيكه Validatorها بر يكديگر منطبق نيستند جلوگيري شده است
تنها تفاوت ميان پروتكل اخير در قسمت سرآيند درخواستها است. در پروتكل HTTP1.1 در قسمت Header درخواستها برخي پارامترهاي اضافي نيز تدارك ديده شده است (كه همان Validatorها هستند). نكته ديگري كه بايد به آن توجه داشت اين است كه الزامي در استفاده از Validatorها توسط Server وجود ندارد. در اين حالت اشياء ارسال در Cache ذخيره مي شوند و تا زماني كه تاريخ انقضاء آنها فرا نرسيده است در Cache معتبر هستند. مگر اينكه توسط دايركتيوها نظير Cache-control از cacheشدن آنها جلوگيري شود.
انواع Validator ها :
1- Last-Modified Date (تاريخ آخرين اصلاح):
معمولا به عنوان Cache-Validator استفاده مي شود. يك مدخل موجود در Cache معتبر است اگر از تاريخ آخرين اصلاح آن تاكنون اصلاحي بر روي آن در Server صورت نگرفته باشد.
2-Entity Tag:
ETagها براي مواردي به كار مي روند كه استفاده از Validatorهاي زماني ممكن نباشد. اصولا در سيستم هاي توزيع شده بهره گيري از مفهوم زمان مي تواند به صورت بالقوه تناقض و ناهمگوني را در سيستم ها در پي داشته باشد. لذا استفاده از اين نوع Validatorها، قابليت اعتماد و اطمينان بالاتري را نسبت به Validatorهاي زماني در پي خواهد داشت.
3- Validatorهاي قوي و ضعيف:
ديديم كه در شيوه اعتبارسنجي (Validating) Server اصلي و Cache اطلاعات مربوط به Validatorهاي خود را با يكديگر مقايسه مي كنند تا مشخص كنند كه آيا هردوي آنها يك چيز واحد را مشخص مي كنند يا اشياء و منابع اطلاعاتي متفاوتي را نشان مي دهند. به صورت عادي انتظار مي رود كه هرگونه تغيير در شيء متناظر با Validator موجب تغيير در Validatorناظر به آن گردد. در صورت برقراري چنين حالتي Validator را قوي (Strong Validator) مي نامند
اما ممكن است حالتي وجود داشته باشد كه Server اصلي تمايل دارد تغييرات معنايي در Validator ايجاد كند و يا تغييرات ناچيزي در شيء متناظر با Validator ايجاد كند اما اين تغييرات در Validator نمودي نداشته باشد. اين نوع Validator را ضعيف (weak) مي نامند
3-1 cache ها چگونه کار مي کنند؟
سئوال اساسي که در اينجا مطرح مي شود اين است که Cacheها چگونه کار مي کنند؟ در پاسخ به اين سئوال بايد گفت تمام Cacheها از يک مجموعه قواعد مشخص براي پاسخدهي به درخواستهايي که محتويات آنها در Cache موجود است استفاده مي کند. برخي از اين قواعد توسط پروتکلها تعيين مي شوند (HTTP 1.0 and HTTP 1.1) و برخي ديگر از اين قواعد و قوانين توسط مديران سيستم cache تعيين مي شوند (اعم از Proxy administrator ها و يا کاربر در سيستم browser cache).
به بيان ديگر در پاسخ به يک درخواست سلسله مراتبي به شرح زير رعايت مي شود:
- اگر سرآيندهايي که به همراه شيء درخواستي ارسال شده اند خواهان اين باشند که شيء موردنظر در Cache ذخيره نشود cache ها آن شيء را ذخيره نمي کنند. اکثر cacheها اشياء فاقد validator را به عنوان شيء غير قابل ذخيره در Cache مي شناشند و از ذخيره شدن آن اشياء در Cache ها ممانعت مي کنند.
- اگر اشياء مورد درخواست امنيتي (Secure) و يا نيازمند به اخذ مجوز باشند (Authenticated) در Cache ذخيره نمي شوند
- يک شيء موجود در Cache " تازه" محسوب مي شود (يعني چنانچه درخواستي براي آن شيء موجود باشد و شيء مورد نظر در Cache موجود باشد بدون تطبيق آن شيء با شيء اصلي موجود در Server آن شيء در پاسخ به درخواست موردنظر ارسال مي شود) اگر:
- شيء موجود در Cache زمان انقضاء (expiry time) داشته باشد و هنوز موعد آن فرا نرسيده باشد (شيء مورد درخواست فاسد نشده باشد)
- شيء موجود در Cache داراي کنترلهاي سني (age-controlling directives) باشد و اين کنترلها هنوز معتبر باشند
- اگر شيء مورد درخواست در Cache فاقد اعتبار باشد (Stale شده باشد) در اين صورت عمليات معتبرسازي براي شيء درخواست شده انجام مي گيرد. به اين صورت كه پارامترهاي اعتباري شيء مورد درخواست با مجموعه پارامترهاي اعتباري شيء اصلي موجود در Server مطابقت داده شده و بر اساس نتيجه اين عمليات نسخه موجود در Cache معتبر تشخيص داده مي شود و يا اينكه درصورت نامعتبر بودن نسخه اي معتبر از آن براي درخواست كننده ارسال مي گردد.
شکل 2: سلسله مراتب و عملکرد Cache ها در اينترنت
در مجموع دو عمليات تازه سازي (freshness) و معتبرسازي (validation) دو روش عمده اي هستند که Cache ها در برخورد باContent ها از آنها استفاده مي کنند.معتبرسازي كاهش پهناي باند مورد استفاده توسط شبكه را درپي دارد و تازه سازي باعث كاهش ترافيك شبكه مي شود. تازه سازي نياز به ارسال درخواست را در بسياري از موارد از بين مي برد و معتبر سازي نياز به ارسال كامل پاسخ از جانب Server را منتفي مي سازد.
3-2 توصيه هايي براي طراحان سايتها: اعمال توصيه هاي زير مي تواند به ساخت سايتهايي که از قدرت Cache ها در رسيدن به محبوبيت بيشتر استفاده مي کنند کمک کند:
<LI>قانون طلايي Caching: ارجاع يکنواخت به اشياء(refer to objects consistently): اگر محتويات يکساني را در صفحات مختلف به کار مي بريد (براي کاربران مختلف يا از سايتهاي مختلف) سعي کنيد URL هاي يکساني را براي آنها به کار ببريد. اين روش ساده ترين و مئثرترين راه براي ساخت سايتهايي است که قابليت بهره برداري از قدرت Cache ها را دارند. براي فهم بيشتر اين موضوع مثال زير را در نظر بگيريد: فرض کنيد در طراحي يک سايت پوشه articles در ريشه وجود دارد. حال فرض کنيد در اين پوشه دو فايل HTML با نامهاي f1.htm و f2.htm وجود دارند. نيز فرض کنيد که در صفحه f1.htm ارجاعي به صفحه f2.htm وجود دارد. اين ارجاع را مي توان به يکي از دو صورت زير انجام داد:
<a href="f1.htm">f1 page refrences 1 </a> <a href="../articles/f1.htm">f1 page refrences 2 </a>
هر دو دستور فوق به يک معنا بوده و براي يک ارجاع به کار مي روند. اگر قرار است از شيوه اول استفاده کنيد در کل صفحه به همان روش عمل کنيد و اگر قرار بر استفاده از شيوه دوم است نيز در کليه ارجاعات موجود در آن صفحه و آن شاخه به همان شيوه عمل نماييد.
استفاده از کتابخانه مشترک از اشياء و تصاوير مورد استفاده در سايت:
سعي کنيد که تمامي اشياء و تصاوير مورد ارجاع در صفحات مختلف را در يک مکان واحد ذخيره کنيد و پيوندهاي مختلف از صفحات را به آن منبع واحد ارجاع دهيد
صفحاتي را که تغييرات زيادي ندارند با تعيين زمان انقضاء طولاني (long expiry time)در بخش سرآيند صفحات آنها در Cache ذخيره کنيد.
اگر يک منبع ( و خصوصا فايلهاي قابل پايين گذاري) تغيير کرد آن را تغيير نام دهيد
از ايجاد تغييرات بي مورد در فايلها خودداري کنيد. براي مثال اگر سايتتان را Up date کرديد کل سايت را مجددا کپي نکنيد تنها فايلهايي را منتقل کنيد که دچار تغيير شده اند. (اين مساله در ارتباط با بخش Last-Modified پاسخ هاي Server است)
از cookieها در مواقع لزوم استفاده کنيد. با توجه به اينکه Cookieها با Cache مشکل دارند و در بسياري از موارد نيازي به استفاده از آنها نيست لذا توصيه مي شود که تا سرحد امکان از آنها کمتر استفاده کنيد و استفاده از آنها را به صفحات ديناميک محدود کنيد.
استفاده از SSL ها را کم کنيد. دليل اين مساله نيز آن است که صفحات رمزگذاري شده در Shared Cache ها استفاده نمي شوند. لذا تنها مواقعي که به آنها نياز داريد از آنها استفاده کنيد.
3-3 زبانهاي مورد استفاده در طراحي و مساله Cache:
تكنولوژي PHP
PHP مخفف Hypertext Preprocessor يك زبان Scripting و Server-Side مي باشد. يك Script به كدي از برنامه ميگويند كه بصورت ابتدايي Compile نميشود و فقط در صورت فراخواني و يا درخواستي براي اجرا توسط مفسّر زبان مورد نظر ترجمه مي شود و به خروجي فرستاده مي شود. اين به اين معني ميباشد كه شما دقيقاً كد برنامه خود را در جاي مورد نياز به كار ميبريد و رابط اجرايي برنامه آنرا به مفسّر مورد نظر ارجاع ميدهد.
بعد از نصب مفسّر PHP شما قادر خواهيد بود كه از كدهاي PHP به همراه كدهاي HTML خود در صفحات Web استفاده كنيد و همچنين ميتوانيد Script هاي صرفاً PHP خود را به عنوان ترمينالهاي تفسير كننده داده ها و رابطهاي ورودي و خروجي بر روي سرور خود قرار دهيد.
فكر اوليهPHP در پاييز سال 1994 توسط Rasmus Lerdorf (rasmus@php.net)شكل گرفت .در ابتدا نگارشي از PHP در صفحه شخصي وي به كار گرفته شد ، تا اطلاعاتي از كساني كه رزومه وي را مي بينند ، نگاه داشته شود. اولين نگارش عمومي آن در اوايل سال 95 ارايه شد و با نام ” Personal Home Page Tools “ معرفي گرديد . كه البته شامل پارسري بسيار ساده بود كه ماكروهاي خاصي را مي شناخت و نيز برخي كاربردهاي مشترك در صفحات شخصـي مانند شمـارنده يا Guestbook وبرخـي ابزار هاي ديگر را شامل مي شد.
پارســر در نيمه سال 95 بازنويســي شد و با نام “ PHP/FI نگارش 2 “ ارايه گرديد . FI نام بسـته نرم افزاري ديگري از Rasmus بود كه فرم هاي داده HTML را تفسير مي كرد . پس از آن بسياري از PHP در كــد هاي خود استفاده كردند . در ميانه سال 96 ميزان استــفاده كنندگان به حـــدود 15 هـزار سايت رسيد . اين ميــزان در نيمه سال 97 در حدود 50 هزار سايت مختلف بود. در هـمين زمان PHP از حالت يك پروژه شخصي درآمد و توســط تيمي توسـعه يافت . اين گروه نگارش جديدي از PHP را ارايه دادند و پارسر آن را بازنويسي نمودند. PHP3 به سرعت مورد استفاده قرار گرفـت . هم اكنـون نيز PHP4 آخرين نگارش اين محصول است كه در آن از موتور اسكريپت Zend براي بدست آوردن قابليت هاي بيشتر استفاده شده است .
امروزه ، PHP3 و PHP4 بر روي بسياري از محصولات تجاري مانند “RedHat’s Stronghold web Server” ارايه مي گردد. هم اكنون برآورد مي شود بيش 5.100.000 سايت از PHPدر طراحي استفاده كرده اند.
دلايل زيادي در محبوبيت و استفاده از اين زبان در حال حاضر وجو دارد برخي از اين دلايل عبارتند از:
سرعت: در مقايسه با تكنولوژي نظير ASP به دليل عدم استفاده PHP از Engine هاي مختلف و متفاوت كدهاي PHP از سرعت بالايي برخوردارند.
نزدیك بودن Syntax به ++C/C و Java:از آنجايیكه اكثر برنامه نویسان از ++C/C استفاده كرده اند و بخاطر محبوب بودن بی حد Java معمولا با Syntax های این دو زبان اكثرا آشنا هستند . PHP هم اكثر Syntax های خود را شبیه به این زبانها انتخاب كرده است
OpenSource بودن PHP
اجرا بر روی Platform های مختلف: به دلیل آنكه توسط GNU C Compiler در همه Platform ها قابل Compile شدن است و از Engine های خاص هیچ سیستم عاملی برای اجرای كدها استفاده نمی كند قابلیت اجرا بر روی تعداد زیادی از سيستم عامل ها را داراست كه این یك مزیت برای توسعه دهندگان سيستم محسوب می شود .
به صورت پيش فرض اشيائي كه توسط PHP مورد پردازش قرار مي گيرند، فاقد Validator هستندو لذا غير قابل Cache شدن. برنامه سازان سيستم هاي تحت وب مي توانند با تنظيم كردن سرآيندهاي HTTP مساله قابل Cache بودن اشيا را در اين زبان تحت كنترل درآورند. اين كار توسط تابع Header() در زبان PHP صورت مي گيرد. تنها نكته اي كه بايد در اين مورد همواره به خاطر داشت اين است كه Headerها همواره بايد قبل از هر خروجي ديگري آماده و ارسال شوند.
براي مثال مجموعه دستورات زير Expires header صفحه ارسالي به سمت سرويس گيرنده را براي سه روز آينده تنظيم مي كند. <?php Header("Cache-Control: must-revalidate"); $offset = 60 * 60 * 24 * 3; $ExpireString = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT"; Header($ExpireString);?>
همچنانكه مشاهده مي كنيد تنظيم اين سرآيندها مستلزم شناخت سرآيندهاي ارسالي از جانب سرويس دهنده در پاسخ به درخواست مرورگر است. علاوه بر آن برنامه نويس بايد از قالب اين تنظيمات نيز آگاهي داشته باشد تا بتواند تنظيمات را به درستي انجام دهد.
به كمك تابع phpinfo() مي توانيد متغيرهاي محيطي مورد استفاده توسط مفسر PHP را مشاهده كنيد.
Cache_Limiter:
cache_limiter اطلاعات مورد نياز براي نحوه Caching داده هاي درخواستي توسط Client را در سرآيندهاي HTTP تنظيم مي كند. مقادير قابل تنظيم آن نيز عبارتند از:
nocache: از cache شدن اطلاعات در سمت Client ممانعت مي كند
Public:اجازه Cache شدن اطلاعات در سمت Client را مي دهد.
Private: شبيه به Public است منتها كمي محدودتر عمل مي كند.
مقدار اين تنظيم در حالت عادي توسط session.cache_limiter تعيين مي شود. براي هر درخواست ارسالي بايد session_cache_limiter() فراخواني شود (قبل از session_start)
تكنولوژي ASP:
ASPكلاسيك نيز قابليت تنظيم سرآيندهاي HTTP را براي تنظيم نحوه Cache شدن صفحات داراست. به عنوان مثال براي تنظيم زمان فساد (Expiry) صفحات، مي توان از خاصيت Expires شيء Response در صفحات ASP استفاده كرد. <% Response.Expires=1440 %>
اين دستور مدت زمان اعتبار شيء مورد نظر را به صورت نسبي و بر حسب دقيقه بيان مي كند. (به اين معني كه از زمان درخواست اين صفحه و ذخيره شدن آن در Cache به مدت 1440 دقيقه يا 24 ساعت اين صفحه معتبر بوده و هر درخواست ديگري كه ناظر به اين صفحه باشد از ناحيه Cache پاسخ داده مي شود و نه از ناحيه Server). اين زمان را به صورت مطلق نيز مي توان بيان كرد و نمونه اي از آن را در قسمت بعد مشاهده مي كنيد
<% Response.ExpiresAbsolute=#May 31,1996 13:30:15 GMT# %>
همچنين سرآيندهاي Cache-Control نيز مي توانند به صفحات وب افزوده شوند. <% Response.CacheControl="public" %>
در اينجا نيز بايد توجه داشت كه قبل از توليد خروجي HTML كار تنظيم سرآيندهاي HTTP را به كمك فراخواني رويدادهاي Response انجام داده باشيد و يا از Response.Buffer براي بافر كردن خروجي استفاده كنيد. به عنوان يك قاعده كلي سرآيندهاي HTTP همواره بايد قبل از خروجي هاي HTML ارسال شوند. نكته ديگري كه بايد به آن توجه داشته باشيد اين است كه ASP ها مقدار Cache-Control را به صورت پيش فرض private فرض مي كنند. براي اينكه اين صفحات توسط Shared Cache هاي تحت پروتكل HTTP1.1 قابل Cache شدن باشند بايد حتما اين مقدار به Public تغيير يابد.
تكنولوژي .NET : در مقايسه با تكنولوژي هاي Server-side اي كه تاكنون مورد بررسي قرار گرفتند به نظر مي رسد تكنولوژي.NET از قدرت بيشتري براي بهره برداري از توان Cacheها برخوردار است. .NET اين ويژگي را دارد كه تمام صفحه، بخش خاصي از آن يا تنها داده هاي صفحه را ذخيره كند. اين سه بخش را .NET به ترتيب با Output Cachingو Fragment Caching و Data Caching مي شناسد.
<LI>صفحاتی که از Output Caching استفاده می کنند برای بار اول اجرا می شوند و سپس حاصل آن cache می گردد. جهت پاسخگوئی به درخواستهای بعدی برای همين صفحه، از نسخه cache شده استفاده می گردد. اين كار با استفاده از دايرکتيو OutputCache@ در ابتداي صفحات وب طراحي شده به كمك اين تكنولوژي صورت مي گيرد. و در حقيقت اين دايركتيو فعال كننده اين ويژگي براي صفحات وب است. اين نوع از Cache دقيقا مشابه همان هايي است كه در تكنولوژيهاي PHP و ASP كلاسيك مورد بررسي قرار گرفت. حتي در اين مورد شكل دستورها در ASPكلاسيك و C# نيز بسيار شبيه به يكديگر است.
<%@ OutputCache Duration = "..." VaryByParam = "..." Location = " ... " %>
و يا [C#]
Response.Cache.SetExpires(DateTime.Now.AddSeconds( 600));
Response.Cache.SetCacheability(HttpCacheability.Pu blic);
صفات OutputCaching
Duration: مدت زمان معتبر بودن cache را مشخص می کند. مقداردهی اين صفت الزامی است و مقدار آن بر اساس ثانيه است. Location: محل قرار گرفتن cache را مشخص می کند.
در حالت Server صفحه cache شده در حافظه سرور نگهداری می شود.
در حالت Downstream صفحه cache شده بر روی proxy server نگهداری می گردد.
در حالت Client صفحه cache شده بر روی مرورگر کاربر قرار می گيرد.
در حالت Any صفحه cache شده بر روی هر يک از موارد فوق می تواند قرار گيرد.
در حالت None صفحه مربوطه عملا در هيچ کجا cache نخواهد شد.
VaryByParam: نسخه های cache متفاوتی از صفحه مورد نظر براساس پارامترهای موجود در QueryString و Form يا ترکيبی از آنها ايجاد می گردد.
<%@ OutputCache Duration="10" VaryByParam="location;count" %>
VaryByHeader: نسخه های cache متفاوتی براساس مقادير مختلف پارامتر تعيين شده در HTTP header ايجاد می گردد. <%@ OutputCache Duration="60" VaryByHeader="Accept-Language" %>
VaryByCustom: اگر مقدار اين صفت کلمه خاص "Browser" باشد، cache مورد نظر براساس نوع و نسخه اصلی مرورگرايجاد خواهد شد. اگر مقدار آن يک رشته دلخواه باشد، آنگاه لازم است که شما متد HttpApplication.GetVaryByCustomString را در فايل Global.asax را بگونه دلخواه بازنويسی کنيد.
<LI>علاوه بر اينکه شما می توانيد تمام يک صفحه را cache کنيد، شما حتی می توانيد بخشی از يک صفحه را cache کنيد. به اين عمل Fragment Caching گويند.
بدين منظور لازم است که شما بخش های مورد نظر را بصورت User Control يا کنترل کاربری ايجاد کرده باشيد.تعيين محل ذخيره سازي اين اطلاعات توسط برنامه ساز مقدور نمي باشد و محل ذخيره سازي بر روي سرور در نظر گرفته مي شود
VaryByControl: ششمين صفت موجود در دايرکتيو Outputcache@ می باشد. تنها می توان در کنترلهای کاربری از آن استفاده کرد. استفاده از آن سبب می شود تا cacheهای متعددی براساس خواص (properties) کنترل کاربری ايجاد گردد. [*.ascx]<%@ Language="C#" %><%@ OutputCache Duration="10" VaryByControl="State;Country" VaryByParam="*"%><script runat=server>public String State {get { return state.Value; }set { state.Value = State; } }public String Country {get { return country.Value; }set { country.Value = Country; } } </script>
<LI>با استفاده از data cache می توان داده های برنامه مانند رشته ها، DataSetها و ساير اقلام داده و آبجکت را بصورت زير cache کرد:
Cache ("counter") = mycount.text
3سپاس
LinkBack URL
About LinkBacks
