[Nestia] با fastify سرعت NestJS را 30 برابر کنید
![[Nestia] با fastify سرعت NestJS را 30 برابر کنید [Nestia] با fastify سرعت NestJS را 30 برابر کنید](https://nabfollower.com/blog/wp-content/uploads/2023/05/Nestia-با-fastify-سرعت-NestJS-را-30-برابر-کنید-780x470.png)
طرح کلی
nestia
و fastify
را افزایش می دهد NestJS
عملکرد سرور حدود 10 برابر تا 30 برابر بیشتر است.
در مقاله قبلی کتابخانه ام را معرفی کردم nestia
، ساخت NestJS
خیلی راحت تر و خیلی سریع تر در مقاله، معرفی بهبود عملکرد، من این را گفته بودم nestia
می تواند سرعت ویلداسیون را حداکثر 20000 برابر سریعتر افزایش دهد (سریال سازی JSON 200 برابر سریعتر است).
اتفاقاً بعضی ها از من اینطور پرسیده اند:
باشه، تو
nestia
سرور NestJS را با افزایش بسیار زیاد سرعت اعتبار سنجی و سریال سازی سریعتر می کند. به هر حال، عملکرد کل سرور چطور؟ من به خصوص می خواهم بدانم که چقدرnestia
می تواند تعداد اتصالات همزمان را افزایش دهد.چطور؟
nestia
عملکرد در کل سطح سرور؟
امروز با جواب برگشتم پاسخ این است، nestia
(+ fastify
) افزایش NestJS
سرور در دسترس در مورد 10 برابر تا 30 برابر. من به شما نشان خواهم داد که چگونه آن را اندازهگیری کردهام، و توضیح میدهم که چگونه فقط اعتبارسنجی و سریالسازی JSON میتواند بر عملکرد کل سرور تأثیر بگذارد.
بر روی Surface Pro 8 اندازه گیری شد
برای مرجع، میتوانید با دنبال کردن دستورات زیر، برنامه بنچمارک را روی رایانه خود اجرا کنید. پس از معیار، گزارشی تحت عنوان صادر خواهد شد nestia/benchmark/results/{YOUR-CPU-NAME}
فهرست راهنما. اگر نتیجه PR را در مخزن من (https://github.com/samchon/nestia) بفرستید، خوشحال می شوم و از آن قدردانی می کنم.
git clone https://github.com/samchon/nestia
cd nestia/benchmark
npm install
npm start
اعتبار سنجی
نحوه استفاده
import { TypedBody, TypedParam, TypedRoute } from "@nestia/core";
import { Controller } from "@nestjs/common";
import { IBbsArticle } from "./IBbsArticle";
@Controller("bbs/articles")
export class BbsArticlesController {
@TypedRoute.Put(":id")
public async update(
@TypedParam("id", "uuid") id: string,
@TypedBody() input: IBbsArticle.IUpdate, // 20,000x faster validation
): Promise<void> {}
}
زمانی که الف را توسعه می دهید NestJS
سرور باطن با nestia
، می توانید به راحتی داده های بدن درخواست را فقط با استفاده از آن تأیید کنید @nestia.TypedBody()
عملکرد دکوراتور مانند بالا
برای مرجع، بر خلاف class-validator
و class-transform
در حال استفاده توسط NestJS
که نیاز به تعاریف طرحواره تکراری سه گانه دارند، nestia
می تواند از نوع TypeScript خالص استفاده کند. به قطعه کد زیر نگاه کنید، سپس ممکن است متوجه شوید که چگونه nestia
تعریف طرحواره DTO را به راحتی انجام می دهد.
//----
// NESTJS (class-validator + class-transform) REQUIRES
// TRIPLE DUPLICATED DEFINITION
//----
export class BbsArticle {
@ApiProperty({
type: () => AttachmentFile,
nullable: true,
isArray: true,
description: "List of attached files.",
})
@Type(() => AttachmentFile)
@IsArray()
@IsOptional()
@IsObject({ each: true })
@ValidateNested({ each: true })
files!: AttachmentFile[] | null;
}
//----
// BESIDES, NESTIA UNDERSTANDS PURE TYPESCRIPT TYPE
//----
export interface IBbsArticle {
files: IAttachmentFile[] | null;
}
عملکرد فردی
بر روی Intel i5-1135g7، Surface Pro 8 اندازه گیری شده است
هنگام اندازه گیری عملکرد اعتبارسنجی، nestia
(nestia
استفاده می کند typia.assert<T>()
تابع) حداکثر 20000 برابر سریعتر از class-validator
استفاده شده توسط NestJS
به صورت پیش فرض.
اگر چنین سرعت اعتبارسنجی سریعی در کل سطح سرور اعمال شود، چگونه فکر می کنید؟ از آنجایی که اعتبارسنجی دادههای بدنه درخواست، بخش کوچکی از کل سرور باطن را میگیرد، آیا این تفاوت عملکرد به اندازه کافی در سطح کلی سرور تأثیرگذار نیست؟ یا فاصله 20000 برابری یک مقدار بسیار زیاد است، بنابراین بر عملکرد کل سرور تأثیر می گذارد؟
بیایید نمودار معیار سرور را در زیر ببینیم.
عملکرد سرور
بر روی Intel i5-1135g7، Surface Pro 8 اندازه گیری شده است
پاسخ این بود که کل عملکرد سطح سرور به طور قابل توجهی تحت تأثیر قرار می گیرد.
هنگام مقایسه عملکرد در کل سطح سرور با اتصالات همزمان، nestia
می تواند تعداد اتصالات همزمان را حدود 10 برابر بیشتر از NestJS
. در صورت تطبیق fastify
، چنین شکاف عملکردی تا 25 برابر افزایش می یابد. علاوه بر این، سازگاری fastify
که در NestJS
فقط حدود 1 تا 2 درصد باعث ایجاد آکنه می شود.
من فکر می کنم چنین تفاوت قابل توجهی به دو دلیل ایجاد می شود.
مورد اول این است: اعتبارسنجی ها در موضوع اصلی پردازش می شوند. همانطور که میدانید، نقطه قوت NodeJS رویدادهایی است که با ورودی/خروجی غیرمسدود نمایش داده میشوند و همه آنها در پسزمینه اجرا میشوند. با این حال، اعتبار سنجی داده های بدنه درخواست در رشته اصلی پردازش می شود، بنابراین اگر چنین منطق اعتبارسنجی کند باشد، کل سرور باطن را متوقف می کند.
دلیل دوم فقط است 20000 برابر شکاف. اگرچه اعتبارسنجی داده بدنه درخواست کار کوچکی در چارچوب کل فرآیندهای سرور است، اگر شکاف عملکرد 20000 برابر باشد، تفاوت قابل توجهی خواهد بود.
با توجه به عملکرد نخ اصلی با شکاف عملکرد 20000 برابری، نتیجه بالاتر از معیار به اندازه کافی منطقی است.
ارجاع
برای مرجع، اعتبار سنجی بدنه درخواست از یک نمونه آرایه با طول 100 استفاده می کند. اگر طول را به 10 کاهش دهید، افزایش عملکرد به نصف می رسد (حدود 60٪). در غیر این صورت، با افزایش طول به بزرگتر شدن، بهبود عملکرد به طور چشمگیری افزایش می یابد.
// "IBox3D" SIMILAR DTOS ARE USED, WITH 100 LENGTH ARRAY
export interface IBox3D {
scale: IPoint3D;
position: IPoint3D;
rotate: IPoint3D;
pivot: IPoint3D;
}
export interface IPoint3D {
x: number;
y: number;
z: number;
}
JSON Serializaiton
نحوه استفاده
import { TypedBody, TypedParam } from "@nestia/core";
import { Controller } from "@nestjs/common";
import typia from "typia";
import { IBbsArticle } from "./IBbsArticle";
@Controller("bbs/articles")
export class BbsArticlesController {
@TypedRoute.Get(":id") // 200x faster JSON serialization
public async at(
@TypedParam("id", "uuid") id: string
): Promise<IBbsArticle> {
return typia.random<IBbsArticle>();
}
}
زمانی که الف را توسعه می دهید NestJS
سرور باطن با nestia
، می توانید به راحتی سرعت سریال سازی JSON را فقط با استفاده از آن افزایش دهید @nestia.EncryptedRoute.${method}()
عملکرد دکوراتور مانند بالا
برای مرجع، بر خلاف class-validator
و class-transform
در حال استفاده توسط NestJS
که نیاز به تعاریف طرحواره تکراری سه گانه دارند، nestia
می تواند از نوع TypeScript خالص استفاده کند. به قطعه کد زیر نگاه کنید، سپس ممکن است متوجه شوید که چگونه nestia
تعریف طرحواره DTO را به راحتی انجام می دهد.
//----
// NESTJS (class-validator + class-transform) REQUIRES
// TRIPLE DUPLICATED DEFINITION
//----
export class BbsArticle {
@ApiProperty({
type: () => AttachmentFile,
nullable: true,
isArray: true,
description: "List of attached files.",
})
@Type(() => AttachmentFile)
@IsArray()
@IsOptional()
@IsObject({ each: true })
@ValidateNested({ each: true })
files!: AttachmentFile[] | null;
}
//----
// BESIDES, NESTIA UNDERSTANDS PURE TYPESCRIPT TYPE
//----
export interface IBbsArticle {
files: IAttachmentFile[] | null;
}
عملکرد فردی
یادت میاد؟ من یک مقاله در مورد کتابخانه دیگرم نوشته بودم typia
و عملکرد سریال سازی JSON را بین مقایسه کرده بود typia
و class-transformer
. در معیار قبلی، typia
حداکثر 200 برابر سریعتر از class-transformer
.
برای مرجع، nestia
استفاده می کند typia
، و NestJS
استفاده می کند class-transformer
.
بر روی Intel i5-1135g7، Surface Pro 8 اندازه گیری شده است
چگونه فکر می کنید که چنین سرعت سریال سازی JSON سریع در کل سطح سرور اعمال شود؟ از آنجایی که بهبود عملکرد سریال سازی JSON بسیار کوچکتر از حالت اعتبارسنجی است (200x در مقابل 20000x)، بنابراین آیا این تفاوت عملکرد به اندازه کافی در سطح کلی سرور تأثیرگذار نیست؟ یا شکاف 200 برابری بر عملکرد کل سرور تأثیر میگذارد، زیرا سریالسازی JSON کار سنگینتری نسبت به اعتبارسنجی است؟
بیایید نمودار معیار سرور را در زیر ببینیم.
عملکرد سرور
بر روی Intel i5-1135g7، Surface Pro 8 اندازه گیری شده است
پاسخ این بود که کل عملکرد سطح سرور نیز به طور قابل توجهی تحت تأثیر قرار می گیرد.
هنگام مقایسه عملکرد در کل سطح سرور با اتصالات همزمان، nestia
می تواند تعداد اتصالات همزمان را حدود 10 برابر بیشتر از NestJS
. در صورت تطبیق fastify
، چنین شکاف عملکردی تا 18 برابر افزایش می یابد. علاوه بر این، سازگاری fastify
که در NestJS
فقط عملکرد آکنه را در حدود 0 تا 10٪ افزایش می دهد.
من فکر می کنم چنین تفاوت قابل توجهی به دو دلیل ایجاد می شود.
دلیل اول در مورد اعتبارسنجی یکسان است. سریال سازی های JSON در رشته اصلی پردازش می شوند. همانطور که میدانید، نقطه قوت NodeJS رویدادهایی است که با ورودی/خروجی غیرمسدود نمایش داده میشوند و همه آنها در پسزمینه اجرا میشوند. با این حال، اعتبار سنجی داده های بدنه درخواست در رشته اصلی پردازش می شود، بنابراین اگر چنین منطق اعتبارسنجی کند باشد، کل سرور باطن را متوقف می کند.
دلیل دوم این است که سریال سازی JSON فرآیندی سنگین تر از اعتبارسنجی است. بنابراین، حتی اگر سریالسازی JSON عملکرد کمتری نسبت به اعتبارسنجی (200x در مقابل 20000) به دست آورد، همچنان در کل سطح سرور قابل توجه خواهد بود.
با توجه به عملیات thread اصلی و فرآیند سنگینتر سریالسازی JSON نسبت به اعتبارسنجی، نتیجه بالاتر از معیار به اندازه کافی منطقی است.
عملکرد ترکیبی
import { TypedBody, TypedRoute } from "@nestia/core";
import { Controller } from "@nestjs/common";
import { IBbsArticle } from "./IBbsArticle";
@Controller("bbs/articles")
export class BbsArticlesController {
@TypedRoute.Post()
public async store(
@TypedBody() input: IBbsArticle.IStore
): Promise<IBbsArticle> {
return {
...input,
id: "2b5e21d8-0e44-4482-bd3e-4540dee7f3d6",
created_at: "2023-04-23T12:04:54.168Z",
}
}
}
آخرین معیار مربوط به عملکرد ترکیبی، اعتبارسنجی دادههای بدنه درخواست و سریالسازی دادههای پاسخ JSON به طور همزمان است. مانند nestia
شکاف عملکرد قابل توجهی را نشان داده بود، معیار کامپوزیت نیز شکاف عملکرد قابل توجهی را نشان می دهد.
بیایید نمودار بنچمارک زیر را ببینیم و تصور کنید در صورت تطبیق عملکرد چقدر افزایش می یابد nestia
در شما NestJS
سرور باطن من فکر می کنم که دیگر دلیلی برای استفاده نکردن وجود ندارد nestia
. بسیار سریعتر و حتی بسیار آسانتر است.
بر روی Intel i5-1135g7، Surface Pro 8 اندازه گیری شده است
نتیجه
-
nestia
افزایش می دهدNestJS
عملکرد سرور به طور قابل توجهی - در صورت تطبیق
fastify
باnestia
، عملکرد بیشتر افزایش می یابد - در غیر این صورت سازگار شوید
fastify
بدونnestia
، عملکرد افزایش نمی یابد - استفاده کنیم
nestia
هنگام توسعهNestJS
سرور باطن- خیلی سریعتر
- بسیار ساده تر
- حتی از تولید SDK مانند پشتیبانی می کند
tRPC
سمت چپ کد سرور و سمت راست کد کلاینت (frontend) است