محتوای آموزشی وبلاگ نتآرام
وقتی صفحهای دیر باز میشود، اولین مظنون معمولاً «هاست» است. گاهی این تشخیص درست است، اما در عمل یک افزونه که برای هر درخواست چند کوئری سنگین اجرا میکند، اتصال کند به API بیرونی یا تنظیم نادرست کش میتواند همان نشانه را ایجاد کند. اگر بدون اندازهگیری مهاجرت کنید، ممکن است هزینه و قطعی انتقال را بپذیرید و چند ساعت بعد همان کندی را روی سرور جدید ببینید.
TTFB یا Time to First Byte فاصلهٔ زمانی میان ارسال درخواست مرورگر و دریافت نخستین بایت پاسخ است. این عدد فقط سرعت دیسک یا پردازنده نیست؛ مجموع چند مرحله است:
- پیدا کردن IP دامنه در DNS؛
- برقراری اتصال TCP و در HTTPS مذاکرهٔ TLS؛
- رسیدن درخواست به وبسرور؛
- اجرای PHP و وردپرس؛
- کوئریهای دیتابیس، کش و سرویسهای بیرونی؛
- آمادهشدن نخستین بخش پاسخ.
بنابراین «TTFB بالا» یک علامت است، نه نام بیماری.
ابتدا آزمایش را قابل تکرار کنید
یک بار بازکردن صفحه معیار خوبی نیست. اتصال اینترنت، گرم یا سرد بودن کش و حتی اجرای Cron وردپرس نتیجه را تغییر میدهد. برای مقایسه:
- یک URL ثابت مثل صفحهٔ اصلی و یک صفحهٔ محصول را انتخاب کنید؛
- هر URL را دستکم پنج بار از یک مبدأ آزمایش کنید؛
- نتیجهٔ بار اول را جدا از چهار بار بعدی نگه دارید؛
- تست را هم در حالت ورودنشده و هم، اگر لازم است، در حالت ورودشده انجام دهید؛
- ساعت آزمون را ثبت کنید تا بتوان آن را با نمودار CPU، RAM و I/O تطبیق داد.
دستور زیر فقط هدرها را میگیرد و زمان مراحل اصلی را نشان میدهد:
کد / دستورcurl -sS -o /dev/null \
-w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/
اگر
time_namelookup بالاست، از DNS شروع کنید. اگر فاصلهٔ connect تا appconnect زیاد است، مسیر شبکه یا TLS را بررسی کنید. اگر این مراحل سریعاند اما time_starttransfer دیر میرسد، بخش عمدهٔ مسئله پس از ورود درخواست به سرور رخ میدهد.آزمایش تعیینکننده: فایل ثابت در برابر وردپرس
در همان دامنه یک فایل کوچک ثابت مثل
health-check.txt قرار دهید و زمان آن را با یک صفحهٔ وردپرس مقایسه کنید. محتوای فایل مهم نیست؛ مهم این است که PHP و دیتابیس در پاسخ آن دخالت ندارند.- اگر فایل ثابت هم کند است، شبکه، TLS، وبسرور، محدودیت منابع یا مسیر CDN را بررسی کنید.
- اگر فایل ثابت سریع و وردپرس کند است، تمرکز باید روی PHP، دیتابیس، قالب و افزونهها باشد.
- اگر فقط بار نخست کند است و درخواستهای بعدی سریع میشوند، کش یا اتصال بیرونیِ گرمشونده نقش مهمی دارد.
این آزمایش ساده جلوی بسیاری از مهاجرتهای بینتیجه را میگیرد.
کش را موقتاً از معادله خارج کنید
یک سایت ممکن است برای بازدیدکننده ناشناس سریع باشد، اما صفحهٔ سبد خرید یا پیشخوان بهدلیل عبور از کش کند بماند. هنگام بررسی این موارد را جدا کنید:
- کش صفحه در وبسرور یا افزونه؛
- Object Cache مانند Redis؛
- کش مرورگر و CDN؛
- صفحاتی که با کوکی یا سشن عمداً کش نمیشوند.
هدف خاموشکردن دائمی کش نیست. میخواهیم بفهمیم سرعت خوب از اجرای سالم برنامه میآید یا فقط پاسخ قبلی دوباره تحویل داده میشود. در فروشگاه ووکامرسی، سرعت صفحهٔ اصلی بهتنهایی نمایندهٔ تجربهٔ واقعی پرداخت نیست.
PHP و دیتابیس را با نشانهها بررسی کنید
اگر کندی داخل وردپرس است، چهار نشانه معمولاً سریعتر از حدسزدن ما را به علت نزدیک میکنند:
۱. افزونهای که به سرویس بیرونی منتظر میماند
افزونهٔ پیامک، نرخ ارز، لایسنس یا فید بیرونی ممکن است در همان درخواست HTTP منتظر پاسخ سامانهٔ دیگری بماند. وقتی سرویس مقابل کند یا قطع شود، TTFB سایت شما هم بالا میرود. لاگ زمان پاسخ درخواستهای خروجی و خاموشکردن کنترلشدهٔ افزونه در محیط آزمایشی، این حالت را روشن میکند.
۲. کوئریهای پرتعداد یا بدون ایندکس مناسب
در سایتهای قدیمی، جدولهای
options و متادیتا میتوانند رشد کنند. Autoload بزرگ، کوئریهای تکراری و جستوجو روی ستون بدون ایندکس، CPU را الزاماً ۱۰۰ درصد نمیکنند اما پاسخ را عقب میاندازند. Query Monitor در محیط آزمایشی مفید است؛ روی سایت پرترافیک آن را دائماً روشن نگذارید.۳. کمبود Worker، نه فقط کمبود RAM
ممکن است حافظه آزاد باشد اما همهٔ PHP Workerها درگیر درخواستهای طولانی باشند. در این حالت درخواست تازه در صف میماند. نمودار همزمانی، صف PHP-FPM و زمان اجرای اسکریپت از عدد خام RAM مهمتر است.
۴. WordPress Cron در زمان نامناسب
کارهای زمانبندیشدهٔ سنگین، ساخت فید، پاکسازی یا ارسال گروهی ایمیل میتوانند درست هنگام بازدید اجرا شوند. انتقال Cron به زمانبندی واقعی سرور و شکستن کار بزرگ به دستههای کوچک، نوسان زمان پاسخ را کم میکند.
چه زمانی ارتقای هاست تصمیم درستی است؟
ارتقا زمانی منطقی است که اندازهگیری نشان دهد محدودیت پایدار زیرساخت دارید: صف پردازش در ساعات شلوغ، CPU throttling، I/O wait، کمبود Worker یا دیتابیسی که با منابع فعلی پاسخگو نیست. در این وضعیت هاست وردپرس با پیکربندی مناسبتر یا برای بارهای خاص سرور مجازی مدیریتشده میتواند ظرفیت و کنترل بیشتری بدهد.
اما اگر یک API بیرونی ۸ ثانیه منتظر میماند یا یک افزونه در هر صفحه صدها کوئری میسازد، قویترکردن سرور فقط مسئله را گرانتر میکند. ابتدا گلوگاه را حذف کنید، سپس ظرفیتی بخرید که با بار واقعی تناسب دارد.
یک برگهٔ نتیجهٔ کوتاه بسازید
پیش از هر تغییر، این پنج عدد را نگه دارید:
| مورد | قبل از تغییر | بعد از تغییر |
| --- | ---: | ---: |
| فایل ثابت، بار اول | | |
| فایل ثابت، میانگین گرم | | |
| صفحهٔ وردپرس، بار اول | | |
| صفحهٔ وردپرس، میانگین گرم | | |
| صفحهٔ بدون کش مثل سبد خرید | | |
با این جدول میفهمید تغییر واقعاً مؤثر بوده یا فقط یک آزمون خوششانس دیدهاید. اگر برای تحلیل لاگها یا تنظیم وبسرور دسترسی کافی ندارید، مدیریت و پشتیبانی سرور باید با همین شواهد کار را آغاز کند؛ نه با تعویض تصادفی تنظیمات.
جمعبندی
برای تشخیص TTFB بالا، مسیر را از بیرون به داخل طی کنید: DNS، اتصال، TLS، فایل ثابت، PHP، دیتابیس و سرویسهای بیرونی. این ترتیب هم زمان عیبیابی را کوتاه میکند و هم جلوی تصمیمهای پرهزینهای را میگیرد که علت اصلی را دستنخورده باقی میگذارند.
برچسبها:
اشتراکگذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
وردپرس ۷.۰.۱ منتشر شد؛ ۳۱ باگ مهم برطرف شدند
۲۰ تیر ۱۴۰۵دیدگاهها (۰)
دیدگاههای تاییدشده و پاسخهای تیم نتآرام