محتوای آموزشی وبلاگ نت‌آرام
وقتی سایت دیر باز می‌شود، ممکن است مشکل از خود برنامه، سرور یا مسیری باشد که درخواست از اینترنت طی می‌کند. یک پینگ خوب یا بد برای تصمیم‌گیری کافی نیست. در این راهنما با چند آزمایش ساده مشخص می‌کنیم چه شواهدی جمع کنیم تا به جای حدس، علت را محدود کنیم.
یک صفحه مشخص و یک زمان مشخص انتخاب کنید
یک نشانی عمومی را انتخاب کنید که همه بتوانند باز کنند؛ مثلاً صفحه اصلی یا یک فایل کوچک ثابت در سایت. آن را هم‌زمان از اینترنت خانگی و اینترنت تلفن همراه امتحان کنید. ساعت، اپراتور و نتیجه هر آزمایش را بنویسید. اگر فقط یک شبکه کند است، مسیر ارتباط آن شبکه یکی از احتمال‌هاست؛ هنوز نمی‌توان گفت کدام شرکت یا دستگاه مقصر است.
اگر فقط پیشخوان یا صفحه پرداخت کند است و فایل ثابت سریع باز می‌شود، ممکن است اجرای برنامه، پایگاه داده یا سرویس بیرونی همان صفحه زمان ببرد. اگر فایل ثابت و همه صفحات کندند، بررسی شبکه و منابع سرور اهمیت بیشتری پیدا می‌کند.
زمان هر بخش درخواست را ببینید
در ترمینال لینوکس یا macOS این دستور را با نشانی سایت خودتان اجرا کنید:
کد / دستورcurl -L -s -o /dev/null -w 'DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n' https://example.com/
مقادیر از شروع درخواست اندازه‌گیری می‌شوند؛ بنابراین برای به‌دست آوردن زمان هر مرحله نباید همه اعداد را با هم جمع کنید. زمان اولین پاسخ فقط زمان اجرای برنامه نیست و مرحله‌های قبلی شبکه و TLS را هم در بر می‌گیرد. اگر چند تغییر مسیر وجود دارد، اعداد جمع برخی مراحل را منعکس می‌کنند. برای تفسیر دقیق‌تر ابتدا نشانی نهایی را جداگانه آزمایش کنید.
برای اینکه اعداد ملموس‌تر شوند، فرض کنید زمان اتصال
0.10 و زمان دریافت نخستین بایت 2.10 ثانیه است. در این نمونه حدود دو ثانیه بین برقراری اتصال و دریافت نخستین بایت گذشته است؛ این فاصله می‌تواند شامل TLS و انتظار برای پاسخ سایت هم باشد. حالا همان دستور را برای فایل ثابت و صفحه کند اجرا کنید. اگر فایل ثابت سریع است و صفحه کند چند ثانیه منتظر می‌ماند، نمونه‌ها را برای بررسی برنامه و گزارش خطا به میزبان بدهید. اگر هر دو فقط در یک شبکه کند هستند، نتیجه همان شبکه و یک شبکه دیگر را کنار هم بفرستید. این مقایسه محل احتمالی مشکل را محدود می‌کند، اما علت قطعی نیست.وضعیت خود سرور را هم‌زمان ببینید
اگر مدیر VPS هستید، در همان دقیقه از کنسول یا SSH این دستورها را اجرا کنید:
کد / دستورuptime
free -h
df -h
این‌ها بار کلی، حافظه و فضای فایل‌سیستم را نشان می‌دهند؛ هیچ‌کدام به تنهایی دلیل کندی را ثابت نمی‌کنند. اگر در زمان خطا حافظه یا دیسک پر است، گزارش فرایندها و برنامه را بررسی کنید. اگر سرور آرام است ولی فقط یک مسیر شبکه مشکل دارد، نتایج دو شبکه و زمان دقیق را به پشتیبانی بدهید.
برای دیدن اینکه در همان لحظه کدام برنامه CPU بیشتری مصرف می‌کند، دستور زیر را اجرا کنید:
کد / دستورtop
در صفحه‌ای که باز می‌شود ستون
%CPU و نام برنامه را بخوانید. با زدن کلید q از آن خارج شوید؛ خود این دستور برنامه‌ای را متوقف نمی‌کند. از همان لحظه نام چند فرایند بالای فهرست و ساعت را یادداشت کنید. یک عدد لحظه‌ای به‌تنهایی برای خاموش‌کردن برنامه کافی نیست؛ اگر چند بار تکرار شد، آن را همراه نشانی صفحه کند به مدیر سرور بدهید.در خروجی
df -h، ستون Use% درصد فضای مصرف‌شده هر فایل‌سیستم است. اگر فایل‌سیستم محل سایت تقریباً پر شده، فایل‌ها و بکاپ‌ها را کورکورانه حذف نکنید. از مدیر سرور بخواهید پوشه‌های بزرگ را شناسایی و فایل‌های قابل حذف را مشخص کند. در خروجی free -h هم ستون available تخمینی از حافظه قابل استفاده است؛ عدد کمِ free به تنهایی دلیل کمبود حافظه نیست، چون سیستم از حافظه برای کش استفاده می‌کند.گزارش قابل استفاده بفرستید
نشانی، ساعت و منطقه زمانی، نتیجه هر شبکه، خروجی زمان‌بندی و اینکه فایل ثابت چگونه باز می‌شود را کنار هم بگذارید. از چند نقطه و در چند زمان نمونه بگیرید، نه صدها درخواست پشت سر هم. اگر از CDN استفاده می‌کنید، مشخص کنید نتیجه مربوط به CDN است یا آزمایش مستقیم سرور؛ پاسخ CDN لزوماً وضعیت سرور اصلی را نشان نمی‌دهد.
برای انتخاب محل میزبانی هم به تجربه کاربران واقعی، نوع برنامه و منابع مورد نیاز با هم نگاه کنید. در صفحه سرور مجازی ایران می‌توانید مشخصات سرویس‌ها را با نیاز خود مقایسه کنید.
منبع: مستندات رسمی.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام