تشخیص علت کندی سایت وردپرسی توسط پلاگین Query Monitor

آموزش کار با Query Monitor

تشخیص علت کندی سایت وردپرسی توسط پلاگین Query Monitor

چگونه با پلاگین Query Monitor علت کندی وردپرس را دقیق شناسایی کنیم؟

 

کاربران شما وبسایت کند را دوست ندارند! اگر وبسایت وردپرسی شما کند شده، احتمال ماندن کاربران در سایت به شدت کاهش می‌یابد. این موضوع می‌تواند رتبه سایت شما در گوگل و فروش شما را کاهش دهد.

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

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

این افزونه را می‌توانید از طریق لینک زیر در مخزن وردپرس دریافت کنید:

https://wordpress.org/plugins/query-monitor

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


پس از نصب و فعالسازی پلاگین، نوار ابزار بالای سایت وردپرسی شما آمارهایی مشابه زیر نمایش می‌دهد:

2,45s 87,2MB 0,08s 152Q

این آمار هرکدام اطلاعات مهمی به شما می‌دهند.

  • 2,45s → مدت زمان کل لود شدن صفحه (Execution Time)
  • 87,2MB → میزان مصرف حافظه (RAM) هنگام لود صفحه
  • 0,08s → زمان لود پایگاه داده (Database Time)
  • 152Q → تعداد کوئری‌های دیتابیس که اجرا شده‌اند (152 Query)

با کلیک روی این آمار، پلاگین Query Monitor جزئیات بیشتری را در پایین سایت نمایش می‌دهد. در ادامه، هر بخش را توضیح می‌دهیم.


بخش Overview

این بخش همان توضیحات Query Monitor در ادمین بار وردپرس است، اما با جزئیات بیشتر.

بخش Overview در پلاگین Query Monitor

در تصویر بالا مشاهده می‌کنید Opcache و Object Cache روی این هاست غیرفعال هستند. فعالسازی آنها باعث بهبود پرفورمنس وردپرس می‌شود. هاستینگ می‌تواند Opcache را فعال کند و برای Object Cache، ابتدا سرویس Redis و اکستنشن PHP آن را نصب کنند. سپس می‌توانید از پلاگین زیر استفاده کنید:

https://wordpress.org/plugins/redis-cache


بخش Database Queries

بخش Database Queries مهم‌ترین قسمت پلاگین است و اطلاعات کلیدی از دستورات اجرا شده روی دیتابیس را نمایش می‌دهد.

بخش Database Queries در پلاگین Query Monitor

هنگام اولین بازدید از این بخش، این پیام نمایش داده می‌شود:

Extended query information such as the component and affected rows is not available. Query Monitor was unable to symlink its db.php file into place. See this help page for more information.

این پیام به شما می‌گوید که برای مشخص شدن هر کوئری به کدام بخش وردپرس یا پلاگین مربوط است، باید یک symlink ایجاد کنید:

ln -s /path/to/wordpress/wp-content/plugins/query-monitor/wp-content/db.php /path/to/wordpress/wp-content/db.php

اگر از هاست اشتراکی استفاده می‌کنید، هنوز می‌توانید این میانبر را ایجاد کنید. در هاست cPanel با یوزرنیم ariohost، دستور زیر را در Cronjob سی‌پنل برای اجرای هر دقیقه اضافه کنید:

ln -s /home/ariohost/public_html/wp-content/plugins/query-monitor/wp-content/db.php /home/ariohost/public_html/wp-content/db.php

پس از چند دقیقه و اطمینان از اجرای دستور، آن را از Cronjob حذف کنید. مسیر home ممکن است متفاوت باشد، بنابراین مسیر دقیق را از هاستینگ بپرسید. در سرورهایی که بیش از یک هارد دارند، مسیر ممکن است /home2/ariohost باشد.

پس از اجرای دستور، وقتی به صفحه Database Queries بازگردید، بخش Component اضافه می‌شود و نشان می‌دهد کوئری اجرا شده به کدام بخش وردپرس تعلق دارد. مطابق تصویر زیر:

بخش Component در Database Queries در پلاگین Query Monitor

مثلاً کوئری شماره 4 توسط پلاگین akismet و شماره 5 توسط autoptimize اجرا شده است.

