خواندن اطلاعات فایر باگ

[idocsidocs]

وقتی یه صفحه رو با فایرباگ چک می کنم، توی قسمت NET تعداد درخواستها رو نشون می ده. ور همچنی حجم صفحات گرفته شده.

من برای کم کردن تعداد درخواستها، فایلها رو کش می کنم. اما هنوز هم فایر باگ تعداد زیادی درخواست رو نمایش می ده.

در بخش حجم فایلهای دریافت شده، عبارت زیر وجود داره. یعنی 14 درخواست از سرور انجام شده، 452 کیلوبایت حجم کل فایلها هستن و 447 کیلوبایت از فایلها توسط حافظه کش بدست اومدن.
14 requests 454.2 KB (447.1 KB from cache)

با توجه به اینکه تقریبا تمام فایلها از کش بدست اومدن، چرا تعداد 14 درخواست از سرور شده؟

[Keramatifar]

کانکشن ها و کوئری هایی که به دیتابیس میزنی رو چک کردی؟

[idocsidocs]

کانکشن ها و کوئری هایی که به دیتابیس میزنی رو چک کردی؟

در این مورد باید بگم که اتصالات بدون مشکل ایجاد می شن و اطلاعات از دیتابیس گرفته می شن. من هیچ فایلی رو از دیتابیس نمی گیرم که بخاطر اونها درخواست http ارسال بشه.

اتصالات به دیتابیس و کوئری گیری چه تاثیری روی کش کردن فایلها دارن؟ لطفا توضیح بدید.

[idocsidocs]

کسی در این مورد نظری نداره؟

[eshpilen]

با توجه به اینکه تقریبا تمام فایلها از کش بدست اومدن، چرا تعداد 14 درخواست از سرور شده؟ کش به این معنا نیست که هیچ درخواستی نشه. سیاست کش چند نوعه که عمدتا بستگی به هدرها داره.

یه نمونه:

مرورگر به سرور: اگر فایل main.css از تاریخ 25/2/2011 تاحالا تغییر کرده اون رو واسم ارسال کن.
سرور: نه قربان تغییری نکرده.
در اینصورت مرورگر هم که فایل رو توی کش خودش داره از نسخهء کش شده استفاده میکنه.

بجز این چند مدل دیگه هم داره!

در اینجا درخواست ارسال شده و پاسخ دریافت شده اما دیتای اصلی ارسال نشده و همچنان از کش استفاده میشه.
برای اینکه این جریان اتفاق نیفته و مرورگر بدون سوال کردن از سرور از نسخهء کش خودش استفاده کنه، باید هدرهای مناسب وجود داشته باشن و هدرهای نامناسب وجود نداشته باشن (تماما یا عمدتا منظور هدرهای پاسخ هست).
و البته کلا سیستم کش HTTP که داستان سمت سرور داره، میان راه داره (پراکسی ها و کش سرورها)، و سمت مرورگر داره، داستان و ظرافت و پیچیدگی زیاد داره و بنابراین بنده هم جزییاتش رو دقیقا یادم نیست.

در بعضی شرایط ممکنه درخواست مرورگر توسط کش سرورهای بین راه پاسخ داده بشه و بنابراین اصلا به سرور اصلی نرسه.

[idocsidocs]

کش به این معنا نیست که هیچ درخواستی نشه. سیاست کش چند نوعه که عمدتا بستگی به هدرها داره.
در بعضی شرایط ممکنه درخواست مرورگر توسط کش سرورهای بین راه پاسخ داده بشه و بنابراین اصلا به سرور اصلی نرسه.
من الان روی لوکال هاست هستم و کدهای کشی که استفاده می کنم همونها هستن که توی تاپکهای قبلی قرارشون دادم.

من وقتیکه سایت رو به مشتری تحویل دادم دیگه تغییرش نمی دم. به همین دلیل می خوام تعداد درخواستها کم بشن. چه کاری باید بکنم؟


# BEGIN Expire headers
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/javascript "access plus 216000 seconds"
ExpiresByType application/x-javascript "access plus 216000 seconds"
ExpiresByType text/html "access plus 600 seconds"
ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>
# END Expire headers

# BEGIN Cache-Control Headers
<ifModule mod_headers.c>
<filesMatch "\.(ico|jpe?g|png|gif|swf)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<filesMatch "\.(css)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<filesMatch "\.(js)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<filesMatch "\.(x?html?)$">
Header set Cache-Control "max-age=600, private, must-revalidate"
</filesMatch>
<filesMatch "\.(php)$">
Header unset Expires
Header set Cache-Control "max-age=0, private"
</filesMatch>
</ifModule>
# END Cache-Control Headers

# BEGIN Turn ETags Off
<ifModule mod_headers.c>
Header unset ETag
</ifModule>

[AMIBCT]

بخشی از این مطلبی که شما می‌فرمایید به مرورگر مربوط می‌شه

روی IE این اتفاق نمی‌افته
یعنی حتی در مورد تغییر کردن محتوا از سرور پرسش نمی‌شه

همون طور که دوستمون گفتن
فایرفاکس و کروم از سرور می‌پرسن که آیا این فایل از تاریخ مورد نظر تاحالا تغییر کرده یا نه.
سرور هم اگه تغییر کرده باشه محتوای جدید رو می‌فرسته

یه توصیه برای شما !
یه کم تمرکزتون رو روی سایت بیشتر کنید
چند وقتی هست که خیلی درگیر حاشیه‌ها شدید
تنظیمات پیش‌فرض آپاچی و مرورگر برای بهترین حالت‌ها که هم تغییرات به موقع شناسایی بشه و هم کمترین حجم در شبکه منتقل بشه هست

اون unset ETag رو هم بردارید !
جز اینکه اطلاعات مفیدی رو از مرورگر دارید می‌گیرید هیچ کار دیگه‌ای انجام نمی‌شه !

[eshpilen]

# BEGIN Expire headers
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/javascript "access plus 216000 seconds"
ExpiresByType application/x-javascript "access plus 216000 seconds"
ExpiresByType text/html "access plus 600 seconds"
ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>
# END Expire headers

# BEGIN Cache-Control Headers
<ifModule mod_headers.c>
<filesMatch "\.(ico|jpe?g|png|gif|swf)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<filesMatch "\.(css)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<filesMatch "\.(js)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<filesMatch "\.(x?html?)$">
Header set Cache-Control "max-age=600, private, must-revalidate"
</filesMatch>
<filesMatch "\.(php)$">
Header unset Expires
Header set Cache-Control "max-age=0, private"
</filesMatch>
</ifModule>
# END Cache-Control Headers

# BEGIN Turn ETags Off
<ifModule mod_headers.c>
Header unset ETag
</ifModule>


این رو هم بهش اضافه کن بعد تست کن و نتیجش رو بگو:

<ifModule mod_headers.c>
Header unset Last-Modified
</ifModule>

[eshpilen]

بخشی از این مطلبی که شما می‌فرمایید به مرورگر مربوط می‌شه

روی IE این اتفاق نمی‌افته
یعنی حتی در مورد تغییر کردن محتوا از سرور پرسش نمی‌شه

دقیقا یعنی چی؟
یعنی فقط از کش خودش استفاده میکنه یا اینکه محتوا رو مستقیما و مجددا از سرور دریافت میکنه؟
شما تست کردید؟


تنظیمات پیش‌فرض آپاچی و مرورگر برای بهترین حالت‌ها که هم تغییرات به موقع شناسایی بشه و هم کمترین حجم در شبکه منتقل بشه هست

درمورد فایلهای استاتیک میتونه اغلب یا در خیلی موارد این تنظیمات و الگوریتم پیشفرض مناسب باشه (اما بازم نه در تمام موارد)، اما برای برنامه ها و دیتای دینامیک خیلی بیشتر از فایلها و دیتای استاتیک بستگی به برنامه و شرایطش و تشخیص برنامه نویس داره.
چون یه الگوریتم و تنظیمات پیشفرض اونقدری هوشمندی و امکان اطلاع از همهء پارامترها رو نداره که بتونه بهترین تنظیمات رو برای هر موردی پیدا کنه. این تنظیمات برای هر سایت و برنامه ای بهینه نیستن.
منتها بخاطر پیچیدگی و دشواری و حساس بودن این تنظیمات، توصیه نمیشه افرادی که ناوارد هستن همینطوری سرخود اونا رو دستکاری کنن. ولی مسلم بدونید برای یک سایت حرفه ای با یه کسی که تخصص و مهارت کافی داشته باشه و سیستم رو هم خوب تست کنه و از کارکرد صحیح همه چیز مطمئن بشه، استفاده از این دستورات و تنظیم کش میتونه واقعا مفید باشه. هم از نظر راحتی و سرعت در سمت کاربران، هم از نظر مصرف پهنای باند و بار سرور و دیگر مسائل.

بهرحال بعضی موارد ساده و محدود احتمالا برای همه ممکنه پیش بیان که نیاز به تنظیم کش داشته باشن و بتونن خوب حلش کنن. بعضی وقتا نیاز داریم از کش جلوگیری کنیم، بعضی وقتا هم بعکس بهتره کش کنیم. اینا رو سرور و مرورگر بصورت خودکار انجام نمیدن و بالاخره باید با یه راهکاری خودمون اجراش کنیم.

[idocsidocs]

بخشی از این مطلبی که شما می‌فرمایید به مرورگر مربوط می‌شه

روی IE این اتفاق نمی‌افته
یعنی حتی در مورد تغییر کردن محتوا از سرور پرسش نمی‌شه

همون طور که دوستمون گفتن
فایرفاکس و کروم از سرور می‌پرسن که آیا این فایل از تاریخ مورد نظر تاحالا تغییر کرده یا نه.
سرور هم اگه تغییر کرده باشه محتوای جدید رو می‌فرسته

یه توصیه برای شما !
یه کم تمرکزتون رو روی سایت بیشتر کنید
چند وقتی هست که خیلی درگیر حاشیه‌ها شدید
تنظیمات پیش‌فرض آپاچی و مرورگر برای بهترین حالت‌ها که هم تغییرات به موقع شناسایی بشه و هم کمترین حجم در شبکه منتقل بشه هست

اون unset ETag رو هم بردارید !
جز اینکه اطلاعات مفیدی رو از مرورگر دارید می‌گیرید هیچ کار دیگه‌ای انجام نمی‌شه !
کش کردن و فشرده کردن سایت، همچنین کاهش تعداد درخواستها از سرور باعث افزایش سرعت سایت می شه. همونطور که می دونید سرعت بالای سایت یکی از خواسته های اصلی کاربرها هست.

