مطالعه موردی مهندسی
محافظ Autoload گزینه‌ها
وردپرس در هر درخواست، پیش از هر کار دیگری آپشن‌های autoload را در حافظه می‌خواند. وقتی افزونه‌ها ترنزینت‌هایشان را با autoload=yes می‌نویسند، این بار بی‌سروصدا بزرگ می‌شود تا جایی که ساخت صفحه بدون هیچ نشانه‌ی ظاهری کند می‌شود. این افزونه همان یک قاعده‌ای را اعمال می‌کند که جلوی این اتفاق را می‌گیرد.
مسئله تجاری
چند افزونه‌ی فروشگاه ترنزینت‌هایشان را با autoload=yes در wp_options می‌نوشتند. آپشن‌های autoload در هر درخواست خوانده می‌شوند، کش باشد یا نباشد. پس چند هزار ردیف ترنزینت ولگرد روی هر بازدید تبدیل به حافظه و وزن کوئری می‌شود. هزینه‌اش واقعی است ولی هیچ‌وقت به‌شکل خطا بیرون نمی‌زند، و دقیقاً به همین دلیل ماه‌ها زنده می‌ماند.
آنچه تحویل دادم
- mu-options-autoload-guard.php که هر ردیف ترنزینت با autoload=yes را به no برمی‌گرداند و کار دیگری نمی‌کند.
- یک قفل اجرای روزانه در یک site transient؛ گارد در هر درخواست فقط یک خواندن کش‌شده هزینه دارد و در ۲۴ ساعت یک بار سراغ دیتابیس می‌رود.
- یک شمارش پایشی جدا که وقتی کل ردیف‌های autoload=yes از ۴٬۰۰۰ رد شد لاگ می‌کند؛ پشت یک ثابت، تا در حالت عادی خاموش بماند.
رویکرد فنی
- آپدیت اصلاحی فقط وقتی اجرا می‌شود که COUNT(*) قبلی دست‌کم یک ردیف متخلف پیدا کرده باشد. سایت سالم فقط هزینه‌ی همان شمارش را می‌دهد.
- به wp_loaded با اولویت ۵۰ وصل است؛ آن‌قدر دیر که افزونه‌های ترنزینت‌نویس حین بوت کارشان را تمام کرده باشند.
- کوئری پایش، ستون ایندکس‌شده‌ی autoload را می‌شمارد و سراغ اندازه‌ی ردیف نمی‌رود. همین ارزان نگهش می‌دارد تا کنار پاس اصلاحی اجرا شود.
- لاگ پیش‌فرض با یک ثابت خاموش است. گاردی که در هر اجرا به error_log می‌نویسد، خودش می‌شود یک منبع نویز تازه.
نتیجه و شواهد
ردیف‌های ترنزینت دیگر در مجموعه‌ی autoload تلنبار نمی‌شوند. این یک کنترل پیشگیرانه است، نه اصلاح یک‌باره: هر روز خطای افزونه‌های نصب‌شده را جبران می‌کند، بی‌آنکه لازم باشد بعد از هر آپدیت تک‌تکشان را ممیزی کنم.
اهمیت برای کارفرما
آپدیت افزونه‌ها مرتب این باگ را برمی‌گردانند. وقتی قاعده در کد اعمال شود و جدول را دستی درست نکنیم، هزینه‌ی یک ریلیز بد یک روز انحراف است، نه یک هفته کندی بی‌دلیل.
خلاصه اجرایی خوانا
خلاصه_اجرایی {
پروژه: "Options Autoload Guard"
فایل: "mu-plugins/mu-options-autoload-guard.php (۴۳ خط)"
قاعده: "هیچ ردیف _transient_ نباید autoload = yes باشد"
هوک: "wp_loaded، اولویت ۵۰"
محدودیت_نرخ: "قفل site transient، یک پاس DB در ۲۴ ساعت"
هشدار: "لاگ وقتی مجموع autoload=yes از ۴۰۰۰ رد شود"
پیش‌فرض: "لاگ خاموش؛ اصلاح همیشه روشن"
}ارزش حرفه‌ای این پروژه
بیشتر ارزش این افزونه در کارهایی است که نمی‌کند. جدول options را تمیز نمی‌کند، ردیف تکراری حذف نمی‌کند، بهینه‌سازی نمی‌کند. فقط یک قاعده را نگه می‌دارد.
گاردهای کوچک و تک‌کاره راحت بازبینی می‌شوند، راحت برداشته می‌شوند و کمتر پیش می‌آید غلط از آب دربیایند. برای زیرساختی که در هر درخواست اجرا می‌شود، معمولاً همین شکل درست است.