اسمحوا لي أولاً أن أشرح لماذا كتبت هذا المقال ولماذا أعاني من هذه المشكلة الصغيرة. بادئ ذي بدء، يعد تشغيل ضغط الملفات الثابتة باستخدام gzip مفيدًا جدًا لتحسين سرعة الوصول إلى موقع الويب، ويقلل بشكل فعال الوقت الذي تستغرقه العناكب في الزحف إلى الصفحات الثابتة، وفي الوقت نفسه، لن يتسبب ذلك في 200 0 لعناكب Baidu مثل تشغيل ضغط الملفات الديناميكي. مشكلة الزحف 64، لذلك من ناحية، تساعد سرعة موقع الويب السريعة على تحسين تجربة المستخدم، ومن ناحية أخرى، أوضحت مدونة مسؤول Google هذا العام أن سرعة موقع الويب هي أحد عوامل التصنيف واستخدام المضيفين الأجانب. لبناء مواقع بايدو الصينية، سيؤدي التحسين والوقت غير المرضي إلى تقليل الزحف إلى الصفحات الداخلية بواسطة Baidu Spider وقد ذكر ذلك أيضًا من قبل في مقال مدونته: كيف تؤثر سرعة تحميل صفحة الويب على تأثير تحسين محركات البحث؟ في فترة زمنية محددة، يكون إجمالي الوقت الذي يستغرقه العنكبوت للزحف إلى موقع الويب ثابتًا، فإذا زادت سرعة الزحف، سيكون عدد الصفحات التي تم الزحف إليها أكثر، والعكس صحيح.
حسنًا، لنبدأ بالنص الرئيسي. في السؤال 2 من المقالة السابقة "النتائج التجريبية لزحف العنكبوت إلى الصفحات الثابتة وتفعيل ضغط gzip"، قمت بالتخمين حول كيفية حفظ النسخة المضغوطة من صفحات gzip الثابتة على الخادم كنت مرتبكًا لفترة طويلة بعد ذلك، وجدت أن السبب الأخير لنتائج gzip المختلفة التي أعادها المضيفان هو إصدار iis بدلاً من إعداد مجلد ذاكرة التخزين المؤقت الذي اعتقدت أنه صغير جدًا.
في الواقع، يحتوي iis7 على تحديث أكبر من iis6 في الضغط الثابت. استخدام مؤشر ترابط مختلف لضغط الملف وتخزين النسخة المضغوطة في مجلد ذاكرة التخزين المؤقت للملف المضغوط لفترة طويلة. في الماضي، أي على خادم IIS6، بعد اكتمال الضغط، لأي طلب HTTP للإصدار المضغوط من الملف الثابت، كان IIS6 يستدعي النسخة المضغوطة مباشرة من مجلد ذاكرة التخزين المؤقت ويعيدها إلى المتصفح.
ولكن في IIS7، يتم إجراء الضغط على مؤشر الترابط الرئيسي، ومن أجل توفير تكلفة الضغط، لا يحفظ IIS7 إصدارات مضغوطة طويلة المدى لجميع طلبات HTTP ولكن فقط الملفات الثابتة التي يتم الوصول إليها بشكل متكرر من قبل المستخدمين أول مرة قمت بزيارتها لم تكن مضغوطة، تم إرجاع النسخة المضغوطة عندما قمت بزيارتها مرة أخرى في فترة زمنية قصيرة، ولكن تم إرجاع النسخة غير المضغوطة عندما قمت بزيارتها بعد بضع دقائق. هنا يمكننا أن نفهم أن IIS7 لا يحفظ فعليًا النسخة المضغوطة في مجلد ذاكرة التخزين المؤقت، ولكنه يحفظها فقط في ذاكرة الخادم، أو يحفظ النسخة المضغوطة مؤقتًا في مجلد ذاكرة التخزين المؤقت ويحذفها بعد فترة.
إن طريقة IIS7 لتحديد الملفات التي يتم الوصول إليها بشكل متكرر والامتثال لمعايير الضغط هي الخاصيتين التاليتين في system.webServer/serverRuntime، وfrequentHitThreshold، وfrequentHitTimePeriod. إذا تلقى IIS إمكانية الوصول إلى ملف ثابت يتجاوز عتبة FrequentHitThreshold خلال فترة FrequentHitTimePeriod، فسيقوم IIS7 بضغط الملف الثابت مثل IIS6 وتخزين النسخة المضغوطة في مجلد ذاكرة التخزين المؤقت للملف المضغوط لفترة طويلة. إذا كانت هناك نسخة مخبأة من الملف موجودة بالفعل في مجلد ذاكرة التخزين المؤقت عندما يصل المستخدم إلى ملف على موقع الويب، فلن يحكم IIS7 بعد الآن على منطق FrequentHitThreshhold ويعيد النسخة المضغوطة مباشرة إلى المتصفح.
هذا الإعداد مؤلم للغاية بالفعل، لكن إجابة Microsoft الرسمية هي أنه يمكن استخدامه لتحسين أداء الخادم. . . لذا، إذا كنت تريد أن يكون IIS7 قادرًا على الضغط مثل IIS6، فهناك حلان بالطبع، كلاهما يقوم بتعديل قيم متكررةHitThreshold وfrequentHitTimePeriod:
الأول هو إضافة المحتوى التالي إلى web.config، وضبط FrequentHitThreshold على 1، وضبط FrequentHitTimePeriod على 10 دقائق.
<نظام.ويب سيرفر>
<تم تمكين وقت تشغيل الخادم = صحيح
متكررةHitThreshold=1
متكررHitTimePeriod=00:10:00/>
</system.webServer>
الطريقة الثانية هي فتح %windir%/system32/inetsrv/appcmd.exe، ثم إدخال سلسلة الأوامر التالية في واجهة سطر الأوامر، ثم الضغط على Enter
تعيين قسم التكوين:system.webServer/serverRuntime -frequentHitThreshold:1
ويشير مسؤولو مايكروسوفت إلى أن النهج الأقل تطرفًا لا يتمثل في خفض معدل تكرارHitThreshold، بل زيادة معدل تكرارHitTimePeriod، وهو أسلوب أكثر اعتدالًا بالنسبة لأداء الخادم. ما أريد أن أذكره هنا هو أنه بالنسبة للأصدقاء الذين لديهم VPS، يوصى بتعيينه يدويًا. يعتمد ما إذا كان بإمكان مستخدمي المضيف الافتراضي تعيينه على مزود الخدمة. لسوء الحظ، لا يمكنني تغييره. الجميع، محاولة إعطائها