شما روی حذف ETag تاکید زیادی می کنید، می شه بگید کار ETag ها چی هست؟

البته طبق مطلب زیر که از یکی از سایتها گرفتمش باید ETag ها حذف بشن و من هم توی کدهام ETag ها رو حذف کردم. کدی که برای حذف استفاده می کنم کد زیر هست:

<ifModule mod_headers.c>
Header unset ETag
</ifModule>
----------نقل قول مطلب گرفته شده--------------
مرورگرها از هدر ETag برای کش کردن محتوای استاتیک تا زمانی که تغییر نکرده استفاده می کنند (مشابه هدر Last-Modified). ولی ETag در صورتی که سایت بر روی بیش از یک سرور میزبانی شده باشد می تواند مشکل ساز شود. مثلا آپاچی به طور پیش فرض برای تولید ETag از «inode – حجم – زمان ویرایش» استفاده می کند و inode در مورد یک فایل روی سرورهای مختلف فرق می کند و در صورتی که مرورگر یک فایل را از یک سرور دریافت کند و در مراجعه بعدی به آن فایل برای چک کردن تغییرات از سرور دیگری استفاده کند، با توجه به اختلاف ETag ها، سرور مجددا فایل را می فرستد که باعث می شود مرورگر از کش استفاده نکند. IIS هم مشکل مشابهی دارد.
اما راهکار این است که یا کلا ETag رو حذف کنید و یا اینکه اصلاحش کنید برای مثال در آپاچی باید inode رو از ETag حذف کنید. (این کار رو با htaccess می شود انجام داد.)
------------------------
منظورتون از برداشتن ETag ها اینه که این کدهایی که در بالا قرار دادم رو از htaccess حذف کنم (اجازه بدم ETag ها برای مروگر ارسال بشن)؟

[idocsidocs]

این رو هم بهش اضافه کن بعد تست کن و نتیجش رو بگو:

<ifModule mod_headers.c>
Header unset Last-Modified
</ifModule>
استفاده کردم ولی فایده نداشت.

[eshpilen]

چند باری تست کن. کش مرورگر رو خالی کن و دوباره تست کن.
چون دیتای قبلی هنوز با دستورات قبلی داخل کش هست.
بعدش هم برای بار اول دیتا باید دریافت بشه و برای درخواست های بعدی کش میشه.

[idocsidocs]

چند باری تست کن. کش مرورگر رو خالی کن و دوباره تست کن.
چون دیتای قبلی هنوز با دستورات قبلی داخل کش هست.
بعدش هم برای بار اول دیتا باید دریافت بشه و برای درخواست های بعدی کش میشه.
توی فایرباگ، قسمت مربوط به نمایش پاسخهای مربوط به کش، کد مربوط به آخرین ویرایش وجود داره و این یعنی سرور این هدرها رو ارسال می کنه.

از طرفی مرورگر درخواستها و پاسخهای ارسالی و دریافتی از سرور رو کش نمی کنه.

به این دلیل بنظرم می رسه که نمی شه این درخواستها رو با استفاده از htaccess حذف کرد. نظر شما چیه؟

[eshpilen]

خب دیگه اینا رو باید تست کنی ببینی علتش چیه. روی لوکال تست میکنی یا روی هاست؟
شاید اختیارات لازم در فایل پیکربندی اصلی آپاچی داده نشده (allowoverride).

[idocsidocs]

خب دیگه اینا رو باید تست کنی ببینی علتش چیه. روی لوکال تست میکنی یا روی هاست؟
شاید اختیارات لازم در فایل پیکربندی اصلی آپاچی داده نشده (allowoverride).
من دارم روی لوکال تست می کنم.

بعضی از سایتها رو تست کردم و دیدم که همه به همین صورت هستن.

آخرین سوالی که دارم اینه که توی فایرباگ عبارت زیر به چه معنی هست؟
1.52s (onload: 1.64s)

البته می دونم که برای سرعت لود شدن سایت هست ولی می شه بگید که چرا دو عدد ارائه شده و عدد onload به چه معنی هست؟ این زمان برای سرعتهای مختلف (خطوط دیال آپ، ADSL و...) متفاوت هست؟

[eshpilen]

آخرین سوالی که دارم اینه که توی فایرباگ عبارت زیر به چه معنی هست؟نمیدونم.
چیز دیگه ننوشته دربارهء اینا؟

[idocsidocs]

نمیدونم.
چیز دیگه ننوشته دربارهء اینا؟
نه چیز دیگه ای ننوشته. این اعداد مربوط به زمان لود شدن سایت هستن ولی نمی دونم چرا دوتا عدد مختلف داده؟

[AMIBCT]

ETag و Last-Modified برای مدیریت Cache توسط مرورگر استفاده می‌شن

البته هر دو به صورت همزمان مورد نیاز نیستن و هر کدومشون باشه کفایت می‌کنه
به هر حال بودنش از نبودنش بهتره
اون مطلبی هم که نقل قول کرده‌بودید یه حالت خیلی خاص هست و قطعا در 99 درصد موارد صدق نمی‌کنه

یکی از دوستان گفته بودن که Last-Modified رو هم بردارید !:عصبانی++::عصبانی++::عصبانی++:
دوست گرامی! اگه این سرآمد رو برداریم، مرورگر مگه علم غیب داره که زمان تغییر فایل رو متوجه بشه و بتونه اون رو cache کنه ؟

و در مورد Cache فایل‌های پویا مثل php که به صورت پیش‌فرض سرآمدهای Cache ارسال نمی‌شن
اگه واقعا نیاز به Cache فایل‌های پویا داشته باشید
مدیریت این عملیات باید از داخل خود فایل انجام بشه و با htaccess و آپاچی راهی وجود نداره که بشه فهمید این فایل چه زمانی نیاز به Cache داره.

[AMIBCT]

ETag و Last-Modified برای مدیریت Cache توسط مرورگر استفاده می‌شن

البته هر دو به صورت همزمان مورد نیاز نیستن و هر کدومشون باشه کفایت می‌کنه
به هر حال بودنش از نبودنش بهتره
اون مطلبی هم که نقل قول کرده‌بودید یه حالت خیلی خاص هست و قطعا در 99 درصد موارد صدق نمی‌کنه

یکی از دوستان گفته بودن که Last-Modified رو هم بردارید !:عصبانی++::عصبانی++::عصبانی++:
دوست گرامی! اگه این سرآمد رو برداریم، مرورگر مگه علم غیب داره که زمان تغییر فایل رو متوجه بشه و بتونه اون رو cache کنه ؟

و در مورد Cache فایل‌های پویا مثل php که به صورت پیش‌فرض سرآمدهای Cache ارسال نمی‌شن
اگه واقعا نیاز به Cache فایل‌های پویا داشته باشید
مدیریت این عملیات باید از داخل خود فایل انجام بشه و با htaccess و آپاچی راهی وجود نداره که بشه فهمید این فایل چه زمانی نیاز به Cache داره.

[idocsidocs]

ETag و Last-Modified برای مدیریت Cache توسط مرورگر استفاده می‌شن

البته هر دو به صورت همزمان مورد نیاز نیستن و هر کدومشون باشه کفایت می‌کنه
به هر حال بودنش از نبودنش بهتره
اون مطلبی هم که نقل قول کرده‌بودید یه حالت خیلی خاص هست و قطعا در 99 درصد موارد صدق نمی‌کنه

یکی از دوستان گفته بودن که Last-Modified رو هم بردارید !:عصبانی++::عصبانی++::عصبانی++:
دوست گرامی! اگه این سرآمد رو برداریم، مرورگر مگه علم غیب داره که زمان تغییر فایل رو متوجه بشه و بتونه اون رو cache کنه ؟

و در مورد Cache فایل‌های پویا مثل php که به صورت پیش‌فرض سرآمدهای Cache ارسال نمی‌شن
اگه واقعا نیاز به Cache فایل‌های پویا داشته باشید
مدیریت این عملیات باید از داخل خود فایل انجام بشه و با htaccess و آپاچی راهی وجود نداره که بشه فهمید این فایل چه زمانی نیاز به Cache داره.
من تصمیم دارم که فقط از Last-Modified استفاده کنم و ETag رو حذف کنم.
اما اگر زمان Last-Modified بشه،مرورگر باید فایل رو کش کنه وهمیشه از کش بخونه. چرا می گید که اگر Last-Modified حذف بشه، مرورگر نمی تونه فایل رو کش کنه؟

[eshpilen]

اون مطلبی هم که نقل قول کرده‌بودید یه حالت خیلی خاص هست و قطعا در 99 درصد موارد صدق نمی‌کنه
کدوم مطلب؟


دوست گرامی! اگه این سرآمد رو برداریم، مرورگر مگه علم غیب داره که زمان تغییر فایل رو متوجه بشه و بتونه اون رو cache کنه ؟
برای کش کردن نیازی به این هدر نیست و مرورگر بر اساس پارامترهای دیگر در موقع مناسب کش میکنه، منتها ما هدرهای دیگری رو که دستور کش رو به مرورگر میدن ارسال میکنیم تا این اجازه صریح باشه و مطمئن بشیم که مرورگر میتونه چنین تصمیمی بگیره (که طبیعتا مرورگرها در حالت عادی همینطور رفتار میکنن - یعنی کش میکنن). اینا رو قبلا در تاپیک دیگر عملا بررسی و تست کرده بودیم و کاملا کار میکنه. اگر خواستید آدرس تاپیک و همچنین برنامه ای رو که برای تست کش طراحی کرده بودم بدم خدمتتون.

ما با هدر مناسب میتونیم به مرورگر (و همچنین کش سرورهای بین راه) بگیم که یک پاسخ رو برای چه مدتی کش کنه. این مسئله دیگه وابسته به وجود هدر Last-Modified نیست. وقتی ما به مرورگر میگیم که میتونه یک پاسخ رو برای مثلا 24 ساعت کش کنه، مرورگر هم میتونه این کار رو بکنه و به توصیهء ما گوش کنه. برای این امر نیازی به دونستن زمان آخرین ویرایش فایل نداره، بلکه از زمانی که پاسخ تولید شده (که در هدرهای پاسخ مشخص میشه) یا پاسخ رو دریافت کرده میتونه به مدت مشخص شده، برای درخواست های بعدی از نسخهء کش شده استفاده کنه. بنظر شما برای این کار چرا چه نیازی به دونستن زمان آخرین ویرایش فایل داره؟

ضمنا در بعضی کارها آپدیت بودن کامل فایلها به هیچ وجه حیاتی نیست. مثلا یه موردی مثل اینکه فلان تصویر بکگراند سایت اگر عوض هم شد اما مرورگر تعدادی از کاربران هنوز از نسخهء کش شدهء قدیمی استفاده میکنه در خیلی سایتها و موارد اشکال خاصی محسوب نمیشه.

ضمنا جزییات تمام این هدرها و کلیت الگوریتم های مناسب در پروتکل HTTP1.1 (http://www.ietf.org/rfc/rfc2616.txt) شرح داده شده. یعنی دقیقا بیان شده هر هدر چه معنایی داره و مثلا درصورت وجود چند نوع هدر با کاربرد مشابه، تضاد و ناسازگاری بعضی هدرها با هم، یا عدم وجود بعضی هدرها، چه تفسیر و عملی باید صورت بگیره (یا مجاز هست صورت بگیره).


و در مورد Cache فایل‌های پویا مثل php که به صورت پیش‌فرض سرآمدهای Cache ارسال نمی‌شن
اگه واقعا نیاز به Cache فایل‌های پویا داشته باشید
مدیریت این عملیات باید از داخل خود فایل انجام بشه و با htaccess و آپاچی راهی وجود نداره که بشه فهمید این فایل چه زمانی نیاز به Cache داره.
بله از داخل فایل هم میشه و بنظر بنده هم این راه خیلی مناسب تری هست. اما مثلا میشه بر اساس دایرکتوری خاصی که کاربرد و شرایط فایلهای اون مشابه هستن دستورات لازم رو در htaccess اون دایرکتوری گذاشت. ولی بهرحال راه داخل فایل بنظر بنده هم در اکثر موارد حتی اینطور موارد بهتر هست.

درمورد فایلهای استاتیک هم منع کلی ای وجود نداره. این امکان و دستورات رو پس برای چی گذاشتن بنظر شما؟ حتما بعضی جاها نیاز هستن و کاربرد دارن بالاخره. اینکه بگید کاربردش خیلی کمه حرف دیگری هست تا اینکه بگید اصلا کاربرد مفیدی ندارن و تنظیمات و تصمیمات خودکار همیشه بهینه ترین حالت هستن.

[AMIBCT]

نقل قول از مطلبی که خودتون لینک گذاشتید:

The Last-Modified entity-header field value is often used as a cache
validator. In simple terms, a cache entry is considered to be valid
if the entity has not been modified since the Last-Modified value.

و


In other words, the preferred behavior for an HTTP/1.1 origin server
is to send both a strong entity tag and a Last-Modified value.

اینجا به طور صریح می‌گه که بهتره سرور هر دو تگ Last-Modified و یک ETag قوی رو به مرورگر بفرسته

لطفا وقتی منبع معرفی می‌کنید اول منبع رو مطالعه کنید بعد بهش ارجاع بدید

و نکته‌ی بعدی هم اینکه فرمودید چون این قابلیت وجود داره که سرآمدها رو حذف کنیم پس حذفشون می‌کنیم !( نقل به مضمون )
خوب اگه این قابلیت وجود داره، صدها قابلیت دیگه هم وجود داره که قطعا اطلاعاتی در موردشون ندارید

یه بار دیگه می‌گم:
تنظیمات پیش‌فرض Apache در شرایط بسیار خوبی قرار داره
دستکاری در این تنظیمات در شرایطی بسیار خاص و با دانش کافی باید صورت بگیره
نه اینکه بر خلاف نظر صریح استانداردها، تگ Last-Modified و Etag رو حذف کنید و بگید چون می‌شه پس باید حذفش کرد !

[eshpilen]

نقل قول از مطلبی که خودتون لینک گذاشتید:

The Last-Modified entity-header field value is often used as a cache
validator. In simple terms, a cache entry is considered to be valid
if the entity has not been modified since the Last-Modified value.

و


In other words, the preferred behavior for an HTTP/1.1 origin server
is to send both a strong entity tag and a Last-Modified value.

اینجا به طور صریح می‌گه که بهتره سرور هر دو تگ Last-Modified و یک ETag قوی رو به مرورگر بفرسته

متن اول میگه هدر Last-Modified اغلب برای اعتبارسنجی کش بکار میرود.
بنده قبلا هم گفته بودم که این هدر در کش کاربرد داره. اما چطورش رو در سطرهای بعدی بخونید.
متن دوم میگه رفتار ترجیح داده شده (نه ضروری) برای یک سرور HTTP ارسال هردوی Last-Modified و یک ETag است.
ما میتونیم این گفته رو به رفتار پیشفرض یک سرور عمومی بدون دخالت صریح انسان/برنامه نویس تفسیر کنیم. البته تاحدودی و با ابهام! یعنی این متن بعضی موارد استثناء و آگاهانه رو لزوما شامل نمیشه.

ضمنا درمورد Last-Modified قسمت دیگش رو درج نکردید:

SHOULD send a Last-Modified value if it is feasible to send one,
unless the risk of a breakdown in semantic transparency that
could result from using this date in an If-Modified-Since header
would lead to serious problems.

میگه باید این هدر رو درصورت شدنی بودن بفرستیم مگر اینکه یک ریسک در شفافیت معنایی وجود داشته باشد که استفاده از این تاریخ در یک هدر If-Modified-Since موجب مشکلات جدی شود.
حالا تفسیر دقیق این متن و اینکه یعنی چی بماند. فقط خواستم مطلب کامل بشه و متوجه بشید که همونطور که گفتم موارد استثناء هم وجود دارن و اینا به تشخیص برنامه نویس و نوع برنامه بستگی دارن. اینکه کجا مشکل جدی معنایی خواهیم داشت رو آیا سرور خودش بصورت خودکار تشخیص میده؟

ضمنا اینکه ما هدر Last-Modified رو هم برمیداریم بنظرم بخاطر این هست که اگر این هدر وجود داشته باشه، مرورگر هربار یک درخواست از نوع If-Modified-Since برای سرور میفرسته. بنابراین اگر ما بخوایم مرورگر بدون اینکه از سرور درخواست و سوالی بکنه از نسخهء کش شدهء خودش استفاده بکنه، باید این هدر رو حذف کنیم (همینطور هدر ETag هم باعث رفتار مشابهی میشه و بنابراین حذفش کردیم).
البته بنده نمیگم لزوما کار ما استاندارد و مناسب هست، اما میخواستم بگم منطقش چیه. اگر شما بخواید مطمئن بشید که مرورگر هر بار یک درخواست نمیفرسته و صرفا از نسخهء کش خودش استفاده میکنه، مجبورید هردوی این هدرها رو حذف کنید. حالا اینکه بگید این کار غیراستاندارد هست حرف دیگری و قابل بحث هست. بنده تا اینجا میخواستم در هدفی که داشتیم موفق بشیم و مهارت بیشتری بدست بیاریم. و شک دارم که اگر هر کسی چنین هدفی داشته باشه لزوما هدفش نامشروع باشه و این روش کاربردهای بجا و مفیدی نداشته باشه. موقعی که سرور یک درخواست مجدد برای هر دیتای کش شده ارسال میکنه، بهرحال در مجموع اینها یک تاخیر رفت و برگشت و مقدار هرچند کمی هم ترافیک و بار روی سرور ایجاد میکنن. ضمنا گذشته از این، اگر بخوایم این رو در یک برنامهء PHP پیاده کنیم نیاز داریم تا اون برنامه کاملتر باشه و با درخواستهای If-Modified-Since بصورت آگاهانه و هوشمندانه برخورد بکنه (نه اینکه هربار با 200 OK جواب بده و کل دیتا رو ارسال کنه) و این کار ما رو یه مقدار بیشتر و پیچیده تر میکنه در هدف کش کردن خروجی یک برنامهء PHP. البته بقول شما شاید این کار باید اصولی تر باشه و باید انجام بشه! ولی بنظر شما اگر برنامه نویس خودش تشخیص داد که این چک کردن مجدد هیچ ضرورتی نداره و خواست به روش ساده و سریعتر عمل بکنه، آیا حتما اشتباه میکنه و نباید به اینصورت عمل بکنه؟
ضمنا یه چیزی رو هم فراموش نکنیم و اون اینکه تاجاییکه بنده تست کردم هروقت کاربر با استفاده از رفرش صفحه رو بارگذاری مجدد بکنه، مرورگر مکانیزم کش رو Bypass میکنه (روی مرورگرهای FF و IE تست شده). یعنی این امکان بهرحال برای کاربر وجود داره که اگر بخواد بتونه با دستور رفرش صریح به مرورگر، نسخهء کاملا آپدیت شده ای از سایت بدست بیاره.

یه چیز دیگه رو هم فراموش نکنیم که پروتکل HTTP1.1 بهرحال یک پروتکل قدیمی هست و مثل خیلی موارد مشابهی که وجود داشته ممکنه بعضی کمبودها و ضعف هایی داشته باشه و به مرور زمان چیزهایی تجربه شدن یا نیاز به امکانات و روشهای گسترده تر و منعطف تری که پیشبینی نشده بودن بوجود آمدن که امکانات این پروتکل بقدر کافی پاسخگوی اونها نیستن. بنده زیاد از این موارد دیدم. استانداردها و پروتکل ها گاهی ابهام دارن یا ضعف و نقص هایی دارن و در عمل از اونها بصورت 100% کامل تبعیت نمیشه. البته مسلما باید سعی کنیم تا حداکثر ممکن با اونها سازگار باشیم. بنده هم نمیگم این مورد از این موارد هست، فقط خواستم بگم حتی در پروتکل ها و استانداردهای اصلی و معروف هم امکان وجود مشکل و کمبود هست و اینکه بگیم تحت هر شرایطی باید 100% از اونا تبعیت کنیم منطقی بنظر نمیاد، چون معادل اینه که بگیم این پروتکل ها و استانداردها 100% عاری از هر عیب و نقص و ابهامی و برای حال و آینده کاملا ایدئال هستن.


لطفا وقتی منبع معرفی می‌کنید اول منبع رو مطالعه کنید بعد بهش ارجاع بدید
اتفاقا بنده قبلا کامل اون رو خونده بودم که معرفی کردم. بهرحال چون حجم و پیچیدگی زیاد داره همهء جزییاتش رو یادم نمونده.


و نکته‌ی بعدی هم اینکه فرمودید چون این قابلیت وجود داره که سرآمدها رو حذف کنیم پس حذفشون می‌کنیم !( نقل به مضمون )
خوب اگه این قابلیت وجود داره، صدها قابلیت دیگه هم وجود داره که قطعا اطلاعاتی در موردشون ندارید
خب چطور؟ یعنی چی؟ این استدلال بود؟ :لبخند:
ما یه نیازی داشتیم و اینهم راهکارش بود. بدون این روش ممکن نیست. ضمنا این روش رو بنده ابداع نکردم؛ کدش رو بروبچ از جای دیگه پیدا کردن و بنده فقط هدف و روش کارش رو تحلیل کردم. بنده فقط خواستم روش کارش رو بررسی کنم و هدفی رو که دوستان داشتن محقق کنیم. حالا ممکنه استاندارد نبوده باشه (که هنوز کاملا ثابت نشده و شک دارم بصورت کلی عمل نادرستی باشه) ولی بنده تاجاییکه میدونستم و بنظرم رسید راهنمایی کردم که کاری رو که میخوان انجام بدن. هدفم یادگیری خودم هم بود که از درستی استنباط خودم مطمئن بشم.

[eshpilen]

اینم جهت تحقیق بیشتر: http://barnamenevis.org/showthread.php?289488
در پست اول تاپیک، مجموعه دستوراتی رو که از این روش استفاده کرده مشاهده میکنید.
بنده هم گفتم که این روش رو ابداع نکردم و فقط تحلیل کردم که هدفش چیه و چطور کار میکنه.

و اینم پستی هست که یه برنامهء ساده رو برای تست کردن راحت و مطمئن کش معرفی کردم:
http://barnamenevis.org/showthread.php?289488&p=1274976&viewfull=1#post1274976
البته این برنامه کش شدن یا نشدن رو فقط در یک حالت محدود و سادهء پایه تست میکنه که برای هدف ما در اون مورد کافی بود.

برای اطلاع از روش استفاده، پست قبلیش رو هم بخونید:
http://barnamenevis.org/showthread.php?289488&p=1274397&viewfull=1#post1274397

درمورد استاندارد بودن این روش هم، اول باید به این سوال جواب بدیم که آیا اینکه بخوایم یک دیتای خاص برای مدت مشخصی کش بشه و مرورگر در این مدت برای آپدیت اون دیتا هیچ تماسی با سرور برقرار نکنه، میتونه مجاز باشه یا نه؟ البته یک سوال مرتبط در درجهء بعد هم اینه که آیا اصلا چنین کاری میتونه فایده ای داشته باشه یا نه و تحت چه شرایطی؟

اگر جواب سوال اول مثبت باشه، سوال بعدی اینه که دقیقا با چه روشی میشه به این هدف رسید؟ آیا بدون حذف کردن هدرهای Last-Modified و ETag میشه با آمار و اطمینان قابل قبولی به این نتیجه رسید یا خیر؟

بهرحال در نهایت بنده ادعا ندارم که حتما درست میگم و این روش حتما اینطوری کار میکنه یا روشی هست که تضادی با استانداردهای وب نداره. این مسائل محض تجربه و بررسی و یادگیری برای خودم هم جالب بود و به اینکه چه رابطه ای با استانداردها داره یا واقعا چقدر در عمل مفید و لازم هست توجه خاصی نداشتم. هرچند اگر چنین کدهایی نوشته شده که نشون میده به احتمال زیاد طرف میدونسته این هدرها چکار میکنن و چطور توسط مرورگر مورد استفاده واقع میشن (که این در سطح یک آدم با اطلاعات ابتدایی در این زمینه نیست بنظرم) احتمالا هدف هوشمندانه ای هم در کار بوده و تصادفی نیست؛ هرچند با اینحال همیشه ممکنه طرف اشتباه کرده باشه! بنده بر اساس این فرض که این کدها از منبع نسبتا خوبی اومدن و عدهء زیادی ازش استفاده میکنن یک مقدار به استاندارد بودن اونها اطمینان کردم.
برای بقیهء مسائل هم اگر بنظرتون مهم هست و مخالفت یا نظر خاصی دارید میتونیم بازهم بحث و بررسی و تست هایی انجام بدیم. شما میتونید منابع و استدلال های خودتون رو مطرح کنید. بهرحال علم و یادگیری و فیلد گسترده و پیچیده و پویای برنامه نویسی همینه و همیشه میشه بحث و مطالعه و بررسی کرد. اینکه شما یه چیزی بگی و من یه چیزی و هیچکدام از مطالب از سطح اولیه و محدود فراتر نرن، چندان فایده ای نداره و به اطمینان کافی نمیرسه. حداقلش در جریان بحث و تحقیق و تست بیشتر آدم چیزهای خیلی بیشتری یاد میگیره. بنده خودم در اینمورد چیزهایی یاد گرفتم که قبلا باوجودی که منابع متعددی رو خونده بودم، یا نمیدونستم یا فکر میکردم سخته و احاطه نداشتم. حتی همین که شما گفتید این امر با استاندارد پروتکل جور درنمیاد هم گرچه ازش اطمینان کافی ندارم اما مد نظرم هست و شاید بعدا بیشتر ازش مطمئن بشم.
بهرحال هرچیزی رو هم اگر آدم بلد باشه بد نیست. بعضی چیزها کاربرد استاندارد و روزمره در کارهای کامل ندارن، اما گاهی برای راه اندازی سریع و راحت بعضی کاربردهای موقتی یا کم اهمیت یا در مراحل توسعه و تست و باگیابی و غیره میتونن واقعا مفید واقع بشن.

[AMIBCT]

برای بهینه‌سازی سرعت و کاهش ارتباط در شبکه
گوگل کروم در بخش Developer پیشنهادهای خیلی خوبی ارایه می‌ده

سایت یاهو هم صفحه‌ی مشهوری داره که حاوی چندین نکته‌ی بهینه‌سازی هست

استفاده از این دو منبع به یه طراح وب کمک می‌کنه نتیجه‌ی بسیار خوبی بگیره

صفحه‌ی بهینه‌سازی یاهو:
http://developer.yahoo.com/performance/rules.html

[eshpilen]

خیلی ممنون بابت معرفی این منبع. این یکی از بهترین منابع در این زمینه بود که تاحالا خونده بودم. البته بعضی مواردی که مطرح کرده بنظرم بیشتر روی سایتهای پرترافیک و یا سرورهای کند اهمیت دارن (خودش هم بعضی جاها اشاره کرده). بالاخره موارد هم ریز و درشت و بعضیا شرایط بخصوص دارن و نمیشه همهء موارد رو دارای اهمیت و تاثیر برابر در عموم شرایط دونست.
در کل واقعا خوب بود. یک جمع بندی عالی بر اساس تجربهء عملی و کار علمی.
بعضی چیزها که تاحالا برام مایهء سوال یا ابهام بود با خوندن این مقاله تقریبا حل شد. مثلا همیشه وقتی میدیدم بعضی سایتها مثلا تصویرهای بکار رفته در صفحات خودشون رو روی یک دامین یا سابدامین جداگانه میذارن مقداری تعجب میکردم و برام سوال میشد که چرا این کار رو میکنن؛ چون فکر میکردم از نظر برنامه نویسی و دسته بندی اگر باشه میشه از روشهای راحتتر و اصولی تری استفاده کرد. الان متوجه شدم که این کار بخاطر امکان دانلودهای موازی بیشتر هست، چون مرورگرها بر اساس استاندارد، روی تعداد دانلود همزمان از یک دامین محدودیت دارن (2 دانلود همزمان).
علاوه بر چیزهایی که یاد گرفتم حداقل یکی دو مورد دیگه هم بود که با خوندن این منبع سوال و ابهام هایی که قبلا برام وجود داشت برطرف شد.

اما در این منبع یه نکتۀ جالب اینکه، در بخش Add an Expires or a Cache-Control Header توصیه میکنه که زمان انقضای یک پاسخ رو به زمانی خیلی دور در آینده تنظیم کنیم، و در یک مثالی که در اینمورد زده این زمان 10 سال درنظر گرفته شده:

This example of the ExpiresDefault directive sets the Expires date 10 years out from the time of the request. ExpiresDefault "access plus 10 years"

اما پروتکل HTTP1.1 (http://www.ietf.org/rfc/rfc2616.txt) صریحا میگه که این زمان نباید بیش از یک سال باشه:

HTTP/1.1 servers SHOULD NOT send Expires dates more than one
year in the future.


این هم خودش یک تضاد واضح بین توصیهء دوتا منبع حرفه ای هست. حالا بنظر شما ما باید از کدومشون تبعیت کنیم؟
البته اینم بگم که عبارت SHOULD NOT در این منابع به معنای توصیه هست و دستور اکید نیست. برای دستور اکید از MUST استفاده میشه.

[eshpilen]

البته اینم بگم که عبارت SHOULD NOT در این منابع به معنای توصیه هست و دستور اکید نیست. برای دستور اکید از MUST استفاده میشه. اینو که گفتم بحث قبلی درمورد اینکه فرمودید پروتکل خودش گفته باید هدرهای ETag و Last-Modified رو ارسال کنیم یادم افتاد و اینکه در مورد این هدرها هم از عبارت SHOULD استفاده شده و این به این معنا هست که ارسال این هدرها فقط یک توصیه هست و اگر از اون پیروی نکنیم پروتکل رو نقض نکردیم.
این اصطلاحات در RFC2119 (http://www.ietf.org/rfc/rfc2119.txt) تعریف شدن. و این منبع درمورد SHOULD میگه:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

ترجمه:
کلمات SHOULD یا RECOMMENDED بدین معنا هستند که در شرایط بخصوصی دلایل معتبری برای نادیده گرفتن یک مورد خاص میتوانند وجود داشته بانشد، اما نتایج ضمنی کامل آن باید درک شده و قبل از انتخاب یک رویۀ دیگر با دقت ارزیابی شوند.

با این توضیحات فکر میکنم مشکل ما هم حل شد. یعنی فهمیدیم که حذف هدرهای ETag و Last-Modified بر خلاف استاندارد نیست و لزوما حتی برخلاف توصیه های استاندارد هم نیست. چون خود استاندارد با کاربرد این کلمات داره میگه شرایط خاصی میتونن وجود داشته باشن که دلایل منطقی کافی برای عمل کردن برخلاف این توصیه وجود داشته باشند.