Bun یا Deno؛ توان عملیاتی نزدیک است، مصرف حافظه نه

برای API مبتنی بر TypeScript، نتیجهٔ یک بنچمارک عمومی به‌تنهایی برندهٔ Bun و Deno را تعیین نمی‌کند. در جدول بنچمارک HTTP، Hono روی Bun میانگین ۱۶۹٬۷۵۲ و روی Deno میانگین ۱۶۸٬۷۲۸ درخواست در ثانیه ثبت کرده است، در حالی که RSS فرایند پس از آزمون به‌ترتیب ۴۴٫۳ و ۹۸٫۶ مگابایت بوده است. این اعداد به اجرای Hono در همان مجموعهٔ آزمون تعلق دارند، نه به عملکرد هر برنامه‌ای که با این runtimeها نوشته شود.

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

میانگین جدول چه چیزی را پنهان می‌کند؟

ردیف‌های مورد بحث یک چارچوب مشترک را در دو محیط اجرا مقایسه می‌کنند، اما «میانگین» از مسیرهایی با کار یکسان به دست نیامده است. پاسخ متنی ساده، استخراج پارامتر و query، پردازش JSON و پخش فایل ویدئویی در جدول کنار هم قرار گرفته‌اند. مسیر ویدئو نیز با هم‌زمانی متفاوتی از مسیرهای سبک‌تر آزمایش شده است؛ بنابراین میانگین آن‌ها تصویر دقیقی از ترکیب ترافیک یک API مشخص نیست.

خود ردیف‌های مسیرها نشان می‌دهند که پیشتازی با نوع درخواست عوض می‌شود: اجرای Hono روی Deno در مسیر پاسخ متنی و پردازش بدنه جلوتر است، اما اجرای آن روی Bun در مسیر query و پخش ویدئو برتری دارد. اگر عمدهٔ زمان API شما صرف اعتبارسنجی، پرس‌وجوی پایگاه داده یا انتظار برای سرویس بیرونی شود، سهم runtime از زمان پاسخ نیز با این مسیرهای نمونه فرق خواهد داشت. به همین دلیل، رتبهٔ میانگین را باید نقطهٔ شروع پرسش دانست: کدام بخش از بار واقعی پروژه به مسیرهای آزمون شباهت دارد؟

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

حافظه و تأخیر را چگونه وارد تصمیم کنیم؟

RSS مقدار حافظه‌ای است که سیستم‌عامل به فرایند نسبت می‌دهد و برای برآورد ظرفیت ماشین یا کانتینر کاربرد دارد. مقدار «پس از آزمون» در جدول یک مشاهده در پایان بار است؛ از آن نمی‌توان نتیجه گرفت کدام بخش از اختلاف به موتور، چارچوب، دادهٔ بارگذاری‌شده یا جمع‌آوری زباله مربوط بوده است. در سرویس طولانی‌عمر، RSS را پیش از بار، هنگام بار پایدار و پس از آرام شدن ترافیک ثبت کنید. تفاوت میان یک جهش موقت و رشد ماندگار، برای سقف حافظه مهم‌تر از یک نمونهٔ منفرد است.

درخواست در ثانیه نیز کیفیت همهٔ پاسخ‌ها را توصیف نمی‌کند. میانهٔ تأخیر رفتار معمول را نشان می‌دهد و p95 و p99 به پاسخ‌های کندتر توجه می‌کنند؛ p99 مرزی است که تقریباً ۹۹ درصد مشاهده‌ها در آن یا پایین‌تر از آن قرار می‌گیرند. این صدک را همراه نرخ خطا و تعداد درخواست‌های هم‌زمان بخوانید. ممکن است با افزایش فشار، توان عملیاتی همچنان بالا برود، ولی صف شدن درخواست‌ها یا خطاها ظرفیت واقعاً قابل‌استفادهٔ سرویس را محدود کنند.

برای حافظه و تأخیر، شرایط اندازه‌گیری به‌اندازهٔ عدد اهمیت دارد. پاسخ کوچکِ ذخیره‌شده در حافظه، بدنهٔ JSON بزرگ و فراخوانی پایگاه داده فشارهای متفاوتی به تخصیص حافظه و زمان انتظار وارد می‌کنند. اگر سقف کانتینر سخت‌گیرانه است، فقط RSS میانگین را نگه ندارید؛ بیشینهٔ مشاهده‌شده در بار پایدار و رفتار فرایند پس از افت ترافیک نیز در تصمیم استقرار نقش دارند.

آزمون همسان را با بار پروژه بسازید

برای مقایسهٔ قابل‌تکرار، ابتدا رفتار API را ثابت کنید. همان نسخهٔ Hono یا چارچوب مورد استفادهٔ پروژه، همان منطق مسیرها، دادهٔ ورودی، اندازهٔ پاسخ، وابستگی‌ها و سیاست cache را در هر دو اجرا نگه دارید. تفاوت‌های لازم در کد راه‌اندازی Bun و Deno را ثبت کنید؛ تغییر هم‌زمان چارچوب و runtime اجازه نمی‌دهد سهم هرکدام را تشخیص دهید.

1. از ترافیک سرویس، چند مسیر نماینده و نسبت تقریبی درخواست‌های آن‌ها را بردارید. یک مسیر سبک، یک مسیر پردازش بدنه و یک مسیر وابسته به پایگاه داده یا سرویس بیرونی می‌توانند فشارهای متفاوت را آشکار کنند. اگر دادهٔ واقعی در دسترس نیست، ترکیب انتخابی را صریحاً یک سناریوی فرضی بنامید.
2. نسخهٔ runtime، چارچوب و بسته‌ها، نوع ماشین، تعداد هسته‌ها و محدودیت حافظه را ثبت کنید. بارساز را جدا از فرایند سرور اجرا کنید تا سقف توان خود بارساز با سقف API اشتباه نشود.
3. هر اجرا را پیش از ثبت نتیجه گرم کنید. مدت آزمون، هم‌زمانی و دادهٔ ورودی را یکسان نگه دارید، چند نوبت اجرا کنید و ترتیب Bun و Deno را جابه‌جا کنید تا اثر وضعیت ماشین کمتر شود.
4. برای هر نوبت، توان عملیاتی، نرخ خطا، میانه، p95، p99 و RSS را کنار هم ذخیره کنید. زمان راه‌اندازی را فقط وقتی در تصمیم دخالت دهید که الگوی استقرار شما به بالا آمدن مکرر فرایند وابسته است.

دو نوع اجرا به دو پرسش متفاوت پاسخ می‌دهند. اجرای مسیر واقعی با پایگاه داده، ظرفیت کل سامانه را نشان می‌دهد؛ اجرای همان منطق با وابستگی کنترل‌شده کمک می‌کند اثر آن وابستگی از هزینهٔ پردازش داخل API جدا شود. نتایج این دو را با هم ادغام نکنید: کندی سرویس بیرونی ممکن است اختلاف runtime را بپوشاند، در حالی که یک مسیر کاملاً درون‌حافظه‌ای سهم آن را بیش از محیط عملیاتی برجسته کند.

ابزار داخلی کجا به کار می‌آید؟

برای یافتن هزینهٔ یک بخش کوچک از کد، راهنمای بنچمارک Bun اندازه‌گیری با performance.now() و Bun.nanoseconds() را توضیح می‌دهد و برای بار HTTP استفاده از بارساز بیرونیِ به‌اندازهٔ کافی سریع را توصیه می‌کند. زمان‌سنج داخل فرایند برای بررسی کارهایی مانند تبدیل داده مناسب است، اما صف درخواست، مسیریابی، شبکه و ارسال پاسخ را مانند آزمون سرتاسری HTTP اندازه نمی‌گیرد.

در سوی دیگر، مستندات deno bench گروه‌بندی آزمون‌ها، تعیین baseline، صدک‌های زمان هر تکرار و محدود کردن اندازه‌گیری به بخش بحرانی را شرح می‌دهد. این امکانات برای مقایسهٔ یک عملیات مشخص سودمندند. p99 یک عملیات در deno bench همان p99 پاسخ HTTP زیر بار نیست؛ برای سنجش سرویس کامل، بارساز بیرونی و تعریف یکسان درخواست‌ها را برای هر دو runtime به کار ببرید.

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

مجوزها و زنجیرهٔ ابزار چه اثری دارند؟

مدل مجوزهای Deno دسترسی به بیشتر ورودی‌وخروجی‌های حساس را به‌طور پیش‌فرض محدود می‌کند؛ برای نمونه، شنیدن اتصال شبکه به مجوز --allow-net نیاز دارد. فایل، متغیر محیطی و اجرای فرایند نیز مجوزهای مربوط به خود را دارند. در آزمون API، دستور اجرا باید همان دسترسی‌هایی را بدهد که استقرار واقعی لازم دارد، وگرنه بخشی از پیکربندی عملیاتی پروژه از مقایسه حذف می‌شود.

مستندات Bun runtime، مدیر بسته، اجراکنندهٔ آزمون و bundler را در یک مجموعه معرفی می‌کند. ارزش این ترکیب به کارهایی بستگی دارد که تیم واقعاً در ساخت، آزمون و انتشار سرویس انجام می‌دهد؛ جدول توان عملیاتی دربارهٔ سازگاری اسکریپت‌ها یا سهولت این گردش کار پاسخی نمی‌دهد. آزمون‌های خود پروژه را نیز در هر دو محیط اجرا کنید تا نتیجهٔ سرعت به برنامه‌ای مربوط باشد که واقعاً می‌توانید مستقر کنید.

اگر بار همسان پروژه توان عملیاتی نزدیک نشان داد، تفاوت RSS، p99، نرخ خطا و شیوهٔ دادن مجوزها می‌تواند انتخاب را تعیین کند. اگر یکی از runtimeها در مسیر پرتکرار پروژه مزیت پایداری داشت، همان نتیجه از رتبهٔ کلی بنچمارک عمومی مرتبط‌تر است. نسخه‌ها و شرایط اجرا را همراه تصمیم ثبت کنید تا با تغییر کد یا الگوی ترافیک، مقایسه دوباره قابل انجام باشد.

بیشتر بخوانید:

• Bun یا Node.js؛ سرعت بیشتر با حفره‌های سازگاری معاوضه می‌شود
• pgvector یا Pinecone؛ سه‌برابر توان عملیاتی می‌تواند ۴٫۸ برابر گران‌تر شود
• Pluto با ۴۲ میلیون دلار از اختفا بیرون آمد؛ ریسک اصلی از ابزارهای بی‌کد است