ظرفیت‌سنجی فروشگاه اینترنتی به زبان ساده
رایج‌ترین سؤال پیش از خرید سرور این است: «چند کاربر هم‌زمان را تحمل می‌کند؟» این سؤال پاسخ عمومی ندارد، اما سؤال‌های بهتری هست که پاسخ دارند.
چرا «چند کاربر هم‌زمان» پاسخ عمومی ندارد
ظرفیت یک سرور به قالب سایت، تعداد و کیفیت افزونه‌ها، حجم دیتابیس و مهم‌تر از همه نسبت صفحات قابل کش بستگی دارد. دو فروشگاه روی سخت‌افزار یکسان می‌توانند ظرفیت کاملاً متفاوتی داشته باشند.
هر عددی که بدون آزمون بار روی همان فروشگاه اعلام شود، حدس است. ما چنین عددی اعلام نمی‌کنیم.
سؤال‌هایی که پاسخ دارند
- در شلوغ‌ترین ساعت ماه گذشته، چند بازدید در دقیقه داشته‌ای؟
- در بزرگ‌ترین کمپین سال گذشته، این عدد چند برابر شد؟
- چه نسبتی از بازدیدها روی صفحات قابل کش بوده و چه نسبتی روی سبد و تسویه؟
- زمان پاسخ فعلی سنگین‌ترین صفحه چقدر است؟
- حجم فعلی دیتابیس چقدر است و ماهانه چقدر رشد می‌کند؟
با پاسخ همین پنج سؤال می‌شود کانفیگی پیشنهاد داد که برای پیک طراحی شده باشد، نه برای میانگین.
آمادگی برای کمپین
- تاریخ کمپین را از قبل به تیم زیرساخت اطلاع بده.
- پیش از کمپین، تنظیمات وب‌سرور و دیتابیس بازبینی شود.
- در بازهٔ کمپین، حساسیت مانیتورینگ بالاتر برود.
- تغییرات بزرگ روی سایت را به بعد از کمپین موکول کن.
- مسیر برگشت (rollback) برای هر تغییر مشخص باشد.
چقدر ظرفیت اضافه نگه داریم؟
طراحی برای «دقیقاً به اندازهٔ پیک» یعنی طراحی برای شکست، چون پیک واقعی همیشه با پیک پیش‌بینی‌شده فرق دارد و منابع هم به‌صورت خطی رفتار نمی‌کنند.
- سروری که در حالت عادی نزدیک سقف کار می‌کند، در پیک جای رشد ندارد — و بدتر، زمان پاسخش خیلی قبل از رسیدن به سقف بالا می‌رود.
- ظرفیت اضافه فقط برای ترافیک نیست. به‌روزرسانی، بازسازی ایندکس دیتابیس و بکاپ هم منابع می‌خواهند و معمولاً بدترین زمان اجرا می‌شوند.
- فضای دیسک بی‌سروصداترین سقف است: پر شدنش سرویس را می‌خواباند و لاگ‌ها را هم با خودش می‌برد.
بزرگ‌تر کردن یا بیشتر کردن؟
| راه | یعنی | مناسب وقتی |
|---|---|---|
| سرور بزرگ‌تر | همان معماری، با پردازنده، حافظه یا دیسک بیشتر. | اپلیکیشن برای اجرای تک‌ماشینی نوشته شده — که در بیشتر فروشگاه‌های آمادهٔ بازار همین‌طور است. ساده‌ترین و کم‌ریسک‌ترین راه. |
| چند سرور | جداکردن دیتابیس از وب، یا چند سرور وب پشت یک توزیع‌کنندهٔ بار. | وقتی یک ماشین دیگر جواب نمی‌دهد، یا وقتی نمی‌خواهی یک خرابی کل سرویس را بخواباند. |
ترتیب معمول این است: اول کش و کوئری‌ها را درست کن، بعد سرور را بزرگ‌تر کن، و تنها بعد از آن سراغ چندسروری برو. جهش زودهنگام به معماری چندسروری، پیچیدگی‌ای اضافه می‌کند که نگهداری‌اش خودش کار می‌برد.
بعد از کمپین هم کاری هست
کمپین بهترین دادهٔ ظرفیت‌سنجی سالت را تولید می‌کند و معمولاً کسی آن را برنمی‌دارد. در هفتهٔ بعدش:
- بیشترین مصرف پردازنده، حافظه و دیسک را در ساعت اوج یادداشت کن. این پایهٔ برنامه‌ریزی سال بعد است.
- ببین گلوگاه کجا بود — اگر بود. همان نقطه اولین چیزی است که تا کمپین بعدی باید درست شود.
- نسبت اصابت کش را در پیک با حالت عادی مقایسه کن.
- اگر ظرفیت را موقتاً بالا برده بودی، تصمیم بگیر برگردانی یا نه — و اگر برمی‌گردانی، قبل از فصل بعدی در تقویم بگذار که دوباره بالا برود.
مطالب مرتبط
این مطلب بخشی از راهنمای زیرساخت فروشگاه اینترنتی است.
