چگونه منابع سرور ابری را براساس تعداد کاربران همزمان تخمین بزنیم؟

منابع سرور ابری برای کاربران همزمان را نمی‌توان تنها با تعداد بازدیدکنندگان تعیین کرد. دو سایت با 1000 کاربر فعال ممکن است مصرف CPU ،RAM و شبکه کاملاً متفاوتی داشته باشند؛ زیرا رفتار کاربران، نوع درخواست‌ها و معماری برنامه یکسان نیست.

برای انتخاب منابع مناسب، باید تعداد کاربران را به بار پردازشی تبدیل کرد، مصرف بخش‌های مختلف سیستم را تخمین زد و نتیجه را با آزمون بار سنجید. این روش هم برای پروژه‌های تازه‌تأسیس کاربرد دارد و هم برای سرویس‌هایی که قصد افزایش ظرفیت دارند.

تخمین منابع سرور ابری براساس تعداد کاربران همزمان با شناخت رفتار کاربران و محاسبه نرخ درخواست در ثانیه یا RPS آغاز می‌شود. سپس میزان مصرف CPU ،RAM، دیسک، دیتابیس و شبکه براساس بار کاری تخمین زده می‌شود. تعداد کاربران آنلاین به‌تنهایی ظرفیت موردنیاز را مشخص نمی‌کند؛ زیرا همه کاربران دائماً درخواست ارسال نمی‌کنند. برای انتخاب پلن مناسب، باید برآورد ظرفیت با آزمون بار، معیارهای قبولی مشخص، داده‌های مانیتورینگ و پیش‌بینی رشد پروژه اعتبارسنجی شود.

کاربران هم زمان در سرور ابری به چه معناست؟

کاربران هم زمان (Concurrent Users) افرادی هستند که در یک بازه مشخص با سایت یا اپلیکیشن تعامل دارند. اما تعداد کاربران فعال با تعداد درخواست‌های در حال پردازش یکسان نیست.

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

سه شاخص مهم باید از یکدیگر تفکیک شوند:

شاخص	تعریف
Concurrent Users	تعداد کاربران فعال در بازه موردنظر
RPS	تعداد درخواست‌های ورودی به سیستم در هر ثانیه
In-flight Requests	تعداد درخواست‌های موجود در سیستم، شامل درخواست‌های منتظر و در حال پردازش

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

نحوه محاسبه منابع سرور ابری برای کاربران همزمان

مرحله اول: رفتار کاربران را مشخص کنید

ابتدا فعالیت‌های اصلی کاربران را شناسایی کنید؛ مانند مشاهده محصول، جست‌وجو، ورود به حساب، ثبت سفارش یا دریافت گزارش.

هر فعالیت ممکن است تعداد متفاوتی درخواست به Backend ایجاد کند. برای مثال، مشاهده یک صفحه کش‌شده معمولاً با اجرای یک گزارش پیچیده دیتابیس بار یکسانی ندارد.

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

مرحله دوم: نرخ درخواست یا RPS را محاسبه کنید

برای یک مدل ساده که هر کاربر در فاصله زمانی مشخص یک درخواست ارسال می‌کند:

RPS = تعداد کاربران هم زمان ÷ میانگین فاصله بین شروع دو درخواست متوالی هر کاربر، برحسب ثانیه

فرض کنید 600 کاربر فعال دارید و فاصله متوسط بین شروع دو درخواست متوالی هر کاربر 12 ثانیه است.

600 ÷ 12 = 50 درخواست در ثانیه

بنابراین نرخ تقریبی درخواست در این سناریو 50 RPS خواهد بود.

نکته مهم: منظور از 12 ثانیه، فاصله بین شروع دو درخواست است. اگر منظور 12 ثانیه مکث کاربر پس از دریافت پاسخ باشد، باید زمان پاسخ نیز به طول چرخه اضافه شود.

برای مثال، با 12 ثانیه مکث و 0/25 ثانیه زمان پاسخ، نرخ تقریبی در مدل بسته با یک درخواست در هر چرخه برابر است با:

600 ÷ 12/25 ≈ 49 درخواست در ثانیه

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

مرحله سوم: قانون لیتل را برای تخمین درخواست های موجود در سیستم به‌کار ببرید

قانون لیتل (Little’s Law) رابطه میان نرخ ورود درخواست‌ها، میانگین زمان حضور آن‌ها در سیستم و میانگین تعداد درخواست‌های موجود در سیستم را بیان می‌کند.

