[Nestia] با fastify سرعت NestJS را 30 برابر کنید

طرح کلی

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 اندازه گیری شده است

نتیجه

1. nestia افزایش می دهد NestJS عملکرد سرور به طور قابل توجهی
2. در صورت تطبیق fastify با nestia، عملکرد بیشتر افزایش می یابد
3. در غیر این صورت سازگار شوید fastify بدون nestia، عملکرد افزایش نمی یابد
4. استفاده کنیم nestia هنگام توسعه NestJS سرور باطن
   • خیلی سریعتر
   • بسیار ساده تر
   • حتی از تولید SDK مانند پشتیبانی می کند tRPC

سمت چپ کد سرور و سمت راست کد کلاینت (frontend) است