وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

محدودیت پردازش هم‌زمان هاست چیست و چطور فشار آن را کم کنیم؟

آموزش فهم نمودار Entry Processes و Faults در هاست و کم کردن فشار درخواست‌های هم‌زمان بدون حذف اطلاعات سایت.

انتشار:
توسط تیم فنی نت‌آرام
۴ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله محدودیت پردازش هم‌زمان هاست چیست و چطور فشار آن را کم کنیم؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
هر بار که یک صفحه پویا در سایت باز می‌شود، سرور باید برای پاسخ به آن کاری انجام دهد. Entry Processes در برخی سرویس‌های میزبانی به تعداد درخواست‌هایی مربوط است که هم‌زمان در حال ورود و پردازش برای حساب هستند. وقتی درخواست‌ها روی هم جمع شوند و به سقف برسند، درخواست تازه ممکن است با خطا روبه‌رو شود. این عدد با تعداد کل بازدیدکنندگان روزانه یکی نیست.

یک مثال ساده

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

عدد مربوط به زمان خطا را پیدا کنید

در برخی هاست‌ها از cPanel به بخش Resource Usage بروید و بازه‌ای را انتخاب کنید که کاربر خطا دیده است. نام بخش و امکانات آن بسته به میزبان متفاوت است. در نمودار به Entry Processes و تعداد Faults نگاه کنید. اگر هم‌زمان با خطا چند بار به سقف رسیده‌اید، از نمودار تصویر بگیرید. پر شدن CPU یا حافظه هم می‌تواند در کند شدن درخواست‌ها نقش داشته باشد؛ یک عدد را جدا از بقیه تفسیر نکنید.
اگر این بخش را ندارید از پشتیبانی بخواهید گزارش همان بازه، نام محدودیت و تعداد خطاها را بگوید. ساعت، منطقه زمانی و آدرس صفحه مشکل‌دار را همراه درخواست بفرستید.

کدام درخواست‌ها زیاد یا طولانی‌اند؟

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

از کجا بفهمیم کدام مسیر را سبک کنیم؟

در سی‌پنل، اگر بخش Metrics → Raw Access در سرویس شما فعال است، گزارش همان دامنه و بازه خطا را دریافت کنید. زمان و مسیرهای پرتکرار را با نمودار Faults مقایسه کنید؛ برای نمونه اگر مسیر جست‌وجو هم‌زمان هزاران بار درخواست شده، در نسخه آزمایشی افزونه ایجادکننده درخواست را تنظیم و فاصله فراخوانی را بیشتر کنید. سپس در زمان مشابه نمودار Entry Processes و زمان پاسخ همان صفحه را ببینید. اگر به گزارش دسترسی ندارید، نام دامنه، بازه زمانی و مسیر مشکوک را بدهید و تعداد درخواست‌ها و مدت اجرای آن مسیر را از میزبان بخواهید.

چند راه‌حل عملی

۱. کش صفحه‌های عمومی را در افزونه معتبر و طبق راهنمای آن فعال کنید. صفحه حساب، سبد و پرداخت نباید کش عمومی شوند. سپس از دو نشست جدا امتحان کنید اطلاعات کاربران قاطی نشود.
۲. زمان پشتیبان‌گیری و کارهای برنامه‌ریزی‌شده سنگین را به ساعت خلوت ببرید. اگر ابزار شما امکان اجرای مرحله‌ای دارد، حجم هر مرحله را کمتر کنید.
۳. در نسخه آزمایشی، افزونه‌ای را که اخیراً نصب شده یک‌بار غیرفعال کنید و همان صفحه را بسنجید. بعد از آزمون وضعیت آن را به حالت لازم برگردانید. حذف دسته‌جمعی افزونه‌ها دلیل واقعی را مبهم می‌کند.
۴. اگر ترافیک غیرعادی به مسیر مشخصی می‌رسد، از امکانات محدودسازی مناسب همان مسیر استفاده کنید یا از پشتیبانی کمک بگیرید. قطع دسترسی همه بازدیدکنندگان یا موتورهای جست‌وجو راه‌حل مناسبی نیست.
پس از هر تغییر، نمودار همان منابع و تجربه کاربر را دوباره بررسی کنید. اگر با وجود رفع کندی، مصرف واقعی سایت به‌طور مداوم به سقف می‌رسد، سرویس با منابع بیشتر می‌تواند مناسب باشد. انتخاب را بر اساس گزارش مصرف انجام دهید، نه صرفاً یک خطای گذرا.
اگر فروشگاه شما رشد کرده است، می‌توانید مشخصات هاست فروشگاهی پربازدید را با مصرف واقعی خود مقایسه کنید و پیش از جابه‌جایی درباره محدودیت‌های پلن از پشتیبانی بپرسید.
اشتراک‌گذاری:
لینکدینتلگرامایکس

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام