خانه » آموزش وردپرس

Autoload در دیتابیس وردپرس چیست؟ آموزش پیدا کردن و پاکسازی Autoload Options سنگین

دسته‌بندی‌ها: آموزش وردپرس ۲۵ شهریور ۱۴۰۵
0 رای
Autoload در دیتابیس وردپرس چیست؟

اگر در بخش «سلامت سایت» وردپرس با هشدار Autoloaded options could affect performance روبه‌رو شده‌اید، احتمالاً بخشی از داده‌های جدول wp_options در هر بار اجرای وردپرس به‌صورت خودکار بارگذاری می‌شوند و حجم آن‌ها از حد معمول بیشتر شده است.

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

در این آموزش ابتدا خیلی ساده توضیح می‌دهیم Autoload چیست و چرا وجود دارد. سپس با Site Health، phpMyAdmin و WP-CLI حجم Autoload سایت را اندازه می‌گیریم، گزینه‌های سنگین را پیدا می‌کنیم، مالک هر گزینه را مشخص می‌کنیم و در نهایت تصمیم می‌گیریم کدام داده باید باقی بماند، کدام گزینه فقط از Autoload خارج شود و کدام مورد واقعاً قابل حذف است.

هدف این آموزش کم کردن عدد Autoload به هر قیمت نیست. هدف این است که داده‌های غیرضروری از بارگذاری همیشگی خارج شوند، بدون اینکه تنظیمات سالم سایت آسیب ببینند.

Autoload در وردپرس چیست؟

وردپرس بخش بزرگی از تنظیمات خود، قالب‌ها و افزونه‌ها را در جدول wp_options نگهداری می‌کند. هر ردیف این جدول یک Option یا «گزینه» است و معمولاً نام و مقدار یک تنظیم را در خود دارد.

بعضی از این تنظیمات تقریباً در همه درخواست‌های وردپرس استفاده می‌شوند. اگر وردپرس برای دریافت هرکدام از آن‌ها یک Query جدا به دیتابیس بفرستد، تعداد درخواست‌ها بالا می‌رود. برای کاهش این رفت‌وبرگشت، وردپرس مجموعه‌ای از Optionها را در ابتدای اجرای درخواست به‌صورت یکجا بارگذاری و کش می‌کند. به این رفتار Autoload گفته می‌شود.

برای یک Option کوچک که تقریباً در همه صفحات لازم است، Autoload می‌تواند مفید باشد. مشکل زمانی شروع می‌شود که داده‌ای بزرگ یا کم‌استفاده هم وارد همین مجموعه شود. در این حالت اطلاعاتی که شاید فقط در یک صفحه مدیریت لازم باشند، در تعداد زیادی از درخواست‌ها همراه وردپرس بارگذاری می‌شوند.

تابع اصلی وردپرس برای بارگذاری این مجموعه wp_load_alloptions() است. بنابراین Autoload ذاتاً یک قابلیت بد یا اضافه نیست؛ اتفاقاً برای کاهش Queryهای پراکنده طراحی شده است. چیزی که باید کنترل شود حجم و نوع داده‌هایی است که Autoload شده‌اند.

اگر علاوه بر دیتابیس، سایت شما در بخش‌های دیگری هم کند است، پیشنهاد می‌کنیم راهنمای افزایش سرعت سایت وردپرسی را هم مطالعه کنید. Autoload فقط یکی از علت‌های احتمالی کندی است و همیشه عامل اصلی نیست.

Autoload در جدول wp_options چگونه مشخص می‌شود؟

در نصب معمولی وردپرس، جدول تنظیمات wp_options نام دارد؛ اما بخش wp_ فقط پیشوند پیش‌فرض است و ممکن است در سایت شما متفاوت باشد. قبل از اجرای Query، نام واقعی جدول Options را در phpMyAdmin یا تنظیمات دیتابیس بررسی کنید.

در نسخه‌های قدیمی‌تر وردپرس معمولاً فقط مقادیر yes و no را در ستون Autoload می‌دیدیم. از WordPress 6.6 به بعد مقادیر دقیق‌تری به Options API اضافه شده‌اند. به همین دلیل Queryهایی که فقط autoload = 'yes' را بررسی می‌کنند، ممکن است بخشی از داده‌های Autoload سایت‌های جدید را نبینند.

مقدار ستون autoload در حالت پیش‌فرض فعلی Autoload می‌شود؟ توضیح ساده
yes بله مقدار قدیمی؛ ممکن است هنوز در سایت‌های قدیمی زیاد دیده شود.
on بله Autoload به‌صورت صریح فعال شده است.
auto-on بله وردپرس براساس منطق داخلی تصمیم گرفته گزینه Autoload شود.
auto بله تصمیم به رفتار پیش‌فرض وردپرس سپرده شده است.
no خیر مقدار قدیمی برای غیرفعال بودن Autoload.
off خیر Autoload به‌صورت صریح غیرفعال شده است.
auto-off خیر وردپرس براساس منطق داخلی تصمیم گرفته گزینه Autoload نشود.

در کدهای جدید وردپرس، استفاده از مقدارهای متنی yes و no برای Options API از WordPress 6.7 منسوخ شده و توسعه‌دهنده بهتر است از true و false استفاده کند. با این حال رکوردهای قدیمی با yes و no همچنان در دیتابیس وجود دارند و وردپرس آن‌ها را می‌شناسد.

چرا Autoload سنگین می‌تواند سرعت سایت را کاهش دهد؟

وقتی حجم مجموعه Autoload زیاد می‌شود، داده بیشتری باید در شروع درخواست خوانده و در حافظه یا Object Cache قرار بگیرد. این موضوع می‌تواند روی مصرف حافظه PHP، زمان پردازش و در بعضی سایت‌ها زمان پاسخ اولیه سرور تأثیر بگذارد.

اما نباید رابطه را بیش از حد ساده کنیم. اگر TTFB سایت بالاست، فقط با دیدن یک جدول بزرگ نمی‌توان گفت Autoload قطعاً علت اصلی است. هاست ضعیف، Queryهای سنگین، پردازش PHP، درخواست‌های Ajax، افزونه‌های کند، APIهای خارجی و تنظیمات کش هم می‌توانند عامل باشند.

Autoload زمانی مشکوک‌تر است که یکی یا چند مورد زیر را هم‌زمان ببینید:

  • Site Health درباره Autoloaded Options هشدار می‌دهد؛
  • چند Option بسیار بزرگ در بالای فهرست قرار گرفته‌اند؛
  • نام Optionها مربوط به افزونه‌ای است که مدت‌ها قبل حذف شده؛
  • حجم Autoload در طول زمان مرتب افزایش پیدا می‌کند؛
  • پیشخوان یا درخواست‌های PHP بدون دلیل مشخص حافظه زیادی مصرف می‌کنند؛
  • پس از پاکسازی کنترل‌شده، زمان پاسخ یا مصرف منابع واقعاً بهتر می‌شود.

هشدار Autoloaded Options در Site Health چیست؟

از WordPress 6.6 یک بررسی مستقیم برای Autoload به بخش سلامت سایت اضافه شد. برای دیدن آن از پیشخوان به مسیر ابزارها ← سلامت سایت ← وضعیت بروید.

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

این عدد را نباید یک مرز جادویی در نظر گرفت. سایت شما ممکن است کمی بالاتر از این مقدار باشد و مشکل محسوسی نداشته باشد؛ یا زیر این مقدار باشد اما یک Option بی‌استفاده بزرگ داشته باشد که بهتر است اصلاح شود. Site Health یک هشدار برای شروع بررسی است، نه دستور حذف داده.

هشدار Autoloaded options در بخش سلامت سایت وردپرس.

تغییرات WordPress 6.6 برای جلوگیری از Autoload بیش از حد

در WordPress 6.6 رفتار Options API بهتر شد تا وردپرس بتواند درباره بعضی Optionها هوشمندانه‌تر تصمیم بگیرد. یکی از تغییرات مهم این است که وقتی توسعه‌دهنده مقدار Autoload را صریح مشخص نکند، وردپرس می‌تواند براساس اندازه داده تصمیم بگیرد.

در حالت پیش‌فرض، اگر مقدار Option از حدود 150000 بایت بزرگ‌تر باشد و توسعه‌دهنده Autoload را به‌صورت صریح روی true نگذاشته باشد، وردپرس می‌تواند آن را با وضعیت auto-off ذخیره کند تا در مجموعه Autoload قرار نگیرد.

این بهبود برای Optionهای جدید یا Optionهایی که دوباره از طریق API ذخیره می‌شوند مفید است، اما یک نکته مهم دارد: وردپرس قرار نیست همه رکوردهای قدیمی دیتابیس شما را خودکار بازنویسی کند. بنابراین سایتی که سال‌ها فعالیت کرده ممکن است همچنان Optionهای قدیمی و حجیمی داشته باشد که نیاز به بررسی دستی دارند.

قبل از پاکسازی Autoload حتماً از دیتابیس بکاپ بگیرید

هر تغییری در wp_options می‌تواند روی تنظیمات مهم سایت اثر بگذارد. قبل از اینکه حتی یک Option را حذف یا Autoload آن را تغییر دهید، از دیتابیس نسخه پشتیبان تهیه کنید.

اگر WP-CLI در دسترس است، می‌توانید با دستور زیر از دیتابیس خروجی بگیرید:

wp db export before-autoload-cleanup.sql

و اگر لازم شد همان فایل را بازیابی کنید:

wp db import before-autoload-cleanup.sql

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

هشدار: بازگردانی کامل دیتابیس روی سایت زنده می‌تواند اطلاعاتی را که بعد از زمان بکاپ ایجاد شده‌اند، مانند سفارش جدید، دیدگاه یا ثبت‌نام کاربر، از بین ببرد. اگر فقط یک Option را تغییر داده‌اید، بازیابی همان Option امن‌تر از Restore کامل دیتابیس است.

مرحله 1: حجم کل Autoload را اندازه بگیرید

اگر Site Health هشدار داده، اولین قدم این است که عدد واقعی را ببینید. در phpMyAdmin دیتابیس سایت را انتخاب کنید، وارد تب SQL شوید و Query زیر را اجرا کنید:

SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto');

اگر پیشوند جدول شما wp_ نیست، نام wp_options را با نام واقعی جدول سایت جایگزین کنید.

این Query مجموع تقریبی اندازه option_valueهای Autoload را برحسب KB نشان می‌دهد. عدد حاصل دقیقاً معادل مصرف RAM یا هزینه واقعی هر درخواست نیست؛ فقط یک معیار خوب برای مقایسه و پیدا کردن رشد غیرعادی است.

اگر مقدار بالاتر از آستانه Site Health بود، هنوز چیزی را حذف نکنید. مرحله بعد پیدا کردن گزینه‌هایی است که بیشترین سهم را در این حجم دارند.

مرحله 2: سنگین‌ترین Autoload Options را پیدا کنید

برای نمایش 30 گزینه بزرگ‌تر از Query زیر استفاده کنید:

SELECT
    option_name,
    autoload,
    ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 30;

این فهرست معمولاً خیلی سریع نشان می‌دهد بخش اصلی حجم از کجا آمده است. ممکن است یک Option بزرگ چندصد کیلوبایتی داشته باشید یا صدها Option کوچک که در مجموع حجم زیادی ساخته‌اند.

پیدا کردن گزینه های سنگین Autoload در جدول wp_options با phpMyAdmin.

مرحله 3: مالک هر Option را پیدا کنید

بزرگ بودن یک Option به معنی غیرضروری بودن آن نیست. قبل از هر تصمیم باید مشخص کنید این رکورد متعلق به کدام بخش سایت است.

نام Option معمولاً سرنخ خوبی می‌دهد. افزونه‌ها اغلب از پیشوند مخصوص خود استفاده می‌کنند. برای مثال ممکن است نام یک Option با نام یا مخفف افزونه شروع شود. اما این روش همیشه قطعی نیست.

برای شناسایی مالک Option می‌توانید این مسیرها را دنبال کنید:

  • نام کامل Option را در فایل‌های افزونه‌ها و قالب جستجو کنید؛
  • مستندات رسمی افزونه را بررسی کنید؛
  • اگر افزونه حذف شده، ببینید آیا سازنده درباره باقی ماندن داده پس از حذف توضیح داده است؛
  • تاریخچه سایت را بررسی کنید تا مشخص شود Option مربوط به افزونه قدیمی، قالب قبلی یا ابزار مهاجرت است؛
  • اگر Option مربوط به افزونه فعال است، قبل از تغییر Autoload آن رفتار افزونه را بررسی کنید.

روی سروری که دسترسی SSH دارد، یک جستجوی ساده در فایل‌ها می‌تواند کمک کند:

grep -R "my_option_name" wp-content/plugins wp-content/themes -n

عبارت my_option_name را با نام واقعی Option جایگزین کنید. اگر نتیجه‌ای پیدا نشد، این موضوع به‌تنهایی ثابت نمی‌کند که Option اضافی است؛ ممکن است نام آن به‌صورت پویا ساخته شده باشد یا افزونه قبلاً حذف شده باشد.

مرحله 4: Autoload را با WP-CLI بررسی کنید

اگر SSH و WP-CLI دارید، بدون ورود به phpMyAdmin هم می‌توانید بخش زیادی از بررسی را انجام دهید.

برای دیدن مجموع حجم Optionهای Autoload:

wp option list --autoload=on --format=total_bytes

برای نمایش نام، وضعیت Autoload و اندازه هر Option:

wp option list --autoload=on --fields=option_name,autoload,size_bytes --format=table

برای دیدن مقدار یک Option مشخص:

wp option get my_option_name
نکته امنیتی: مقدار بعضی Optionها می‌تواند شامل کلید API، توکن، مسیر داخلی، تنظیمات حساس یا اطلاعاتی باشد که نباید در تیکت عمومی و اسکرین‌شات منتشر شود. قبل از اشتراک خروجی wp option get محتوای آن را بررسی کنید.
بررسی Autoload Options وردپرس با WP-CLI.

چطور تصمیم بگیریم یک Option حذف شود یا فقط Autoload آن خاموش شود؟

بعد از پیدا کردن Optionهای بزرگ، مهم‌ترین بخش کار تصمیم‌گیری است. سه حالت اصلی وجود دارد: Option ضروری است و باید همان‌طور بماند؛ Option لازم است ولی نباید در هر درخواست Autoload شود؛ یا Option دیگر هیچ استفاده‌ای ندارد و می‌توان آن را حذف کرد.

وضعیت Option اقدام مناسب مثال
در بیشتر درخواست‌های سایت استفاده می‌شود معمولاً Autoload را حفظ کنید تنظیم کوچک و عمومی که در بخش‌های مختلف لازم است
لازم است اما فقط در چند صفحه خاص استفاده می‌شود بعد از بررسی، Autoload را خاموش کنید داده حجیم مربوط به یک صفحه مدیریت خاص
متعلق به افزونه حذف‌شده و واقعاً بدون استفاده است پس از بکاپ، حذف دقیق همان Option تنظیم باقی‌مانده از افزونه‌ای که دیگر نصب نیست
مالک یا کاربرد آن مشخص نیست فعلاً هیچ تغییری ندهید Option با نام مبهم یا داده سریال‌شده ناشناس
Transient بدون انقضا و بزرگ است منبع تولید را بررسی کنید؛ حذف کورکورانه کافی نیست کش موقت افزونه که بدون زمان انقضا ساخته شده است

مرحله 5: اگر Option لازم است ولی نباید Autoload شود

اگر مطمئن شده‌اید Option باید در دیتابیس باقی بماند اما در هر درخواست نیاز نیست، بهتر است به‌جای ویرایش مستقیم SQL از API خود وردپرس یا WP-CLI استفاده کنید.

در WP-CLI:

wp option set-autoload my_option_name off

این دستور فقط وضعیت Autoload را تغییر می‌دهد و مقدار Option را دستکاری نمی‌کند.

برای توسعه‌دهندگان، WordPress از نسخه 6.4 تابع مخصوص تغییر Autoload دارد:

wp_set_option_autoload( 'my_option_name', false );

اگر در حال توسعه افزونه خودتان هستید، هنگام ساخت Option نیز بهتر است از همان ابتدا تصمیم درست بگیرید. برای داده‌ای که فقط در چند صفحه خاص استفاده می‌شود، Autoload را صریح روی false قرار دهید.

مزیت استفاده از API وردپرس این است که کش داخلی Optionها هم با منطق خود وردپرس هماهنگ می‌شود. تغییر مستقیم ستون Autoload در دیتابیس ممکن است در سایت‌هایی که Object Cache دارند تا زمان پاک شدن کش، نتیجه گیج‌کننده‌ای ایجاد کند.

آموزش افزایش حافظه php در وردپرس به همراه شرح دلایل ایجاد آن

مرحله 6: حذف Option یتیم یا بلااستفاده

اگر با بررسی فایل‌ها، افزونه‌ها و مستندات مطمئن شدید Option متعلق به افزونه یا قالبی است که دیگر استفاده نمی‌شود، می‌توانید بعد از بکاپ همان رکورد مشخص را حذف کنید.

روش امن‌تر با WP-CLI:

wp option delete my_old_plugin_option

بهتر است گزینه‌ها را یکی‌یکی یا در گروه‌های کوچک حذف کنید و بعد از هر مرحله سایت را تست کنید. حذف چندصد Option با یک دستور عمومی، فقط به این دلیل که نام آن‌ها شبیه نام یک افزونه است، روش مطمئنی نیست.

از DELETEهای گسترده با LIKE یا الگوهای مبهم برای پاکسازی استفاده نکنید، مگر اینکه دقیقاً بدانید چه داده‌هایی انتخاب می‌شوند و نسخه پشتیبان قابل بازیابی داشته باشید. یک Prefix مشابه ممکن است توسط افزونه فعال یا چند بخش مختلف سایت استفاده شود.

Transientها چه ارتباطی با Autoload دارند؟

Transientها داده‌های موقتی وردپرس هستند که معمولاً برای کش کردن نتیجه یک پردازش یا درخواست استفاده می‌شوند. بدون Persistent Object Cache، این داده‌ها می‌توانند داخل جدول wp_options ذخیره شوند.