میانگین تعداد درخواست های موجود در سیستم، شامل درخواست‌های در صف و در حال پردازش = نرخ درخواست × میانگین زمان حضور درخواست در همان سیستم، برحسب ثانیه

اگر نرخ درخواست 50 RPS و میانگین زمان پاسخ در محدوده اندازه‌گیری‌شده 250 میلی‌ثانیه باشد:

50 × 0/25 = 12/5

یعنی به‌طور متوسط حدود 12 تا 13 درخواست در سیستم حضور دارند.

این رابطه برای شرایط پایدار و مرز یکسان اندازه‌گیری نرخ و زمان معتبر است. همچنین خروجی آن به‌تنهایی تعداد Worker های لازم یا ظرفیت موردنیاز برای جهش‌های ناگهانی ترافیک را مشخص نمی‌کند.

چگونه CPU موردنیاز سرور ابری را تخمین بزنیم؟

نیاز پردازشی بیشتر از آنکه به تعداد کاربران آنلاین وابسته باشد، به نرخ درخواست و میزان مصرف CPU هر درخواست بستگی دارد.

فرض کنید اندازه‌گیری‌ها نشان دهند هر درخواست به‌طور متوسط 20 میلی‌ثانیه زمان CPU نیاز دارد و سیستم باید 50 درخواست در ثانیه پردازش کند.

مجموع تقاضای پردازشی برابر است با:

50 × 20 میلی‌ثانیه = 1000 میلی‌ثانیه CPU در هر ثانیه

این مقدار معادل یک هسته کاملاً مشغول است؛ البته با فرض ثابت‌بودن ظرفیت پردازنده و نبود محدودیت‌های دیگر.

ازآنجاکه استفاده دائمی از تمام ظرفیت پردازنده فضای مناسبی برای نوسان بار باقی نمی‌گذارد، ممکن است دو vCPU نقطه شروع مناسبی برای آزمون این سناریوی فرضی باشد.

این مثال تضمین ظرفیت نیست. عملکرد واقعی به نوع پردازنده، معماری برنامه، محدودیت های مجازی سازی و بارهای جانبی بستگی دارد.

تفاوت ظرفیت واقعی و مجازی پردازنده در مقاله تفاوت vCPU و CPU Core بررسی شده است.

چگونه RAM موردنیاز سرور را محاسبه کنیم؟

فرمول ثابتی مانند «یک گیگابایت رم به‌ازای هر 100 کاربر» مبنای فنی قابل‌اتکایی ندارد.

مصرف حافظه از ترکیب سیستم عامل، فرایندهای برنامه، Worker ها، کش، اتصال‌ها و سایر سرویس‌ها به‌دست می‌آید.

برای مثال، اگر برنامه در حالت پایه 1/2 گیگابایت حافظه مصرف کند و هشت Worker هرکدام حدود 100 مگابایت حافظه اضافی و مستقل نیاز داشته باشند، مصرف اولیه نزدیک به 2 گیگابایت خواهد بود.

این عدد هنوز شامل تمام سرویس‌ها، فضای احتیاطی و رشد حافظه نیست. همچنین حافظه مشترک بین فرایندها نباید چند بار محاسبه شود.

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

ظرفیت دیسک و پهنای باند چگونه تخمین زده می‌شوند؟

ظرفیت و عملکرد ذخیره سازی

برای انتخاب فضای ذخیره سازی، فقط IOPS و سرعت دیسک اهمیت ندارند. باید حجم اولیه داده، رشد ماهانه، مدت نگهداری لاگ‌ها و محل ذخیره نسخه‌های پشتیبان نیز بررسی شوند.

برای مثال، اگر داده اولیه 80 گیگابایت باشد و ماهانه 12 گیگابایت افزایش پیدا کند، پس از شش ماه حجم داده به حدود 152 گیگابایت خواهد رسید؛ بدون احتساب لاگ‌ها، بکاپ‌ها و فضای احتیاطی.

عملکرد دیسک نیز جداگانه با شاخص‌هایی مانند IOPS، نرخ خواندن و نوشتن و تأخیر ذخیره سازی سنجیده می‌شود. فضای بیشتر الزاماً به معنی عملکرد سریع‌تر نیست.

پهنای باند شبکه

اگر سرور در هر ثانیه 50 پاسخ با میانگین حجم 100 کیلوبایت ارسال کند، نرخ خروجی داده حدود 40 مگابیت‌برثانیه خواهد بود.

