انتخاب سرور برای یک پروژه Next.js فقط به تعداد صفحات یا میزان بازدید سایت بستگی ندارد. ممکن است یک پروژه در زمان اجرای عادی به حافظه زیادی نیاز نداشته باشد، اما هنگام اجرای دستور next build با خطای کمبود حافظه متوقف شود. حالت برعکس هم ممکن است؛ یعنی Build بدون مشکل انجام شود، اما با افزایش تعداد کاربران هم زمان، مصرف RAM سرور بالا برود.

البته این اعداد حداقل رسمی اعلام شده توسط Next.js نیستند و باید با توجه به معماری برنامه، روش رندر صفحات، وابستگی ها و تعداد درخواست های هم زمان بررسی شوند. نکته مهم این است که حافظه مورد نیاز برای Build را با RAM لازم برای اجرای سایت یکی در نظر نگیریم.

حداقل رم مورد نیاز Next.js چقدر است؟

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

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

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

این اعداد برای انتخاب اولیه پلن هستند، نه تضمین عملکرد پروژه. اگر دیتابیس، Redis، سرویس API یا چند برنامه Node.js نیز روی همان ماشین اجرا می شوند، باید مصرف حافظه تمام این سرویس ها را در محاسبات وارد کنید.

یک نکته مهم دیگر اینکه برای سایت هایی که کاملاً به صورت Static Export خروجی گرفته می شوند، الزاماً نیازی به اجرای سرور Node.js در محیط میزبانی نیست. Next.js می تواند فایل های HTML، CSS و JavaScript را تولید کند و آنها را روی یک وب سرور معمولی یا سرویس میزبانی استاتیک قرار دهید. البته در این حالت، قابلیت هایی مانند SSR و ISR که به سرور نیاز دارند قابل استفاده نخواهند بود.

تفاوت مصرف رم در زمان Build و اجرای Next.js چیست؟

این دو مرحله مهم ترین عامل در تخمین منابع مورد نیاز یک پروژه هستند.

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

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

تفاوت این دو مرحله را در جدول زیر می بینید:

برای مثال، ممکن است یک سایت محتوایی هنگام تولید تعداد زیادی صفحه در زمان Build به 4 گیگابایت RAM نیاز داشته باشد، اما پس از استقرار نسخه Production با 2 گیگابایت حافظه به خوبی اجرا شود.

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

به همین دلیل بهتر است در پروژه های بزرگ، فرآیند Build روی یک محیط جداگانه مانند CI/CD انجام شود و فقط خروجی نهایی در محیط Production مستقر شود.

تأثیر SSR، SSG و ISR بر مصرف حافظه Next.js

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

مصرف رم در SSR

در Server-Side Rendering یا SSR، محتوای صفحه هنگام دریافت درخواست کاربر در سمت سرور تولید می شود.

یعنی برخلاف صفحات استاتیک، سرور باید برای درخواست های مرتبط عملیات دریافت داده و تولید HTML را انجام دهد. مستندات Next.js نیز توضیح می دهد که در SSR صفحات در هر درخواست رندر می شوند.

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

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

مصرف حافظه در SSG

در Static Site Generation یا SSG، صفحات در زمان اجرای next build تولید می شوند و خروجی آنها برای درخواست های بعدی مورد استفاده قرار می گیرد.

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

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

مصرف رم در ISR

Incremental Static Regeneration یا ISR ترکیبی از مزایای تولید استاتیک و به روزرسانی تدریجی محتوا را ارائه می دهد.

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

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

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

بنابراین اگر محتوای سایت زیاد است یا تعداد صفحات زیادی به صورت هم زمان نیاز به بازتولید دارند، باید این موضوع را در انتخاب RAM در نظر بگیرید.

چه عواملی مصرف RAM یک پروژه Next.js را افزایش می دهند؟

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

مهم ترین عوامل عبارت اند از:

تعداد وابستگی ها و کتابخانه ها: هرچه پروژه از پکیج ها و وابستگی های بیشتری استفاده کند، ممکن است در زمان Build و اجرای برنامه حافظه بیشتری مصرف شود. استفاده از کتابخانه های سنگین بدون نیاز واقعی، می تواند منابع پروژه را تحت فشار قرار دهد.

تعداد صفحات و محتوای قابل تولید: تولید تعداد زیادی صفحه استاتیک، مخصوصاً زمانی که اطلاعات هر صفحه از API یا دیتابیس دریافت می شود، می تواند مصرف حافظه Build را افزایش دهد.

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

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

تنظیمات Cache و Webpack: برخی تنظیمات برای بهبود سرعت Build یا پاسخ گویی، از حافظه بیشتری استفاده می کنند. به عنوان نمونه، Cache در Webpack می تواند سرعت پردازش را بهبود دهد، اما مصرف منابع را نیز افزایش دهد.

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

Heap در Node.js چیست و چه تفاوتی با RAM دارد؟

یکی از اصطلاحاتی که هنگام بررسی خطاهای کمبود حافظه در Next.js زیاد دیده می شود، Heap است.

Heap بخشی از حافظه است که موتور JavaScript یعنی V8 از آن برای نگهداری و مدیریت اشیای JavaScript استفاده می کند. Node.js برای اجرای برنامه از این حافظه بهره می برد، اما Heap تمام حافظه مصرفی پردازش نیست.

برای درک بهتر، Node.js چند شاخص مهم برای بررسی حافظه در اختیار توسعه دهندگان قرار می دهد:

• heapUsed: میزان Heap استفاده شده توسط برنامه

• heapTotal: مجموع Heap تخصیص داده شده توسط V8

• rss: میزان حافظه فیزیکی اشغال شده توسط کل پردازش

• external: حافظه مربوط به اشیای خارجی متصل به اشیای JavaScript

• arrayBuffers: حافظه مورد استفاده ArrayBuffer و Bufferها

برای مثال، ممکن است مقدار heapUsed پایین باشد، اما مقدار rss به دلیل استفاده از حافظه های خارج از Heap یا بخش های دیگر پردازش بیشتر باشد.

پس هنگام بررسی رم سرور باید به مصرف واقعی پردازش Node.js توجه کنید، نه فقط مقدار Heap.

دستور --max-old-space-size چه کاربردی دارد؟

NODE_OPTIONS="--max-old-space-size=1536" npm run build

$env:NODE_OPTIONS="--max-old-space-size=1536"
npm run build

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

طبق مستندات Node.js، برای ماشینی با 2 GiB حافظه، مقدار 1536 MiB می تواند یک تنظیم قابل بررسی باشد تا بخشی از RAM برای سایر پردازش ها باقی بماند. این مقدار نسخه آماده و اجباری برای تمام پروژه ها نیست و باید با توجه به مصرف واقعی برنامه تنظیم شود.

چطور مصرف رم Next.js را در زمان Build کاهش دهیم؟

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

مستندات Next.js چند روش برای شناسایی و کاهش مصرف حافظه پیشنهاد می کند.

استفاده از ابزار بررسی حافظه Build

next build --experimental-debug-memory-usage

این قابلیت اطلاعاتی درباره وضعیت Heap و فرآیند Garbage Collection در طول Build نمایش می دهد. همچنین در شرایط نزدیک شدن به محدودیت حافظه، امکان تهیه Heap Snapshot برای بررسی بیشتر وجود دارد.

به کمک این اطلاعات می توانید متوجه شوید مصرف حافظه در کدام مرحله افزایش پیدا می کند.

بررسی کتابخانه های اضافی

پکیج هایی که دیگر در پروژه استفاده نمی شوند یا وابستگی های سنگین غیرضروری، می توانند مصرف حافظه را افزایش دهند.

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

بررسی تنظیمات Webpack

در Next.js قابلیتی با عنوان experimental.webpackMemoryOptimizations وجود دارد که از نسخه 15 معرفی شده است.

با فعال کردن این گزینه در پروژه هایی که از Webpack استفاده می کنند، می توان رفتار حافظه Webpack را بهینه کرد. این قابلیت همچنان آزمایشی است و ممکن است کمی زمان کامپایل را افزایش دهد؛ بنابراین باید پس از فعال سازی، سازگاری و عملکرد Build بررسی شود.