یک نکته مهم که گاهی در آموزش‌ها اشتباه توضیح داده می‌شود این است که همه Transientها لزوماً Autoload نمی‌شوند. طبق پیاده‌سازی فعلی WordPress:

  • Transient دارای زمان انقضا، به‌صورت پیش‌فرض Autoload نمی‌شود؛
  • Transient بدون زمان انقضا می‌تواند Autoload شود.

به همین دلیل اگر یک افزونه داده موقتی بزرگ را بدون زمان انقضا بسازد، ممکن است همان داده در مجموعه Autoload قرار بگیرد. راه‌حل اصولی فقط حذف دستی آن رکورد نیست؛ باید مشخص شود کدام افزونه آن را ایجاد کرده و آیا تنظیم یا نسخه جدیدتری برای اصلاح رفتار وجود دارد.

اگر Redis یا Memcached به‌عنوان Persistent Object Cache فعال باشد، محل نگهداری Transientها می‌تواند متفاوت باشد. بنابراین هنگام بررسی دیتابیس، نوع کش سایت را هم در نظر بگیرید.

آیا Redis یا Object Cache مشکل Autoload را حل می‌کند؟

Persistent Object Cache می‌تواند تعداد مراجعه به دیتابیس را کم کند و مجموعه alloptions را در حافظه نگه دارد. این موضوع در سایت پرترافیک مفید است، اما به این معنی نیست که حجم زیاد Autoload دیگر اهمیتی ندارد.

اگر مجموعه Autoload چند مگابایت داده غیرضروری داشته باشد، همان داده باید در کش نگهداری، از کش دریافت و در حافظه پردازش شود. Object Cache می‌تواند محل گلوگاه را تغییر دهد، اما داده غیرضروری را به داده ضروری تبدیل نمی‌کند.

بنابراین ترتیب منطقی این است: ابتدا Autoloadهای واقعاً اضافه را اصلاح کنید، سپس از Object Cache برای کاهش Queryهای تکراری استفاده کنید. نصب Redis به‌تنهایی جای پاکسازی دیتابیس را نمی‌گیرد.

آیا WooCommerce، Elementor یا Wordfence همیشه Autoload را سنگین می‌کنند؟

نه. نمی‌توان یک فهرست ثابت از «افزونه‌های مقصر» ارائه کرد. یک افزونه بزرگ ممکن است روی یک سایت Autoload کاملاً منطقی داشته باشد و روی سایت دیگر به‌دلیل نسخه قدیمی، تنظیمات باقی‌مانده یا افزودنی جانبی، داده بیشتری ایجاد کند.

به همین دلیل بهتر است به‌جای اینکه صرفاً نام WooCommerce، Elementor، افزونه امنیتی یا فرم‌ساز را مقصر بدانیم، خود داده را اندازه بگیریم. نام Option، اندازه آن، وضعیت افزونه و کاربرد واقعی آن معیارهای بهتری برای تصمیم‌گیری هستند.

اگر یک Option با نام افزونه فعال در بالای فهرست قرار دارد، قبل از هر تغییر این موارد را بررسی کنید:

  • افزونه به آخرین نسخه پایدار بروزرسانی شده باشد؛
  • آیا همان Option در مستندات یا کد افزونه استفاده می‌شود؛
  • آیا حجم زیاد نتیجه تعداد زیاد تنظیمات، لاگ یا داده قدیمی است؛
  • آیا خود افزونه ابزار پاکسازی یا Reset برای داده‌های قدیمی دارد؛
  • آیا افزودنی دیگری داده را در Option همان افزونه ذخیره می‌کند.

مرحله 7: کش را پاک کنید و دوباره اندازه بگیرید

بعد از تغییر Autoload یا حذف یک Option، نتیجه را همان لحظه فقط با نگاه کردن به دیتابیس قضاوت نکنید. اگر سایت Object Cache دارد، ممکن است مقدار قبلی همچنان در کش باشد.

در WP-CLI می‌توانید کش شیء وردپرس را با دستور زیر پاک کنید:

wp cache flush

اگر Redis، Memcached یا کش مخصوص هاست دارید، روش پاکسازی همان سرویس را هم انجام دهید. Page Cache نیز بهتر است پاک شود تا تست صفحات با نسخه قبلی انجام نشود.

بعد از آن دوباره حجم Autoload را با Site Health، SQL یا WP-CLI اندازه بگیرید و مهم‌تر از عدد، عملکرد سایت را تست کنید.

بعد از پاکسازی چه بخش‌هایی را تست کنیم؟

اگر Option اشتباهی تغییر کرده باشد، مشکل همیشه به‌صورت صفحه سفید ظاهر نمی‌شود. ممکن است فقط یک بخش از سایت تنظیم خود را از دست بدهد. بعد از هر مرحله این موارد را بررسی کنید:

  • صفحه اصلی و چند نوشته یا برگه مهم؛
  • ورود و پیشخوان مدیریت؛
  • تنظیمات قالب و افزونه‌ای که Option به آن مربوط بوده است؛
  • فرم تماس، جستجو و سایر بخش‌های تعاملی؛
  • در فروشگاه: صفحه محصول، سبد خرید، تسویه‌حساب و ایمیل سفارش؛
  • REST API یا فرایندهای Ajax مهم در صورت استفاده؛
  • Cron و کارهای زمان‌بندی‌شده مهم؛
  • خطاهای PHP و لاگ سرور.

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

یک سناریوی عملی برای پاکسازی Autoload

فرض کنید Site Health حجم Autoload را حدود 1.8 MB گزارش کرده است. Query بزرگ‌ترین Optionها نشان می‌دهد یک Option با حجم حدود 700 KB در صدر فهرست است و نام آن شبیه افزونه‌ای است که 6 ماه قبل از سایت حذف شده.

روش درست این نیست که فوراً آن رکورد را Delete کنید. مسیر امن می‌تواند این‌طور باشد:

  1. از دیتابیس بکاپ بگیرید؛
  2. نام Option را در کدهای فعلی جستجو کنید؛
  3. مطمئن شوید افزونه مربوط واقعاً دیگر نصب یا استفاده نمی‌شود؛
  4. مقدار همان Option را برای بازیابی احتمالی ذخیره کنید؛
  5. فقط همان Option را با WP-CLI حذف کنید؛
  6. Object Cache را پاک کنید؛
  7. Site Health و حجم کل را دوباره بررسی کنید؛
  8. صفحات و فرایندهای مهم سایت را تست کنید.

اگر حجم از 1.8 MB به حدود 1.1 MB کاهش پیدا کرد ولی هشدار هنوز باقی بود، سراغ Option بعدی بروید. این روش مرحله‌ای بسیار امن‌تر از پاک کردن چندین رکورد در یک نوبت است.

چه زمانی فقط Autoload را خاموش کنیم و Option را حذف نکنیم؟

بعضی Optionها کاملاً لازم هستند اما فقط در شرایط خاص خوانده می‌شوند. برای مثال ممکن است یک افزونه تنظیمات بزرگی داشته باشد که فقط در صفحه مدیریت خودش نیاز است.

اگر با بررسی کد یا مستندات مطمئن شدید چنین Optionی در همه صفحات لازم نیست، تغییر Autoload از روشن به خاموش می‌تواند انتخاب بهتری از حذف کامل باشد. در این حالت افزونه همچنان می‌تواند با get_option() مقدار خود را هنگام نیاز بخواند؛ فقط آن داده دیگر همراه مجموعه Autoload در شروع همه درخواست‌ها بارگذاری نمی‌شود.

این تصمیم باید براساس رفتار واقعی افزونه باشد. خاموش کردن Autoload یک Option که در تقریباً همه صفحات استفاده می‌شود ممکن است به‌جای بهبود، Queryهای جداگانه بیشتری ایجاد کند.

اشتباهات رایج در پاکسازی Autoload وردپرس

حذف هر Option بزرگ فقط به دلیل اندازه آن

بزرگ بودن یک رکورد نشانه‌ای برای بررسی است، نه مجوز حذف. Option می‌تواند بزرگ و در عین حال برای سایت ضروری باشد.

استفاده از Queryهای قدیمی با autoload = yes

در وردپرس جدید فقط بررسی yes کافی نیست. مقادیر on، auto-on و auto هم در رفتار پیش‌فرض فعلی جزو Autoload محسوب می‌شوند.

تغییر مستقیم چندین رکورد در phpMyAdmin

اگر 20 Option را هم‌زمان تغییر دهید و سایت خراب شود، پیدا کردن گزینه مشکل‌ساز بسیار سخت‌تر خواهد بود. تغییرات را کوچک و قابل بازگشت انجام دهید.

حذف داده افزونه فعال به امید ساخته شدن دوباره

بعضی تنظیمات بعد از حذف خودکار ساخته نمی‌شوند یا با مقدار پیش‌فرض برمی‌گردند. حذف یک Option ممکن است تنظیمات مهم را از بین ببرد.

نادیده گرفتن Object Cache

بعد از تغییر دیتابیس ممکن است نسخه قبلی Option در Redis، Memcached یا کش داخلی باقی بماند. کش را پاک و سپس نتیجه را تست کنید.

تمرکز فقط روی رسیدن به کمتر از 800000 بایت

آستانه Site Health ابزار هشدار است. هدف باید حذف بار غیرضروری باشد، نه رسیدن اجباری به یک عدد خاص.

حذف Transient بدون پیدا کردن منبع تولید

اگر افزونه هر چند دقیقه همان داده را دوباره بسازد، پاک کردن Transient فقط یک اثر موقت دارد. منبع تولید و نحوه تنظیم زمان انقضا مهم‌تر است.

برای توسعه‌دهندگان؛ Autoload را از ابتدا درست تنظیم کنید

اگر افزونه یا قابلیت اختصاصی می‌نویسید، بهترین پاکسازی این است که اصلاً داده غیرضروری وارد Autoload نشود.

برای Optionی که در بیشتر درخواست‌ها استفاده می‌شود:

add_option( 'my_plugin_setting', $value, '', true );

برای Optionی که فقط در صفحه خاص یا مدیریت استفاده می‌شود:

add_option( 'my_plugin_large_data', $value, '', false );

برای تغییر وضعیت Autoload یک Option موجود بدون تغییر مقدار آن:

wp_set_option_autoload( 'my_plugin_large_data', false );

در WordPress 6.6 مقدار پیش‌فرض پارامتر Autoload در Options API به null تغییر کرده است؛ یعنی در بعضی شرایط وردپرس می‌تواند براساس منطق داخلی درباره Autoload تصمیم بگیرد. اگر توسعه‌دهنده دقیقاً می‌داند Option در همه درخواست‌ها لازم یا غیرلازم است، تعیین صریح true یا false انتخاب روشن‌تری است.

برای داده‌های موقتی نیز اگر از Transients API استفاده می‌کنید، زمان انقضا تعیین کنید؛ زیرا Transient بدون انقضا در حالت ذخیره‌سازی دیتابیس می‌تواند Autoload شود.

چک‌لیست امن پاکسازی Autoload Options

مرحله کار لازم چرا مهم است؟
1 از دیتابیس بکاپ بگیرید امکان بازگشت در صورت حذف یا تغییر اشتباه
2 Site Health و حجم کل را بررسی کنید داشتن نقطه شروع برای مقایسه
3 30 Option بزرگ‌تر را پیدا کنید تمرکز روی موارد اثرگذار به‌جای پاکسازی کور
4 مالک و کاربرد Option را مشخص کنید جلوگیری از حذف تنظیم ضروری
5 بین نگه داشتن، خاموش کردن Autoload یا حذف تصمیم بگیرید هر Option راه‌حل یکسان ندارد
6 تغییرات را یکی‌یکی انجام دهید عیب‌یابی و Rollback ساده‌تر می‌شود
7 Object Cache و Page Cache را پاک کنید مشاهده نتیجه واقعی تغییر
8 صفحات و فرایندهای مهم را تست کنید اطمینان از سالم ماندن سایت
9 حجم و عملکرد را دوباره اندازه بگیرید تأیید اینکه تغییر واقعاً مفید بوده است

اگر بعد از تغییر سایت خراب شد چه کنیم؟

اگر فقط یک Option را تغییر داده‌اید، بهترین کار این است که همان تغییر را برگردانید. برای مثال اگر Autoload یک Option را خاموش کرده‌اید، می‌توانید دوباره آن را روشن کنید:

wp option set-autoload my_option_name on

اگر Option حذف شده و مقدار قبلی را ذخیره کرده‌اید، همان مقدار را بازیابی کنید. اگر چند تغییر هم‌زمان انجام شده و مشخص نیست مشکل از کدام مورد است، از بکاپ دیتابیس استفاده کنید.

بعد از Rollback، کش را هم پاک کنید:

wp cache flush

در سایت زنده، Restore کامل دیتابیس را با احتیاط انجام دهید؛ چون ممکن است سفارش، کاربر یا محتوایی که بعد از بکاپ ایجاد شده از دست برود.

چه زمانی Autoload عامل اصلی کندی نیست؟

اگر حجم Autoload منطقی است یا بعد از پاکسازی تغییر محسوسی در عملکرد سایت ایجاد نشد، بهتر است سراغ سایر عوامل بروید. موارد زیر می‌توانند TTFB و مصرف منابع را بالا ببرند:

  • هاست یا دیتابیس کند؛
  • تعداد کم PHP Worker در ترافیک بالا؛
  • Queryهای سنگین افزونه یا قالب؛
  • درخواست‌های زیاد admin-ajax.php؛
  • API خارجی کند؛
  • کش نامناسب یا غیرفعال؛
  • Jobهای سنگین WP-Cron؛
  • Object Cache ناسازگار یا بدتنظیم؛
  • فشار بالای CPU، RAM یا I/O سرور.

در چنین شرایطی کم کردن چندصد کیلوبایت Autoload ممکن است مفید باشد، اما مشکل اصلی را حل نمی‌کند. اندازه‌گیری قبل و بعد از هر تغییر کمک می‌کند بهینه‌سازی را روی عامل واقعی متمرکز کنید.

جمع‌بندی

Autoload یکی از بخش‌های طبیعی و مفید سیستم Options وردپرس است. مشکل زمانی ایجاد می‌شود که داده‌ای حجیم، قدیمی یا کم‌استفاده وارد مجموعه‌ای شود که در شروع تعداد زیادی از درخواست‌ها بارگذاری می‌شود.

برای پاکسازی امن، از Site Health یا WP-CLI برای دیدن وضعیت شروع کنید، حجم کل را اندازه بگیرید، بزرگ‌ترین Optionها را پیدا کنید و قبل از هر تغییر مالک آن‌ها را مشخص کنید. اگر Option واقعاً یتیم است، بعد از بکاپ حذفش کنید؛ اگر لازم است اما در همه صفحات استفاده نمی‌شود، Autoload آن را با API وردپرس یا WP-CLI خاموش کنید.

مهم‌تر از کاهش عدد، نتیجه واقعی است. بعد از هر تغییر کش را پاک کنید، صفحات و فرایندهای مهم را تست کنید و عملکرد را دوباره اندازه بگیرید. اگر Autoload سبک شد اما سایت همچنان کند بود، باید سراغ سایر بخش‌های PHP، دیتابیس، افزونه‌ها، کش و زیرساخت بروید.

برای مطالعه فنی‌تر درباره رفتار Autoload، می‌توانید مستندات بهینه‌سازی وردپرس و توضیحات رسمی تغییرات Options API در WordPress 6.6 را ببینید.

سوالات متداول

Autoload روشی است که وردپرس با آن تعدادی از Optionهای جدول wp_options را در شروع درخواست به‌صورت یکجا بارگذاری و کش می‌کند. این کار برای تنظیمات کوچک و پرتکرار مفید است، اما اگر داده‌های زیاد یا کم‌استفاده Autoload شوند می‌تواند مصرف منابع را بالا ببرد.
WordPress از نسخه 6.6 به‌طور پیش‌فرض در Site Health برای مجموع Autoload برابر با 800000 بایت یا بیشتر هشدار عملکردی نمایش می‌دهد. این مقدار یک آستانه هشدار است، نه قانون قطعی برای همه سایت‌ها. نوع داده، زیرساخت و استفاده واقعی Optionها هم مهم است.
خیر. بعضی Optionها در بخش‌های مختلف سایت استفاده می‌شوند و Autoload آن‌ها از Queryهای متعدد جلوگیری می‌کند. خاموش کردن همه گزینه‌ها می‌تواند عملکرد را بدتر کند یا باعث Queryهای جداگانه بیشتری شود.
خیر. اندازه فقط یک علامت برای بررسی است. ابتدا باید مالک Option و کاربرد آن مشخص شود. اگر داده لازم است ولی در هر درخواست نیاز نیست، خاموش کردن Autoload می‌تواند بهتر از حذف باشد.
بعضی ابزارها می‌توانند گزینه‌های بزرگ یا یتیم را نشان دهند، اما تصمیم حذف هنوز نیاز به بررسی دارد. هیچ افزونه‌ای نمی‌تواند بدون شناخت کامل سایت با اطمینان بگوید هر Option بزرگ غیرضروری است. قبل از پاکسازی خودکار، بکاپ و بررسی مالک داده ضروری است.
Redis یا Memcached می‌تواند خواندن مکرر Optionها از دیتابیس را کمتر کند، اما داده غیرضروری Autoload همچنان فضای کش و حافظه مصرف می‌کند. Object Cache مکمل پاکسازی است، نه جایگزین آن.
نه به‌صورت کلی. Transient دارای زمان انقضا به‌طور پیش‌فرض Autoload نمی‌شود، اما Transient بدون انقضا می‌تواند Autoload شود. اگر Transient بزرگ و بدون انقضا پیدا کردید، منبع تولید آن را بررسی کنید.
آیا این مقاله برای شما مفید بود؟
تقریبا
خیر
6 سال عضو همیار وردپرس
نویسندگی و توسعه، دو مسیر از یک رسالت‌اند: خلق چیزی که بماند

دیدگاهتان را بنویسید

ارسال دیدگاه به معنی این است که شما ابتدا قوانین ارسال دیدگاه را مطالعه کرده‌اید و با آن موافق هستید.