این مقدار سربار پروتکل‌ها، ترافیک ورودی و افزایش ناگهانی درخواست‌ها را شامل نمی‌شود.

همچنین باید مشخص شود کدام داده‌ها از سرور اصلی و کدام از CDN یا سرویس ذخیره سازی ارائه می‌شوند.

اگر برآورد ظرفیت یا آزمون بار نشان دهد محدودیت اصلی در انتقال داده است، بررسی Network Optimized Server منطقی خواهد بود.

جدول معیارهای انتخاب منابع سرور ابری

 

منبع	معیار اندازه‌گیری	نشانه نیاز به بررسی
CPU	زمان CPU هر درخواست و نرخ درخواست	اشباع پردازنده و افزایش صف
RAM	مصرف واقعی حافظه و Workerها	OOM، کمبود حافظه یا Swap غیرعادی
دیسک	حجم داده، رشد ماهانه، IOPS و تأخیر	کمبود ظرفیت یا افزایش تأخیر
شبکه	Throughput و حجم داده انتقالی	نزدیک‌شدن به محدودیت شبکه
دیتابیس	زمان Query و اتصال‌های فعال	Query کند، قفل و انتظار اتصال

این شاخص‌ها باید کنار یکدیگر بررسی شوند. بالا بودن مصرف یک منبع الزاماً ثابت نمی‌کند که افزایش همان منبع بهترین راه‌حل است.

چگونه با آزمون بار منابع سرور را اعتبارسنجی کنیم؟

آزمون بار (Load Testing) برای مقایسه تخمین اولیه با رفتار واقعی برنامه استفاده می‌شود.

ابزارهایی مانند k6 یا JMeter امکان اجرای سناریوهای شبیه‌سازی‌شده را فراهم می‌کنند. اما روش تولید بار باید با هدف آزمون هماهنگ باشد.

 

 

تفاوت آزمون با کاربران ثابت و نرخ ورود ثابت

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

اگر سرور کند شود، چرخه فعالیت طولانی‌تر خواهد شد و نرخ درخواست تولیدشده ممکن است کاهش پیدا کند. بنابراین تعداد کاربر مجازی ثابت، معادل RPS ثابت نیست.

در مدل Open، شروع تکرارهای جدید براساس نرخ ازپیش‌تعیین‌شده انجام می‌شود و مستقیماً به پایان تکرار قبلی وابسته نیست.

برای ارزیابی ظرفیت در برابر نرخ ورود مشخص، می‌توان از سناریوهای Arrival Rate در مستندات Grafana k6 استفاده کرد.

البته اگر هر تکرار شامل چند درخواست HTTP باشد، نرخ تکرارها با نرخ درخواست‌ها برابر نخواهد بود. بنابراین RPS واقعی باید جداگانه اندازه‌گیری شود.

معیار قبولی آزمون را پیش از اجرا مشخص کنید

صرف ثبت P95 ،P99 و نرخ خطا کافی نیست. باید از ابتدا تعیین شود چه سطحی از عملکرد برای سرویس قابل‌قبول است.

برای مثال، یک پروژه ممکن است هدف آزمایشی زیر را تعریف کند:

• زمان پاسخ P95 کمتر از 800 میلی‌ثانیه
• زمان پاسخ P99 کمتر از 1500 میلی‌ثانیه
• نرخ خطای درخواست‌ها کمتر از یک درصد
• موفقیت عملیات مهم مانند ثبت سفارش
• نبود Timeout یا خطای اتصال فراتر از حد مجاز

این اعداد صرفاً نمونه‌اند و استاندارد عمومی برای تمام برنامه‌ها نیستند.

نکته دیگر اینکه دریافت HTTP 200 الزاماً به معنی موفقیت عملیات کاربردی نیست. ممکن است پاسخ موفق باشد، اما سفارش ثبت نشده یا داده نادرستی برگردانده شده باشد.

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

چه زمانی افزایش منابع سرور ضروری است؟

اگر آزمون بار نشان دهد CPU اشباع شده و صف درخواست‌ها افزایش یافته، ارتقای پردازنده ارزش بررسی دارد. اگر کمبود حافظه رخ دهد، مصرف RAM و تعداد فرایندها باید تحلیل شود.

 

 

اما در صورت وجود Queryهای ناکارآمد، محدودیت Connection Pool یا کندی سرویس بیرونی، افزایش CPU و RAM اپلیکیشن الزاماً مشکل را حل نمی‌کند.