همچنین Webpack Build Worker در نسخه های جدید Next.js، در شرایط پشتیبانی شده به صورت پیش فرض فعال است و می تواند فشار حافظه هنگام کامپایل را کاهش دهد.

بررسی TypeScript و Source Map

بررسی نوع داده ها در پروژه های بزرگ TypeScript می تواند به حافظه قابل توجهی نیاز داشته باشد. تولید Source Map نیز در زمان Build مصرف حافظه را افزایش می دهد.

می توانید فرآیند بررسی TypeScript را در یک مرحله جداگانه از CI/CD اجرا کنید یا در صورت عدم نیاز واقعی، تنظیمات Source Map را بررسی کنید.

نادیده گرفتن خطاهای TypeScript برای عبور از Build راه حل مناسبی نیست؛ زیرا ممکن است باعث انتشار نسخه ای با خطاهای برنامه نویسی شود.

برای انتخاب هاست Next.js چه مشخصاتی را بررسی کنیم؟

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

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

نوع و سرعت دیسک: فایل های پروژه، Cache، خروجی Build و اطلاعات موقت روی دیسک ذخیره می شوند. استفاده از SSD یا NVMe می تواند در عملیات خواندن و نوشتن اطلاعات مؤثر باشد.

نسخه Node.js: محیط سرور باید از نسخه سازگار Node.js پشتیبانی کند. طبق مستندات فعلی Next.js، حداقل نسخه Node.js مورد نیاز برای راه اندازی پروژه جدید 20.9 است.

امکان اجرای دائمی Node.js: اگر پروژه به قابلیت های سمت سرور نیاز دارد، هاست باید امکان اجرای فرآیند Node.js و مدیریت پایدار آن را فراهم کند. صرفاً داشتن فضای میزبانی یا امکان آپلود فایل برای اجرای چنین پروژه ای کافی نیست.

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

پیش از خرید، مشخص کنید که Build روی همان سرور انجام می شود یا در محیط جداگانه. این موضوع در انتخاب پلن مناسب تأثیر مستقیمی دارد.

چطور بفهمیم سرور انتخاب شده برای Next.js کافی است؟

بهترین روش، اندازه گیری مصرف واقعی پروژه در شرایط نزدیک به محیط Production است.

ابتدا Build را اجرا کنید و بیشترین مصرف حافظه در این مرحله را بررسی کنید. سپس برنامه را با next start در حالت Production بالا بیاورید و مصرف RAM را در زمان فعالیت عادی اندازه گیری کنید.

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

console.log(process.memoryUsage());

با اجرای این کد در محیط پردازش برنامه، مقادیری مانند rss، heapUsed و external قابل بررسی هستند.

اگر مصرف RSS به طور مداوم افزایش پیدا کند و پس از کاهش ترافیک به سطح قبلی برنگردد، باید احتمال نشت حافظه یا نگهداری غیرضروری داده ها را نیز بررسی کنید.

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

جمع بندی: برای یک سایت Next.js چند گیگ رم بخریم؟

برای یک پروژه کوچک Next.js، سرور 2 گیگابایتی می تواند نقطه شروع مناسبی باشد؛ اما برای سایت های متوسط با پردازش سمت سرور، انتخاب 4 گیگابایت RAM منطقی تر است. پروژه های سنگین، داشبوردهای پویا و سایت های پرترافیک نیز ممکن است به 8 گیگابایت یا بیشتر نیاز داشته باشند.

مهم تر از مقدار رم، شناخت تفاوت مصرف حافظه در زمان next build و اجرای Production است. ممکن است برای Build به سرور قوی تری نیاز داشته باشید، اما نسخه نهایی برنامه روی پلن کوچک تری اجرا شود.

پیشنهاد می شود پیش از انتخاب هاست Next.js، نوع رندر صفحات، تعداد پردازش های هم زمان، وضعیت Cache و نحوه اجرای Build را مشخص کنید. به این ترتیب می توانید به جای پرداخت هزینه برای منابع غیرضروری، پلنی متناسب با نیاز واقعی پروژه انتخاب کنید.