آرشیو گروه فناوری و تکنولوژی: post #2110 — TG.ME

راهنمای نصب و پیکربندی Page Cache برای وردپرس در Windows Server و IIS قسمت دوم. • Enable page caching: فعال. آغاز فرآیند پایه کش صفحات. • Cache lifespan: ۱۰ ساعت. مقدار پیش‌فرض ۲۴ ساعته به‌منظور حفظ تازگی محتوا و جلوگیری از اختلال در مکانیسم nonce وردپرس، به ۱۰ ساعت کاهش یافت. • Serve cached pages to logged-in users: غیرفعال. جهت اطمینان از دریافت محتوای کاملاً به‌روز و پویا توسط مدیران و کاربران واردشده به حساب کاربری. • Generate separate files for mobile devices: غیرفعال. در طراحی‌های مدرن و واکنش‌گرا (Responsive) که ساختار HTML تغییر نمی‌کند، ایجاد فایل کش مجزا برای دستگاه‌های همراه غیرضروری است. • Gzip compression: غیرفعال در افزونه. به دلیل فعال بودن این قابلیت در سطح IIS، جهت جلوگیری از تداخل و فشرده‌سازی دوباره، در افزونه فعال نگردید. • Automatically preload content…: فعال. بازسازی خودکار محتوای کش پس از پاک‌سازی آن را تضمین می‌کند. استثناها (Cache Exclusion) و عدم استفاده از IIS Output Cache. گزینه‌های پیشرفته استثناسازی در افزونه (بر اساس URL، کوکی و مرورگر) بررسی شدند. به منظور حفظ رفتار استاندارد کش در وردپرس و جلوگیری از پیچیدگی‌های بی‌مورد، قوانین استثنای گسترده تعریف نگردید. همچنین بهره‌گیری از مکانیسم داخلی “Output Caching” در IIS ارزیابی شد. با این حال، از آنجا که WP-Optimize لایه کش HTML مطلوب را به صورت کامل فراهم می‌کرد، ایجاد لایه دوم کش HTML غیرضروری تشخیص داده شد؛ چرا که می‌توانست موجب تداخل در عملکرد سیستم شود. مرحله ارزیابی و تأیید صحت عملکرد. جهت اطمینان از کارکرد صحیح سیستم، بررسی‌های جامع زیر انجام گرفت. ۱. کنترل سیستم فایل: تشکیل فایل‌های استاتیک با پسوند .html در مسیر مربوطه روی سرور تأیید شد. ۲. بررسی کد منبع (Source Code): در انتهای کد منبع صفحات بازدیدشده، امضای تأیید WP-Optimize به صورت زیر مشاهده گردید: <!– Cached by WP-Optimize (gzip) – https://teamupdraft.com/wp-optimize/ – Last modified: 11 August 2026 07:50 (UTC:3) –> ۳. بررسی گزارش‌های سرور: پاک بودن فایل گزارش خطاهای PHP و عدم تکرار خطای WP_CACHE احراز گردید. نتیجه‌گیری و نمودار معماری. پیاده‌سازی Page Cache برای وردپرس در محیط Windows Server و IIS بدون وابستگی به قواعد .htaccess و با رعایت اصل تفکیک وظایف در لایه‌های مختلف، با موفقیت انجام شد. نمودار متنی زیر فرآیند پردازش درخواست‌های کاربران را در لایه‌های مختلف این معماری نشان می‌دهد: [ Windows Server / IIS ] • مدیریت HTTPS • فشرده‌سازی Gzip • کش فایل‌های استاتیک در مرورگر (۴ روز) [ WP-Optimize ] • (Page Cache) • [ Cache HIT ] [ Cache MISS ] • ارائه مستقیم پردازش وردپرس • HTML استاتیک و PHP [ MySQL ] تشریح تفصیلی جریان پردازش درخواست‌ها. ۱. لایه سرور (IIS): با ورود درخواست به سرور، IIS مسئولیت مدیریت ارتباط امن (HTTPS)، ارائه فایل‌های استاتیکِ کش‌شده (نظیر رسانه‌ها، CSS و JS) و فشرده‌سازی عمومی Gzip را بر عهده می‌گیرد و سپس درخواست را جهت پردازش به وردپرس ارجاع می‌دهد. ۲. لایه کش (WP-Optimize): حالت Cache HIT (یافت‌شده در کش): اگر نسخه استاتیک HTML صفحه درخواستی قبلاً ساخته شده باشد، درخواست بدون درگیر کردن لایه‌های PHP و پایگاه داده، مستقیماً از طریق IIS به کاربر تحویل داده می‌شود. این سناریو مصرف منابع سرور را به حداقل ممکن می‌رساند. حالت Cache MISS (یافت‌نشده در کش): اگر صفحه هنوز کش نشده باشد، محتوا تغییر کرده باشد یا زمان اعتبار کش به پایان رسیده باشد، درخواست به فرآیند “پردازش و تولید” هدایت می‌شود. ۳. لایه پردازش و کامپایل پویا (PHP + WordPress + MySQL): ارجاع درخواست: درخواست صفحه به مفسر PHP منتقل شده و هسته وردپرس بارگذاری می‌شود. استعلام داده‌ها: وردپرس جهت شکل‌دهی به محتوای صفحه، تنظیمات پوسته، داده‌های افزونه‌ها و دسترسی‌های کاربران، استعلام‌های SQL را به پایگاه داده MySQL ارسال می‌کند. تولید خروجی HTML: داده‌های دریافتی از پایگاه داده توسط PHP پردازش شده و به یک سند HTML پویا تبدیل می‌شوند. ذخیره‌سازی در کش: یک نسخه از این خروجی نهایی HTML توسط WP-Optimize در مسیر wp-content/cache/wpo-cache/… به‌صورت فایل .html ذخیره می‌شود (تا در بازدید بعدی، حالت Cache HIT رخ دهد. ) ارسال پاسخ: محتوای تولیدشده برای کاربر ارسال می‌گردد. ساختار نهایی مورد نظر با واگذاری مدیریت فایل‌های استاتیک و فشرده‌سازی به IIS، سپردن پیش‌بافته‌سازی صفحات پویا به WP-Optimize، و محدود کردن پردازش‌های سنگین PHP و MySQL تنها به موارد ضروری، موجب بهره‌وری حداکثری از منابع سخت‌افزاری سرور (CPU و RAM) خواهد شد…