محتوای آموزشی وبلاگ نتآرام
دو فروشگاه با ده هزار محصول میتوانند نیاز کاملاً متفاوتی داشته باشند. یکی روزانه صد بازدید دارد و بیشتر صفحاتش از کش تحویل داده میشود؛ دیگری در یک کمپین چند صد کاربر همزمان، جستوجوی فیلترشده و پرداخت فعال دارد. اگر فقط از روی «تعداد محصول» یا «فضای لازم» هاست بخریم، ظرفیت واقعی فروشگاه را نمیسنجیم.
این راهنما یک ماشینحساب قطعی نیست؛ چکلیستی است برای اینکه پیش از انتخاب هاست ووکامرس سؤالهای درست را بپرسید و بعد از راهاندازی نیز بدانید چه چیزی را پایش کنید.
چهار نوع درخواست را از هم جدا کنید
تمام بازدیدهای ووکامرس هزینهٔ یکسانی ندارند:
- صفحهٔ کششده: معمولاً با دخالت کم PHP و دیتابیس پاسخ داده میشود.
- جستوجو و فیلتر محصول: ممکن است چندین کوئری روی ویژگیها و متادیتا اجرا کند.
- سبد خرید و تسویهحساب: به سشن وابسته است و غالباً نباید از کش عمومی تحویل داده شود.
- درخواست مدیریتی و پسزمینه: همگامسازی موجودی، ساخت تصویر، خروجی حسابداری، وبهوک و Cron.
یک فروشگاه با بازدید زیاد اما نسبت بالای صفحات کششده شاید سبکتر از فروشگاهی با بازدید کمتر و فیلترهای پیچیده باشد. بنابراین نرخ «درخواست پویا در ثانیه» و زمان اجرای آن از عدد بازدید روزانه دقیقتر است.
کاربران همزمان را تخمین بزنید
بازدید ماهانه را مستقیم به RAM تبدیل نکنید. ابتدا بازهٔ شلوغ را پیدا کنید. فرض کنید در شلوغترین ده دقیقه، ۶۰۰ نفر وارد سایت میشوند. اگر هر نفر در آن بازه چهار صفحهٔ پویا ببیند، حدود ۲۴۰۰ درخواست پویا یا بهطور میانگین چهار درخواست در ثانیه دارید. میانگین کافی نیست؛ قلههای کوتاه ناشی از تبلیغ، پیامک یا موجودشدن محصول مهمترند.
برای تخمین اولیه این موارد را یادداشت کنید:
| شاخص | چرا مهم است؟ |
| --- | --- |
| کاربران همزمان در اوج | میزان همزمانی PHP Workerها را نشان میدهد |
| درصد صفحات بدون کش | بار واقعی روی PHP و دیتابیس را روشن میکند |
| زمان متوسط درخواست پویا | تعیین میکند هر Worker چه مدت اشغال میماند |
| سفارش در دقیقه | فشار مسیر سبد و پرداخت را مشخص میکند |
| کارهای پسزمینه | ممکن است منابع مشتریان را با پردازش مدیریتی رقابت دهد |
CPU را فقط با تعداد هسته نسنجید
در ووکامرس، سرعت تکهسته برای بسیاری از درخواستهای PHP مهم است؛ در مقابل، تعداد هسته در مدیریت چند درخواست همزمان کمک میکند. عبارت «۸ هسته» بدون دانستن سهم واقعی، محدودیت پردازنده و نسل CPU اطلاعات کاملی نمیدهد.
نشانهٔ کمبود ظرفیت CPU این نیست که همیشه عدد ۱۰۰ درصد ببینید. صف PHP، افزایش زمان پاسخ در ساعت شلوغ و بازگشت سریع سرعت بعد از پایان کمپین نشانههای دقیقتری هستند. اگر یک افزونه درخواست طولانی میسازد، ابتدا همان مسیر را اصلاح کنید؛ هستهٔ بیشتر جای کد ناکارآمد را نمیگیرد.
RAM کجا مصرف میشود؟
حافظه میان PHP Workerها، دیتابیس، Object Cache و سرویسهای وب تقسیم میشود. تنظیم بیشازحد Worker بدون RAM کافی باعث Swap یا خاتمهٔ پردازشها میشود؛ تنظیم خیلی کم نیز درخواستها را در صف نگه میدارد.
برای فروشگاه، Redis میتواند فشار خواندن دادههای تکراری را کم کند، اما جایگزین کوئری درست و دیتابیس سالم نیست. همچنین کش بیشازحد و بدون سیاست پاکسازی، حافظه را اشغال میکند و گاهی دادهٔ قدیمی نشان میدهد. منابع باید براساس مشاهده تنظیم شوند، نه نسخهای ثابت برای همهٔ سایتها.
فضای دیسک با عملکرد دیسک فرق دارد
داشتن ۵۰ گیگابایت فضای خالی دربارهٔ latency یا IOPS چیزی نمیگوید. ووکامرس همزمان فایلهای کوچک، لاگ، Session و جدولهای دیتابیس را میخواند و مینویسد. NVMe در بارهای I/O محور مفید است، اما اگر گلوگاه API پرداخت یا کد PHP باشد، سریعترین دیسک هم آن انتظار را حذف نمیکند.
هنگام برآورد فضا اینها را جدا حساب کنید:
- تصاویر اصلی و نسخههای بندانگشتی؛
- بکاپهای موقت و بستههای مهاجرت؛
- رشد دیتابیس سفارشها و لاگها؛
- فضای لازم برای بهروزرسانی و استخراج فایل؛
- حاشیهٔ امن، تا پرشدن دیسک سرویس را متوقف نکند.
بکاپ دائمی را داخل همان فضای هاست نگه ندارید؛ دربارهٔ نسخهٔ مستقل در ادامه توضیح میدهیم.
کارهای پسزمینه را زمانبندی کنید
ساخت فید محصولات، همگامسازی انبار، ارسال انبوه پیام و تولید گزارش میتواند همان منابعی را مصرف کند که مشتری هنگام پرداخت لازم دارد. اگر این کارها در ساعت اوج اجرا شوند، تجربهٔ خرید آسیب میبیند حتی اگر میانگین مصرف روزانه پایین باشد.
Cron واقعی سرور، صفبندی کارها و تقسیم عملیات بزرگ به Batchهای کوچک باعث میشود بار قابل پیشبینیتر شود. برای یک کمپین، زمان ارسال پیامک را با ظرفیت سایت هماهنگ کنید؛ هزاران کلیک همزمان یک مسئلهٔ زیرساختی است، نه صرفاً بازاریابی.
امنیت و پایداری بخشی از ظرفیتاند
حملهٔ رباتها، تلاش ورود و خزش بیقاعده میتواند Workerها را پیش از مشتری واقعی اشغال کند. WAF، Rate Limit متناسب، محافظت صفحهٔ ورود و بهروزرسانی منظم بخشی از طراحی ظرفیت است. محدودیت کورکورانه نیز درست نیست؛ نباید درگاه پرداخت یا وبهوک معتبر را مسدود کند.
برای سایتهای حساس، محیط آزمایشی و بکاپ قابل بازیابی از چند گیگابایت RAM اضافی ارزشمندتر است. ارتقایی که راه بازگشت ندارد، ریسک کسبوکار را کم نمیکند.
قبل از خرید این اطلاعات را آماده کنید
- بازدید روزانه و اوج دهدقیقهای؛
- تعداد سفارش روزانه و اوج سفارش در دقیقه؛
- حجم فعلی فایل و دیتابیس و رشد سهماهه؛
- فهرست افزونههای پرداخت، پیامک، حسابداری و جستوجو؛
- کش فعلی و صفحاتی که نباید کش شوند؛
- برنامهٔ کمپینها و جهش احتمالی ورودی؛
- نیاز به بکاپ ساعتی، روزانه یا نقطهٔ بازیابی نزدیکتر.
اگر هنوز دادهٔ واقعی ندارید، با ظرفیت منطقی شروع کنید اما از روز نخست نمودار و لاگ داشته باشید. هاست وردپرس برای سایت محتوایی و فروشگاه سبک میتواند کافی باشد؛ فروشگاهی که همزمانی و عملیات پسزمینهٔ بیشتری دارد باید روی طرحی قرار گیرد که منابع و رفتار آن متناسب با ووکامرس باشد.
آزمون قبل از کمپین
آزمون بار را ناگهانی روی سایت زنده اجرا نکنید. ابتدا با تیم میزبانی هماهنگ شوید، سناریویی شبیه رفتار واقعی بسازید و از محیط آزمایشی استفاده کنید. فقط صفحهٔ اصلی را هدف نگیرید؛ جستوجو، افزودن به سبد و مرحلهٔ قبل از اتصال به بانک را نیز بسنجید، بدون آنکه سفارش یا پرداخت جعلی ایجاد شود.
نتیجهٔ خوب یعنی علاوه بر زمان پاسخ مناسب، نرخ خطا پایین بماند و پس از پایان بار، صفها سریع تخلیه شوند. نمودار CPU بدون نرخ خطا و latency تصویر کاملی نمیدهد.
جمعبندی
انتخاب هاست ووکامرس با تعداد محصول یا فضای دیسک انجام نمیشود. همزمانی، سهم درخواستهای بدون کش، زمان اجرای PHP، الگوی دیتابیس، کارهای پسزمینه و جهش کمپین را کنار هم ببینید. وقتی این عددها معلوم باشند، هم انتخاب اولیه دقیقتر میشود و هم میدانید چه زمانی بهینهسازی کافی است و چه زمانی ارتقا واقعاً لازم شده است.
اشتراکگذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
TTFB بالا از هاست است یا وردپرس؟ یک روش تشخیص بدون حدس
۳۰ شهریور ۱۴۰۵دیدگاهها (۰)
دیدگاههای تاییدشده و پاسخهای تیم نتآرام