زمان اجرای کوئری‌ها تاثیر مستقیم روی سرعت سایت دارد. بهتر است هر کوئری در چند میلی‌ثانیه اجرا شود و مجموع زمان کوئری‌ها کمتر از یک ثانیه باشد. در غیر این صورت، سایت دچار کندی می‌شود.

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

Duplicate Queries

این بخش کوئری‌های تکراری را نمایش می‌دهد. وجود این کوئری‌ها نشان می‌دهد پیاده‌سازی بهینه نیست و می‌تواند عملکرد سایت را کاهش دهد.

مثال Duplicate Queries در ووکامرس

فرض کنید در صفحه فروشگاه ووکامرس، قیمت و موجودی محصولات با تابع get_post_meta() فراخوانی می‌شوند:

$price = get_post_meta( $product_id, '_price', true );
$stock = get_post_meta( $product_id, '_stock', true );

اگر صفحه ۲۰ محصول داشته باشد، برای هر محصول دو کوئری مشابه اجرا می‌شود:

SELECT meta_value FROM wp_postmeta WHERE post_id = 123 AND meta_key = '_price';
SELECT meta_value FROM wp_postmeta WHERE post_id = 123 AND meta_key = '_stock';

در بخش Duplicate Queries افزونه Query Monitor این کوئری‌ها ۴۰ بار تکرار شده‌اند. این مشکل N+1 Query نام دارد و سرعت صفحه را کاهش می‌دهد.

راه‌حل‌ها:

  • استفاده از Object Cache (Redis یا Memcached)
  • بارگذاری متاهای مورد نیاز همه محصولات با یک کوئری گروهی
  • استفاده از توابع ووکامرس که داده‌ها را از کش داخلی ووکامرس می‌خوانند، مانند wc_get_product() به جای چند get_post_meta()

بخش HTTP API Calls

این بخش ریکوئست‌های HTTP سایت شما با سرورهای دیگر را نمایش می‌دهد. مثلا پلاگین‌هایی که از سرورهای خارجی اطلاعات می‌گیرند، در این بخش مشخص می‌شوند.

در بخش آپدیت‌ها و افزونه‌ها، اطلاعات زیادی از ارتباط سایت با wordpress.org وجود دارد. اگر این ارتباط کند باشد، لود سایت هم کند می‌شود.

بخش HTTP API Calls در پلاگین Query Monitor

همانطور که در تصویر مشاهده می‌کنید، کامل شدن HTTP API Calls حدود ۲۰ ثانیه طول کشیده است. این زمان زیاد است و اجرای سایر بخش‌ها مثل کوئری‌های دیتابیس نیز به زمان نهایی لود صفحه اضافه می‌شود.

مثلاً اجرای درخواست http://api.wordpress.org/plugins/update-check/1.1 حدود ۳ تا ۴ ثانیه زمان برده است، در حالی که استاندارد معمولاا زیر یک ثانیه یا در حالت بهتر زیر ۵۰۰ میلی‌ثانیه است.

این موضوع نشان می‌دهد اتصال سرور شما به api.wordpress.org مشکل دارد و باید با هاستینگ مطرح شود.

گاهی ممکن است مشکل از سرور component باشد که در این صورت باید ارائه‌دهنده مقصد مشکل را رفع کند.

راه‌حل موقت: هاستینگ می‌تواند آدرس کند را در فایل /etc/hosts لینوکس به 127.0.0.1 هدایت کند. این کار باعث می‌شود درخواست HTTP سریع fail شود و PHP منتظر timeout طولانی نماند.

بخش HTTP API Calls در پلاگین Query Monitor - پس از رفع مشکل

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

سایر بخش‌های Query Monitor

Timings

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


Logs

در این بخش، لاگ‌های PHP یا افزونه‌ها نمایش داده می‌شوند. این بخش برای دیباگ خطاها و بررسی پیام‌های توسعه‌دهندگان مفید است.


Request

اطلاعات درخواست فعلی شامل متد HTTP، کوئری پارامترها، هدرها و متغیرهای ارسال‌شده به وردپرس در این بخش مشاهده می‌شوند.


Admin Screen

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


Scripts

این قسمت فایل‌های JavaScript لود شده در صفحه را همراه با وابستگی‌ها، نسخه و محل بارگذاری (header یا footer) نشان می‌دهد. با این اطلاعات می‌توانید اسکریپت‌های اضافی یا تکراری را شناسایی کنید.


Styles

مشابه بخش Scripts است، با این تفاوت که فایل‌های CSS لود شده در صفحه را نشان می‌دهد. این بخش برای شناسایی استایل‌های غیرضروری یا تکراری کاربرد دارد.


Hooks & Actions

این بخش لیست هوک‌ها و اکشن‌هایی که در طول اجرای درخواست فراخوانی شده‌اند را نمایش می‌دهد. شما می‌توانید ترتیب اجرا و منطق افزونه‌ها را بررسی کنید.


Transient Updates

اطلاعات مربوط به Transientها و بروزرسانی آن‌ها در این بخش قابل مشاهده است. این بخش به تشخیص مشکلات کش موقت و اجرای بیش از حد درخواست‌های آپدیت کمک می‌کند.


Capability Checks

این بخش سطح دسترسی کاربران (Capabilities) را که در طول درخواست بررسی شده‌اند نشان می‌دهد. برای دیباگ مسائل مربوط به دسترسی مفید است.


Environment

این بخش اطلاعات محیط اجرا شامل نسخه PHP، دیتابیس، تنظیمات سرور و پیکربندی وردپرس را نمایش می‌دهد و بیشتر جنبه اطلاعاتی دارد.


Conditionals

شرط‌های وردپرسی مانند is_single، is_page و is_admin که مقدار true یا false دارند، در این بخش مشاهده می‌شوند. این اطلاعات برای بررسی منطق شرطی قالب یا افزونه کاربرد دارند.


بررسی چالشی در خصوص بخش HTTP API Calls و مشکل Timeout

گاهی اجرای یک API Call طولانی می‌شود و لود صفحه با Timeout مواجه می‌شود. در این حالت، المان‌های وردپرس مثل Query Monitor لود نمی‌شوند و نمی‌توانید تشخیص دهید کدام بخش باعث کندی شده است.

برای حل مشکل، باید موقتا Timeoutهای وب سرور و PHP را افزایش دهید تا لود صفحه کامل انجام شود و بخش مشکل‌دار مشخص شود.

مثلاً در سرورهایی که وب سرور LiteSpeed دارند، ادمین سرور باید فایل زیر را ویرایش کند:

nano /usr/local/lsws/conf/httpd_config.xml

و مقدار connTimeout را افزایش دهد. پس از آن، وب سرور را ریستارت کند:

systemctl restart lsws

همچنین، در php.ini مقدار max_execution_time را به همان میزان افزایش دهید. پس از مشخص شدن مشکل، حتما مقادیر را به حالت پیش‌فرض برگردانید تا مشکلات پرفورمنس و امنیت ایجاد نشود.


جمع‌بندی: پلاگین Query Monitor یک ابزار کارآمد و مفید برای بررسی وضعیت وبسایت‌های وردپرسی است. برای داشتن بهترین کارآیی و سرعت لود در وردپرس، استفاده از هاستینگ معتبر اهمیت بالایی دارد.

هاست وردپرس و هاست ووکامرس آریوهاست دو سرویس ویژه میزبانی سایت‌ها و فروشگاه‌های وردپرسی هستند. در این سرویس‌ها با بهره‌گیری از بروزترین تکنولوژی سخت‌افزاری و بهینه‌ترین کانفیگ نرم‌افزاری، تجربه‌ای ایده‌آل از میزبانی سایت خواهید داشت. کوئری‌های دیتابیس با هاردهای فوق پرسرعت NVMe در کوتاه‌ترین زمان ممکن اجرا می‌شوند و سرعت لود سایت شما بسیار مطلوب خواهد بود.

با راه‌اندازی پروکسی‌های چندلایه اختصاصی، کمترین خطاهای مربوط به بخش HTTP API Calls رخ می‌دهد و در صورت بروز مشکل، کارشناسان پشتیبانی فنی آریوهاست سریعا آن را رفع می‌کنند.

Post Your Comment

پیشنهاد ویژه به طراحان وب‌سایت!

با خرید هاست از آریوهاست علاوه بر دریافت خدمات با کیفیت، در سود فروش میزبانی هم سهیم شوید.

آریوهاست

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

تماس با ما