همچنین ممکن است به‌جای افزایش منابع یک سرور، توزیع بار میان چند نمونه مناسب‌تر باشد. انتخاب بین این رویکردها در مقاله مقیاس پذیری افقی و عمودی بررسی شده است.

چه زمانی این روش ظرفیت سنجی مناسب نیست؟

مدل ساده کاربران و RPS برای وب‌سایت، فروشگاه و APIهای معمولی کاربرد دارد؛ اما برای پردازش ویدئو، سیستم های WebSocket، وظایف پس‌زمینه یا پردازش‌های غیرهم‌زمان، باید مدل بار اختصاصی طراحی شود.

در چنین پروژه‌هایی ممکن است تعداد اتصال‌های باز، حجم پیام‌ها، طول صف وظایف یا زمان پردازش هر Job مهم‌تر از تعداد کاربران آنلاین باشد.

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

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

اگر برای راه اندازی سایت، API، فروشگاه اینترنتی یا نرم افزار سازمانی به سرور ابری نیاز دارید، پیش از خرید بهتر است تعداد کاربران همزمان، نرخ درخواست، مصرف CPU و RAM، رشد اطلاعات، نیاز شبکه و سطح عملکرد مورد انتظار را بررسی کنید.

ویراک کلود با ارائه سرور ابری، پلن‌های متنوع منابع، محاسبه ساعتی هزینه، دیتابیس ابری و امکانات شبکه، به تیم‌های فنی امکان می‌دهد زیرساخت متناسب با نیاز پروژه را انتخاب کنند. اگر هنوز نمی‌دانید چه میزان CPU ،RAM یا پهنای باند برای کاربران و بار کاری مجموعه شما مناسب است، برای تماس با ویراک کلود کلیک کنید تا نیازهای فنی پروژه را با کارشناسان مجموعه بررسی کنید.

سؤالات متداول

منابع سرور ابری برای کاربران همزمان چگونه محاسبه می‌شود؟

ابتدا رفتار کاربران به نرخ درخواست در ثانیه تبدیل می‌شود. سپس مصرف CPU ،RAM، دیسک، دیتابیس و شبکه براساس بار کاری تخمین زده شده و با آزمون بار و معیارهای قبولی مشخص اعتبارسنجی می‌شود.

برای 1000 کاربر همزمان چند هسته CPU لازم است؟

عدد ثابتی وجود ندارد. تعداد vCPU به نرخ درخواست، زمان پردازش هر درخواست و ظرفیت واقعی پردازنده بستگی دارد. تعیین مقدار مناسب به برآورد ظرفیت و آزمون بار نیاز دارد.

برای 500 کاربر همزمان چقدر RAM نیاز داریم؟

مقدار RAM به معماری برنامه، تعداد Workerها، کش، دیتابیس و مصرف حافظه هر فرایند وابسته است. تعداد کاربران به‌تنهایی برای تعیین مقدار حافظه کافی نیست.

تفاوت Concurrent Users و RPS چیست؟

Concurrent Users تعداد کاربران فعال را نشان می‌دهد؛ اما RPS تعداد درخواست‌های ورودی در هر ثانیه است. تعداد کاربران مجازی ثابت در آزمون بار نیز الزاماً به معنی تولید نرخ درخواست ثابت نیست.

آیا افزایش CPU و RAM همیشه ظرفیت سرور را افزایش می‌دهد؟

خیر. افزایش منابع زمانی مفید است که محدودیت اصلی به همان منابع مربوط باشد. مشکلات دیتابیس، شبکه، دیسک یا معماری برنامه ممکن است با ارتقای CPU و RAM برطرف نشوند.

چگونه بفهمیم سرور ابری به ارتقای منابع نیاز دارد؟

افزایش زمان پاسخ، اشباع منابع، خطاهای اتصال و طولانی‌شدن صف‌ها نشانه‌هایی برای بررسی هستند. تصمیم نهایی باید با تحلیل گلوگاه، آزمون بار و اهداف عملکردی اتخاذ شود.

بهترین روش تست ظرفیت سرور ابری چیست؟

اجرای آزمون با سناریوهای واقعی کاربر و در صورت نیاز نرخ ورود مشخص، همراه با اندازه‌گیری P95 ،P99، نرخ خطا، Timeout، صحت عملیات و مصرف منابع. معیار قبولی باید قبل از آزمون تعریف شود.