پاسخ کوتاه
Node.js برای I/O هم‌زمان کارآمد است؛ انتخاب سرور به CPU هر Request، حافظه Heap، Connection و سرویس‌های جانبی وابسته است.
یک Process JavaScript معمولاً یک Event loop اصلی دارد. برای استفاده از چند Core می‌توان چند Process اجرا کرد، اما بار CPU-bound شاید به Worker thread یا سرویس جدا نیاز داشته باشد.
چرا یک عدد ثابت جواب نمی‌دهد؟
دو برنامه با تعداد کاربر برابر می‌توانند منابع کاملاً متفاوتی بخواهند. Cache، تعداد Request هم‌زمان، Query، اندازه پاسخ، Job پس‌زمینه و درصد نوشتن در دیتابیس روی مصرف اثر می‌گذارند. بنابراین «بازدید ماهانه» یا نام Framework به‌تنهایی ورودی خوبی برای خرید نیست.
هدف باید تجربه کاربر و پایداری باشد: p95 زمان پاسخ، نرخ خطا، زمان Queue، ظرفیت Connection و زمان بازیابی. منابع وسیله رسیدن به این هدف‌اند، نه خود هدف.
بار کاری خود را توصیف کنید
یک روز عادی و یک ساعت پیک را جدا بنویسید. تعداد Request، کاربر هم‌زمان، حجم و رشد داده، نسبت خواندن به نوشتن، Jobهای زمان‌بندی‌شده و Dependencyهای خارجی را مشخص کنید. همچنین معلوم کنید چه مقدار قطعی قابل قبول است.
اگر سرویس موجود دارید، حدس نزنید؛ حداقل یک هفته متریک بگیرید. اگر پروژه جدید است، با سناریوی کوچک Load test و فرضیات صریح شروع کنید تا بعداً بتوانید آن‌ها را با داده واقعی جایگزین کنید.
منابع را چطور کنار هم ببینیم؟
CPU سریع برای کار تک‌رشته‌ای، Core بیشتر برای کار موازی، RAM برای Working set و Cache، دیسک کم‌تأخیر برای I/O و شبکه مناسب برای کاربر و Dependency لازم است. گلوگاه یکی از این‌ها می‌تواند بقیه منابع آزاد را بی‌اثر کند.
- 2 vCPU و 2–4 GB برای API سبک نقطه شروع است.
- Event-loop lag و Heap را پایش کنید.
- Connection pool دیتابیس را با تعداد Process هماهنگ کنید.
نقطه شروع و روش اندازه‌گیری
با autocannon یا ابزار مشابه سناریوی واقعی را تست و p95 latency، CPU، RSS و event-loop lag را اندازه بگیرید؛ سپس Process count را تنظیم کنید.
پلنی انتخاب کنید که Resize آن روشن و کم‌ریسک باشد. پس از راه‌اندازی، CPU هر Core، available memory و Swap، latency دیسک، Connectionها و p95 پاسخ را در پیک ثبت کنید. عدد شروع حکم نهایی نیست؛ یک فرض مهندسی قابل آزمون است.
Load test درست چه شکلی است؟
سناریو باید رفتار واقعی را تقلید کند: ترکیب Endpointها، Login، Cache warm/cold، خواندن و نوشتن و زمان فکر کاربر. افزایش بار را مرحله‌ای انجام دهید و نقطه‌ای را ثبت کنید که latency یا error به‌سرعت رشد می‌کند.
تست را روی Production فعال و بدون سقف اجرا نکنید. داده آزمایشی، محدودیت نرخ، پنجره مشخص و مانیتورینگ کامل لازم است. نتیجه باید علاوه بر حداکثر ظرفیت، حاشیه امن و رفتار زمان خرابی Dependency را نشان دهد.
هزینه واقعی و قابلیت اطمینان
قیمت پلن فقط بخشی از هزینه است. Backup، ترافیک خروجی، IP، License، مانیتورینگ، زمان نگهداری و هزینه قطعی را هم حساب کنید. گاهی دو سرور متوسط با Failover از یک سرور بسیار بزرگ ارزش عملیاتی بیشتری دارند.
همچنین دامنه خرابی را بشناسید. چند ماشین روی یک میزبان، چند دیسک در یک Array یا Backup در همان حساب ممکن است ظاهراً چند نسخه باشند اما از یک حادثه مشترک آسیب ببینند.
چه زمانی ارتقا یا مهاجرت کنیم؟
اگر در چند پیک متوالی CPU یا I/O اشباع، available memory کم، Swap فعال، Queue رو به رشد یا p95 خارج از هدف دارید و بهینه‌سازی واضحی باقی نمانده، ارتقا منطقی است. برای بار فصلی، مقیاس‌پذیری موقت ممکن است بهتر از خرید ظرفیت دائمی باشد.
پیش از مهاجرت، Benchmark مقصد، روش انتقال داده، زمان همگام‌سازی، TTL، Cutover و Rollback را آزمایش کنید. تصمیم ظرفیت بدون برنامه مهاجرت می‌تواند ریسک بیشتری از کمبود فعلی ایجاد کند.
اشتباه رایج
افزایش بی‌حساب PM2 instances می‌تواند Connection دیتابیس و حافظه را چند برابر و عملکرد را بدتر کند.
منابع بیشتر می‌توانند یک Query بد، Memory leak یا معماری تک‌نقطه‌ای را مدتی پنهان کنند؛ اما مشکل را حذف نمی‌کنند. هزینه را فقط وقتی بالا ببرید که داده نشان دهد گلوگاه واقعاً همان منبع است.
پرسش‌های مهمی که قبل از اقدام باید جواب دهید
برای اینکه پاسخ «برای Node.js چه سروری مناسب است؟» فقط در حد اطلاعات عمومی نماند، ابتدا وضعیت فعلی خود را با عدد توصیف کنید: نسخه سیستم‌عامل یا نرم‌افزار، تعداد کاربر هم‌زمان، مصرف معمول و اوج منابع، حجم و رشد داده، محدودیت شبکه و بیشترین قطعی قابل قبول. بدون این اطلاعات ممکن است توصیه‌ای که از نظر فنی درست است، برای محیط شما انتخاب مناسبی نباشد.
دو سؤال بعدی مستقیماً از نکات این موضوع می‌آیند: «2 vCPU و 2–4 GB برای API سبک نقطه شروع است.» در زیرساخت شما چگونه اندازه‌گیری یا تأیید می‌شود؟ و «Event-loop lag و Heap را پایش کنید.» چه اثری روی کاربر، هزینه یا مسیر بازیابی دارد؟ پاسخ را در قالب شواهدی مانند خروجی فرمان، نمودار متریک، نتیجه آزمون یا مستند ارائه‌دهنده ثبت کنید؛ اتکا به حافظه و حدس برای تصمیم عملیاتی کافی نیست.
یک برنامه عملی کم‌ریسک
کار را با ثبت وضعیت فعلی و یک معیار موفقیت آغاز کنید. سپس پیشنهاد اصلی این راهنما را در کوچک‌ترین محیط نماینده اجرا کنید: با autocannon یا ابزار مشابه سناریوی واقعی را تست و p95 latency، CPU، RSS و event-loop lag را اندازه بگیرید؛ سپس Process count را تنظیم کنید. نتیجه را در حالت عادی و در یک سناریوی خطا یا فشار کنترل‌شده بسنجید. اگر معیار بهتر نشد، به‌جای افزودن تغییرات بیشتر، فرض اولیه را بازبینی کنید.
پیش از اعمال تغییر در سرویس اصلی، روش بازگشت، مسئول تصمیم و زمان توقف را روشن کنید. این هشدار را نیز به‌عنوان شرط توقف در نظر بگیرید: افزایش بی‌حساب PM2 instances می‌تواند Connection دیتابیس و حافظه را چند برابر و عملکرد را بدتر کند. پس از اجرا، نتیجه، نسخه‌ها و تنظیمات مؤثر را مستند کنید و یک زمان بازبینی تعیین کنید؛ تغییر بدون پایش ممکن است امروز سالم به نظر برسد اما در پیک بعدی شکست بخورد.
- 2 vCPU و 2–4 GB برای API سبک نقطه شروع است.
- Event-loop lag و Heap را پایش کنید.
- Connection pool دیتابیس را با تعداد Process هماهنگ کنید.
جمع‌بندی و چک‌لیست خرید
برای پاسخ به «برای Node.js چه سروری مناسب است؟» این موارد را کنار هم بگذارید: بار عادی و پیک، معیار latency و خطا، CPU، RAM، I/O، شبکه، رشد داده، Backup، دامنه خرابی، امکان Resize و هزینه کل. با یک نقطه شروع منطقی آغاز کنید و زمان بازبینی را از همان روز اول تعیین کنید.
- 2 vCPU و 2–4 GB برای API سبک نقطه شروع است.
- Event-loop lag و Heap را پایش کنید.
- Connection pool دیتابیس را با تعداد Process هماهنگ کنید.