مشکل: WordPress هر صفحه را از صفر بازمیسازد
بهصورت پیشفرض، WordPress کاملاً پویاست: هر بازدید صفحه، PHP را بوت میکند، پلاگینها را بارگذاری میکند، دهها کوئری MySQL اجرا میکند و HTML را سرهم میکند پیش از آنکه یک بایت به بازدیدکننده برسد. این برای مشتی کاربر خوب است و زیر بار فاجعهبار، چون همزمانی با تعداد worker های PHP شما و سرعت پاسخ MySQL محدود میشود. وقتی یک نوشته به اشتراک گذاشته میشود یا یک کمپین فرود میآید، worker های PHP در انتظار دیتابیس روی هم انباشته میشوند، زمان پاسخ باد میکند، و سایت میتواند بهکلی از پا درآید — نه به این دلیل که محتوا سنگین است، بلکه چون همان کار برای هر بازدیدکننده دوباره انجام میشود.
object cache از نوع Redis: از دیتابیس همان چیز را دوباره نپرسید
object cache مدیریتشده Redis کوئریهای داخلی WordPress را رهگیری و نتایج آنها را در حافظه نگه میدارد. منوها، داده widget، روابط term، مقادیر option و متادیتای نوشته که در غیر این صورت در هر درخواست از MySQL دریافت میشدند، ظرف چند میکروثانیه از Redis ارائه میشوند. زیر یک جهش ترافیک این تفاوت میان دیتابیسی است که آرام به قطرهای از کوئریهای cache-miss پاسخ میدهد و دیتابیسی که غرق شده است. بهویژه به صفحات واردشده و پویا که نمیتوان آنها را کاملاً در edge کش کرد کمک میکند، چون حتی صفحات غیرقابلcache هم کار دیتابیسشان بهشدت کم میشود.
CDN edge cache: چیزهای سنگین را از نزدیک ارائه دهید
بیشتر حجم یک صفحه WordPress ثابت است — تصاویر، CSS، JS و فونتها — و هیچکدام برای تولید به PHP نیاز ندارند. فرستادن آن داراییها به edge شبکه cdn.com.tr یعنی از مکانی نزدیک به بازدیدکننده تحویل میشوند و پس از اولین پُر شدن هرگز به origin دست نمیزنند. برای محتوایی که بهصورت کلی امن است که cache شود، caching کاملصفحه در edge فراتر میرود و کل درخواستها را بدون بیدار کردن PHP پاسخ میدهد. اثر ترکیبی این است که origin شما بخش کوچکی از کل درخواستها را رسیدگی میکند، و آنهایی که رسیدگی میکند همانهای واقعاً پویا هستند.
WAF: ترافیک حمله را از worker های PHP دور نگه دارید
WordPress پُرحملهترین CMS روی وب است، و بیشتر آن فشار خودکار است: credential stuffing علیه wp-login.php، تقویت XML-RPC و کاوش برای endpoint های پلاگین آسیبپذیر. بدون یک فیلتر، هر یک از آن درخواستها یک worker از نوع PHP و برشی از زمان دیتابیس را مصرف میکند و سایت را برای کاربران واقعی افت میدهد حتی وقتی حمله هرگز موفق نمیشود. WAF در edge این ترافیک را پیش از رسیدن به اپلیکیشن بازرسی و فیلتر میکند، بنابراین الگوهای brute-force و سوءاستفادهگر در edge رها میشوند و worker های شما برای بازدیدکنندگان مشروع آزاد میمانند. این بهاندازه یک امکان امنیتی، یک امکان کارایی است.
استراتژی purge تا ویراستاران هرگز سردرگم نشوند
caching تهاجمی تنها زمانی کار میکند که ویراستاران به آن اعتماد کنند. الگویی که همه را راضی نگه میدارد، purge هدفمند هنگام انتشار است: وقتی یک نوشته ساخته یا بهروزرسانی میشود، آن URL و هر صفحه فهرستی که در آن ظاهر میشود را purge کنید، تا محتوای جدید بلافاصله زنده شود در حالی که بقیه سایت در cache سریع میماند. داراییهای ثابت باید نسخهبندی شوند تا یک بهروزرسانی قالب یا پلاگین بهطور طبیعی URL های جدید تولید کند نه اینکه به یک flush کامل نیاز داشته باشد. از پنل یا cdnctl میتوانید هنگام یک تغییر گسترده کل zone را هم purge کنید، اما روزبهروز هدف باطلسازیهای کوچک و دقیقی است که هرگز یک ویراستار را به این فکر نمیاندازد که چرا تغییرش نمایش داده نمیشود.
جان بهدر بردن از کمپینها و موجهای خبری
آزمون واقعی روزی است که ترافیک بدون هشدار چند برابر میشود — یک کمپین زنده میشود، یک خبر برداشته میشود، یک خبرنامه فرود میآید. با edge cache که درخواستهای ثابت و قابلcache را جذب میکند، Redis که از دیتابیس سپر میسازد، و WAF که آشغال را فیلتر میکند، origin تنها تهمانده کوچک پویا را میبیند، بنابراین سایت روی همان منابعی که در غیر این صورت از پا درمیآمدند سرپا و سریع میماند. سرِ آسودگی یک استک بسیار بزرگتر را از یک پیکربندی مدیریتشده میگیرید، و میتوانید در حین وقوع از طریق لاگها و وضعیت تماشا کنید که دوام میآورد، بهجای اینکه از کاربران عصبانی باخبر شوید.
راهاندازی گامبهگام
WordPress را روی پلتفرم مدیریتشده راهاندازی یا مهاجرت دهید
یک اپلیکیشن WordPress در پنل بسازید، که runtime از نوع PHP، ذخیرهسازی پایدار آپلودها و یک دیتابیس مدیریتشده MySQL را برای شما تأمین میکند. اگر یک سایت موجود را جابهجا میکنید، فایلها و export دیتابیس خود را بیاورید و اپلیکیشن را به آنها اشاره دهید تا runtime، DB و اعتبارنامهها بدون ویرایش دستی wp-config سیمکشی شوند.
object cache مدیریتشده Redis را فعال کنید
Redis مدیریتشده را به سایت متصل و drop-in مربوط به object cache را فعال کنید تا WordPress نتایج کوئریهای پرهزینه را در حافظه ذخیره کند. آنگاه جستوجوهای مکرر برای option ها، منوها، term ها و متادیتای نوشتهها بهجای کوبیدن MySQL در هر درخواست، از Redis پاسخ داده میشوند.
دامنه را با Auto SSL از مسیر edge اشاره دهید
دامنه خود را متصل کنید، apex و www را تأیید کنید و بگذارید Auto SSL گواهی را صادر کند. اکنون ترافیک ابتدا به edge شبکه cdn.com.tr میرسد، جایی که سیاستهای cache و WAF اعمال میشوند، پیش از آنکه چیزی به origin از نوع WordPress ارسال شود.
CDN cache را برای داراییهای ثابت روشن کنید
edge caching را فعال کنید تا تصاویر، CSS، JS و فونتها بهجای origin از مکانهای edge نزدیک ارائه شوند. این نخستین و بزرگترین دستاورد برای حجم صفحه است، و بیشتر درخواستها را بهکلی از PHP برمیدارد.
WAF را فعال کنید
سیاستهای WAF را روشن کنید تا الگوهای رایج حمله، تلاشهای brute-force علیه wp-login.php و سوءاستفاده از XML-RPC را پیش از مصرف worker های PHP فیلتر کنید. این سایت را حتی در حالی که کاوش میشود برای بازدیدکنندگان واقعی پاسخگو نگه میدارد.
purge هنگام انتشار را پیکربندی کنید
ویراستاران را طوری تنظیم کنید که هنگام انتشار یا بهروزرسانی محتوا، cache را از پنل یا از طریق cdnctl purge کنند، تا نوشتههای جدید بلافاصله ظاهر شوند در حالی که بقیه cacheشده میماند. در ترکیب با داراییهای نسخهدار، این باطلسازیها را هدفمند نگه میدارد بهجای flush کل سایت.
نمونه سناریوها
خبرهای فوری بهشدت به اشتراک گذاشته میشوند؛ edge cache و Redis به سایت امکان میدهند خوانندگیِ ناگهانی را جذب کند در حالی که ویراستاران همچنان لحظه انتشار محتوای تازه را میبینند.
صفحات واردشده و سبد خرید را نمیتوان کاملاً کش کرد، بنابراین object cache از نوع Redis با کاستن کار دیتابیسی که آن صفحات پویا تولید میکنند بار را به دوش میکشد.
یک دستور استاندارد WordPress بهعلاوه Redis بهعلاوه CDN بهعلاوه WAF روی هر سایت مشتری اعمال میشود، بنابراین کارایی و امنیت بهجای حدسوگمان پروژهبهپروژه یکدست است.
پرسشهای پرتکرار
آیا به یک پلاگین caching هم نیاز دارم؟
کار سنگین در لایه پلتفرم انجام میشود: Redis، object cache را رسیدگی میکند و CDN، edge caching را. یک پلاگین page-cache میتواند مکمل این باشد، اما باید از روی هم گذاشتن چند پلاگین که همه سعی میکنند caching کاملصفحه انجام دهند پرهیز کنید، که معمولاً باعث باطلسازیهای متناقض و صفحات کهنه میشود.
آیا caching کاربران واردشده، سبد خرید یا checkout را خراب میکند؟
خیر، چون آن صفحات بهعنوان پویا تلقی و در edge کاملاً کش نمیشوند. آنها همچنان بهشدت از object cache از نوع Redis بهره میبرند، که کار دیتابیس پشت آنها را میکاهد بدون آنکه هرگز نشست یک کاربر را به دیگری ارائه دهد.
object cache از نوع Redis با CDN cache چه تفاوتی دارد؟
CDN cache پاسخها و داراییهای نهایی را در edge، نزدیک به بازدیدکنندگان ذخیره میکند. object cache از نوع Redis در کنار WordPress زندگی میکند و نتایج کوئریهای داخلی دیتابیس را ذخیره میکند تا PHP بتواند صفحات پویا را بدون کوئری مجدد از MySQL بازسازی کند. آنها دو نیمه متفاوت مشکل را حل میکنند و با هم قویتریناند.
یک نوشته منتشرشده بهروزرسانی را نشان نمیدهد. چه کار کنم؟
آن URL را از پنل یا با cdnctl، purge کنید؛ edge همچنان نسخه پیشتر کششده را ارائه میدهد. راهاندازی purge-on-publish برای ویراستاران شما این را خودکار میکند تا نوشتههای جدید و بهروزشده بلافاصله زنده شوند.
آیا WAF پلاگینهای مشروع یا REST API را مسدود میکند؟
WAF الگوهای شناختهشده سوءاستفاده و رفتار brute-force را هدف میگیرد نه ترافیک عادی اپلیکیشن. استفاده مشروع از admin، پلاگین و REST API عبور میکند؛ اگر یک گردشکار خاص روزی یک قاعده را فعال کرد، سیاست را میتوان تنظیم کرد بهجای خاموش کردن آن.
آیا میتوانم سایت WordPress موجود خود را بدون قطعی به این منتقل کنم؟
فایلها و یک export دیتابیس را روی پلتفرم مدیریتشده میآورید و سایت را روی پلتفرم پیش از تغییر DNS راستیآزمایی میکنید. چون دامنه تنها پس از راستیآزمایی سایت و آماده بودن Auto SSL به edge منتقل میشود، بازه جابهجایی کوتاه و کمریسک است.