Сервергүй архитектур: Үйлчилгээний функцийн TTFB шинжилгээ

Serverless архитектур нь хөгжүүлэгчдэд суурь дэд бүтцийн удирдлагыг нууж, програм хангамжийг зохион бүтээх, байрлуулах арга барилыг хувьсгал хийсэн. Энэ шинэчлэлийн голд Function-as-a-Service (FaaS) оршдог бөгөөд энэ нь сервер удирдах шаардлагагүйгээр үйл явдлын хариуд тусдаа кодын хэсгүүдийг ажиллуулах боломжийг олгодог загвар юм. Энэ арга нь зөвхөн өргөтгөх чадвар ба зардлын үр ашигийг сайжруулдаг төдийгүй, ялангуяа Time to First Byte (TTFB)-г хэмжих тал дээр шинэ анхаарал татах асуудлуудыг бий болгодог. Serverless орчин дахь TTFB хэрхэн үйлчилж байгааг ойлгох нь хэрэглэгчийн туршлагыг оновчтой болгох, SEO зэрэглэлээ хадгалахад чухал юм.

Serverless архитектур ба Function-as-a-Service (FaaS)-ийн үндсэн ойлголтууд

Serverless архитектур нь уламжлалт үүлэн тооцооллын загвараас шилжиж, хөгжүүлэгчдэд серверийг шууд тохируулах эсвэл удирдах шаардлагыг арилгасан загвар юм. Виртуал машин эсвэл контейнерийг тохируулах, засварлах шаардлагатай уламжлалт загвараас ялгаатай нь serverless тооцоолол нь бүх дэд бүтцийн асуудлыг үүлэн үйлчилгээ үзүүлэгчид даатгадаг. Энэ нь хөгжүүлэгчдэд зөвхөн код болон бизнесийн логик дээр төвлөрөх боломжийг олгодог.

Serverless тооцооллын голд Function-as-a-Service (FaaS) оршдог бөгөөд энэ нь програмуудыг тусдаа, үйл явдалд суурилсан функцуудын цогцоор бүрдүүлдэг загвар юм. Эдгээр функцууд нь HTTP хүсэлт, өгөгдлийн сангийн шинэчлэлт, мессежийн дараалал эсвэл бусад үүлэн үйл явдлаар өдөөгдөж, шаардлагатай үед ажилладаг. Энэ нарийн гүйцэтгэлийн загвар нь өндөр өргөтгөх чадвартай, зардал хэмнэлттэй програм хангамжийн архитектурыг боломжтой болгодог.

Тухайлбал AWS Lambda, Azure Functions, болон Google Cloud Functions зэрэг тэргүүлэгч FaaS платформууд нь serverless функцуудыг байрлуулахад бат бөх орчин бүрдүүлдэг. Эдгээр платформууд нь автомат өргөтгөл, өндөр хүртээмж, бусад үүлэн үйлчилгээнүүдтэй уялдаатай интеграцчилалтай. Гол онцлогууд нь:

• Үйл явдалд суурилсан гүйцэтгэл: Функцууд зөвхөн тодорхой өдөөгчид хариу үйлдэл үзүүлдэг.
• Автомат өргөтгөл: Функцууд эрэлтэд нийцүүлэн уян хатан өргөжиж, багасдаг.
• Хэрэглсэн хэмжээгээр төлбөр төлөх: Төлбөр нь бодит тооцооллын хугацаа ба хэрэглэсэн нөөц дээр үндэслэгддэг.
• Удирдлагатай гүйцэтгэлийн орчин: Үйлчилгээ үзүүлэгчид засвар, аюулгүй байдал, дэд бүтцийн шинэчлэлтийг хариуцдаг.

Serverless ба FaaS-ийн нийтлэг хэрэглээ нь өргөн хүрээний програм хангамжийн салбарт тархсан. Үүнд бодит цагийн файл боловсруулах, API арын системүүд, чатботууд, IoT өгөгдөл хүлээн авах, төлөвлөгдсөн үүргүүд орно. Ашиг тус нь:

• Өргөтгөх чадвар: Serverless функцууд гэнэт их хэмжээний ачааллыг гараар оролцолгүйгээр даах чадвартай.
• Зардлын үр ашиг: Байгууллагууд зөвхөн бодит гүйцэтгэлийн хугацаанд төлдөг тул сул серверийн зардлыг арилгана.
• Үйл ажиллагааны ачааллыг бууруулах: Дэд бүтцийн удирдлагыг үүлэн үйлчилгээ үзүүлэгчдэд шилжүүлж, хөгжүүлэлтийн багуудыг шинэлэг зүйлд төвлөрүүлэх боломж олгодог.

Энэ загвар нь уян хатан ба үр ашигт төвлөрсөн орчин үеийн үүлэн тооцооллын загваруудтай сайн нийцдэг. Энэ нь Infrastructure-as-a-Service (IaaS) эсвэл Platform-as-a-Service (PaaS) загвараас ялгаатай нь дэд бүтцийн серверүүдийг бүрэн нууж өгдөг.

Дүгнэж хэлэхэд, server

Time to First Byte (TTFB) гэж юу вэ, Serverless орчинд түүний ач холбогдол

Time to First Byte (TTFB) гэдэг нь хэрэглэгчийн хүсэлт илгээснээс эхлэн хариуны анхны байт хэрэглэгчийн хөтчид ирэх хүртэлх хугацааг хэмждэг чухал гүйцэтгэлийн үзүүлэлт юм. Энэ нь вэб програмын хурд ба серверийн арын процессын хурдны үндсэн үзүүлэлт болдог. Serverless орчинд TTFB-г ойлгож, оновчтой болгох нь хэрэглэгчийн туршлагыг тасралтгүй хангах, хайлтын системийн зэрэглэлээ хадгалахад зайлшгүй чухал юм.

TTFB нь вэбсайт эсвэл програмын хурдыг хэрэглэгчдэд хэрхэн мэдрэгдэж байгааг шууд нөлөөлдөг. TTFB бага байх нь ачааллын хугацааг богиносгож, хэрэглэгчийн оролцоог нэмэгдүүлж, буцах хандалтыг бууруулдаг. Мөн хайлтын системүүд хуудсын хурдыг зэрэглэл тогтоох алгоритмдаа улам бүр оруулж байгаа тул TTFB нь SEO гүйцэтгэлийн гол үзүүлэлт болдог. Хурд удаан TTFB-тэй вэбсайтууд харагдах байдал, зочдын тоо буурах хандлагатай тул энэ үзүүлэлтийг хянаж сайжруулах шаардлагатай.

TTFB-г хэмжихдээ хэрэглэгчийн HTTP хүсэлт илгээснээс эхлэн анхны байт хариу ирэх хүртэлх хугацааг хянадаг. Энэ хэмжилт нь серверийн боловсруулалтын саатал, сүлжээний дамжуулалтын хугацаа, дунд үеийн нэмэлт хугацааг багтаадаг. Serverless програмуудад TTFB-г шинжлэхэд ихэвчлэн хөтчийн хөгжүүлэгчийн хэрэгслүүд, хиймэл хяналтын үйлчилгээ (Pingdom, GTmetrix гэх мэт), мөн FaaS платформуудтай интеграцчилсан тусгай APM (Програмын гүйцэтгэлийн хяналт) шийдлүүд ашиглагддаг. Эдгээр хэрэгслүүд нь саатлын бүрдэл хэсгүүдийг нарийвчлан харуулж, оновчтой болгох арга хэмжээг чиглүүлэх боломжийг олгодог.

TTFB-ийн асуудал уламжлалт серверийн тохиргоо ба serverless функцуудын хооронд ихээхэн ялгаатай. Уламжлалт вэб серверүүд нь байнгын ажиллах орчинтой тул хүсэлтэнд хариулахдаа эхлүүлэх нэмэлт хугацаа бага гардаг. Харин serverless функцууд хүйтэн эхлэл (cold start) гэж нэрлэгддэг үзэгдэлтэй тул гүйцэтгэлийн орчинг эхлүүлэх шаардлагатай байдаг. Энэ эхлүүлэх хугацаа нь TTFB-г ихээр нэмэгдүүлж, ялангуяа ховор эсвэл гэнэтийн ачааллын үед илүү мэдэгдэхүйц болдог.

Мөн serverless архитектур нь API gateway-ийн нэмэлт ачаалал, функцийн контейнер үүсгэх, динамик нөөцийн хуваарилалт зэрэг онцгой саатлын хүчин зүйлүүдийг авчирдаг. Эдгээр нь TTFB-г хэмжихэд төвөгтэй болгодог бөгөөд serverless гүйцэтгэлийн үзүүлэлтүүдийг нарийн ойлгохыг шаарддаг. Уламжлалт үүлэн тооцооллын загваруудтай харьцуулахад latency нь тогтвортой, таамаглах боломжтой байдаг бол serverless TTFB нь ачааллын хэв маяг, платформын онцлогт үндэслэн хэлбэлздэг.

Товчхондоо, TTFB нь serverless вэб програмын саатал ба хурдны гол үзүүлэлт юм. Энэ нь хэрэглэгчийн туршлагаас гадна SEO зэрэглэлд нөлөөлдөг тул Function-as-a-Service платформ дээр ажиллаж буй хөгжүүлэгч, архитекторуудад чухал анхаарах зүйл болдог. ТTFB-г нарийвчлан шинжлэх, serverless-тэй холбоотой саатлын хүчин зүйлсийг ойлгох нь илүү хурдан, найдвартай програмуудыг үүсгэхэд тусалдаг.

Function-as-a-Service суулгалтуудад TTFB-д нөлөөлөх хүчин зүйлс

Serverless гүйцэтгэлийн үзүүлэлтүүдийг үнэлэхэд Time to First Byte (TTFB)-д хамгийн их нөлөөлдөг хүчин зүйлсийн нэг нь нэр хүндтэй хүйтэн эхлэлийн саатал юм. Хүйтэн эхлэл нь үүлэн үйлчилгээ үзүүлэгч шинэ runtime орчинг эхлүүлж, урьдчилан халсан тохиолдол байхгүй эсвэл идэвхгүй байсан serverless функцыг ажиллуулах шаардлагатай үед үүсдэг. Энэ эхлүүлэх процесс нь функц хүсэлтийг боловсруулах эхлэхээс өмнө ихээхэн саатал үүсгэж, TTFB-г нэмэгдүүлж, хэрэглэгчийн туршлагад сөргөөр нөлөөлдөг.

Хүйтэн эхлэлийн саатал нь ашигласан програмчлалын хэл, суулгалтын багцын хэмжээ, функцийн эхлүүлэх логикийн төвөгтэй байдлаас хамааран өөр өөр байдаг. Жишээлбэл, Go эсвэл C# зэрэг компиляцлагдсан хэл дээр бичигдсэн функцууд Python эсвэл Node.js шиг тайлбарлагдсан хэлнүүдтэй харьцуулахад runtime ялгаанаас болж богино хүйтэн эхлэлтэй байдаг. Мөн олон хамааралтай том функцийн багцуудыг ачаалах хугацаа урт байдаг тул хүйтэн эхлэлийн хугацааг нэмэгдүүлдэг.

Хүйтэн эхлэлээс гадна функцийн эхлүүлэх үйл явц TTFB-д чухал үүрэг гүйцэтгэдэг. Эхлүүлэх үйл явцад глобал хувьсагчид тохируулах, өгөгдлийн сантай холболт үүсгэх, тохиргооны файлуудыг ачаалах зэрэг орно. Хүнд эхлүүлэх логик бүхий функцууд хариу өгөхөд илүү удаан хугацаа шаардана. Энэ кодыг оновчтой болгож, шаардлагагүй ажлыг хойшлуулах эсвэл эхлүүлэх үйл явцыг асинхрон байдлаар гүйцэтгэх нь TTFB-д үзүүлэх нөлөөг бууруулахад тусална.

FaaS платформуудаас олгогддог runtime орчин нь мөн сааталд нөлөөлдөг. Тус бүрийн үйлчилгээ үзүүлэгч өөр өөр дэд бүтцийн ба контейнер дахин ашиглалтын стратегиудыг санал болгодог бөгөөд энэ нь функцууд хэр хурдан ажиллахыг тодорхойлдог. Жишээ нь, зарим платформууд хүйтэн эхлэл багасгахын тулд халсан контейнеруудыг идэвхтэй дахин ашигладаг бол бусад нь аюулгүй байдлын тусгаарлалыг чухалчилж эхлүүлэх хугацааг уртасгадаг.

Нөөцийн хуваарилалт нь бас чухал хүчин зүйл юм. Serverless платформууд ихэвчлэн функцийн тохиргоо эсвэл эрэлт дээр үндэслэн CPU ба санах ойн нөөцийг динамикаар хуваарилдаг. Санах ой дутмаг байвал CPU гүйцэтгэл саатаж, гүйцэтгэл удааширч, TTFB нэмэгддэг. Харин нөөцийг хэт их хуваарилах нь саатлыг бууруулж болох ч зардлыг нэмэгдүүлдэг тул serverless суулгалтуудад гол тэнцвэрийг олж тогтоох шаардлагатай.

Сүлжээтэй холбоотой хүчин зүйлс нь FaaS орчин дахь TTFB-д нөлөөлдөг. Сүлжээний саатал нь API gateway, функцийн гүйцэтгэлийн орчин, өгөгдлийн сан эсвэл гадаад API зэрэг арын үйлчилгээ хоорондын харилцаанаас үүсдэг. Үүлэн үйлчилгээ үзүүлэгчид дотоод сүлжээг оновчтой болгохыг хичээдэг ч газарзүйн зай болон интернетийн чиглүүлэлт хариу өгөх хугацаанд хэлбэлзэл үүсгэж болно. Олон арын дуудлага эсвэл төвөгтэй зохион байгуулалттай програмууд ихэвчлэн нэмэгдсэн сааталтай тулгардаг.

API gateway-ийн ачаалал нэмэгдэх нь бас нэг саатлын эх үүсвэр юм. Олон serverless архитектурт орж ирж буй хүсэлтүүд API gateway-ээр дамждаг бөгөөд энэ нь баталгаажуулалт, хязгаарлалт, чиглүүлэлт зэрэг үүргүүдийг гүйцэтгэсний дараа функцыг дуудаж ажиллуулдаг. Энэ нэмэлт давхарга нь хүсэлтийг боловсруулах хугацаанд хэдэн миллисекунд нэмдэг бөгөөд TTFB-д нөлөөлдөг. Үр ашигтай gateway тохиргоог сонгож, шаардлагагүй middleware-ийг багасгах нь энэ ачааллыг бууруулахад тусална.

Арын интеграцийн саатал ч мөн адил чухал. Функцууд ихэвчлэн гадаад системүүдэд найдаж ажилладаг бөгөөд эдгээр системүүдийн удаан хариу эсвэл холболтын асуудлууд шууд TTFB-г нэмэгдүүлдэг. Кэшлэх стратегиудыг хэрэгжүүлэх, өгөгдлийн сангийн асуулгыг оновчтой болгох, шаардлагатай үед асинхрон боловсруулалтыг ашиглах нь арын саатлыг бууруулахад тусална.

Үйлчилгээ үзүүлэгч тус бүрийн оновчлол ба хязгаарлалтууд TTFB-ийн үр дүнд ихээхэн нөлөөлдөг. Жишээ нь, AWS Lambda нь функцийн урьдчилан халсан хувилбаруудыг санал болгодог бөгөөд энэ нь хүйтэн эхлэлийн нөлөөг бууруулдаг бол бусад платформууд халалтын механизм нь төдийлөн боловсронгуй биш байдаг. Мөн Google Cloud Functions нь Google-ийн edge сүлжээнд нягт интеграцлагдсанаар сүлжээний саатлыг бууруулах боломжтой. FaaS платформ бүрийн архитектур ба гүйцэтгэлийн онцлогийг TTFB-д мэдрэг програмуудыг хөгжүүлэхдээ нарийвчлан үнэлэх хэрэгтэй.

Жишээ болгон FaaS үйлчилгээ үзүүлэгчдийн TTFB-ийг хар

Serverless архитектур дахь TTFB-г оновчтой болгох практик стратегиуд

Хүйтэн эхлэлийн саатлыг бууруулах нь serverless орчинд TTFB-г оновчтой болгох хамгийн үр дүнтэй аргуудын нэг юм. Өргөнөөр ашиглагддаг нэг арга бол функц халалт бөгөөд энэ нь функцуудыг тогтмол дуудаж, гүйцэтгэлийн орчинг идэвхтэй байлгаж, хүйтэн эхлэлээс сэргийлэх арга юм. Энэ арга нь хариу өгөх хугацааг сайжруулж чадах ч тасралтгүй дуудах нь зардлыг нэмэгдүүлэх эрсдэлтэй. Халалтын дуудлагын давтамжийг төсвийн хязгаарлалтад тохируулан тэнцвэржүүлэх нь зардлын үр ашигтай байдлыг хадгалахад чухал.

Илүү дэвшилтэт, найдвартай шийдэл нь AWS Lambda зэрэг томоохон FaaS платформуудаас санал болгодог урьдчилан тохируулсан зэрэгцүүлэлт ашиглах явдал юм. Урьдчилан тохируулсан зэрэгцүүлэлт нь халсан функцийн тодорхой тоог урьдчилан хуваарилж, ирж буй хүсэлтийг хүйтэн эхлэлийн сааталгүйгээр шууд гүйцэтгэх боломжийг олгодог. Энэ функц нь latency-д мэдрэг програмуудад TTFB-г эрс бууруулдаг боловч нөөцийн захиалгад нэмэлт төлбөртэй байдаг. Тиймээс архитекторууд ачааллын хэв маяг ба төсвийг нарийвчлан үнэлж, урьдчилан тохируулсан зэрэгцүүлэлтийн хамгийн тохиромжтой түвшинг шийдэх хэрэгтэй.

Функцийн загварчлалын шилдэг туршлагууд мөн эхлүүлэх ачааллыг багасгахад ихээхэн хувь нэмэр оруулдаг. Хөгжүүлэгчид функцуудыг хөнгөн байлгахыг зорих ёстой:

• Боломжтой бол хүнд хамааралтай багцуудыг ашиглахаас зайлсхийх.
• Шаардлагагүй эхлүүлэх кодыг handler функцээс гадуур шилжүүлэх.
• Нөөц их шаарддаг үйлдлүүдийг шаардлагатай үед гүйцэтгэхээр хойшлуулах lazy loading аргыг ашиглах.
• Дэмжигдсэн runtime-д глобал хувьсагч ашиглан өгөгдлийн сантай холболтыг дахин ашиглах.

Эдгээр стратегиуд нь runtime орчныг тохируулах хугацааг багасгаж, шууд TTFB-г бууруулдаг.

Edge computing ба Content Delivery Network (CDN) интеграцчилал нь serverless програмуудын хариу өгөх хугацааг улам сайжруулдаг. Serverless функцуудыг хэрэглэгчдэд ойр сүлжээний ирмэг дээр байршуулснаар газарзүйн зайнаас үүсэх саатлыг багасгадаг. Олон FaaS үйлчилгээ үзүүлэгчид одоо edge функцийн үйлчилгээг санал болгодог, жишээ нь AWS Lambda@Edge эсвэл Cloudflare Workers, хөгжүүлэгчдэд дэлхий даяар тархсан node-ууд дээр код ажиллуулах боломж олгодог. Эдгээр edge функцуудыг CDN-үүдтэй интеграцчлах нь статик агуулга ба динамик хариуг хурдан хүргэхэд тусалж, Time to First Byte-г сайжруулдаг.

Тогтмол гүйцэтгэлийн мониторинг нь serverless архитектур дахь бага TTFB-г хадгалахад чухал. AWS CloudWatch, Azure Application Insights эсвэл гуравдагч талын APM платформууд зэрэг serverless мониторингийн хэрэгслүүд-ийг ашиглан хөгжүүлэгчид функцийн гүйцэтгэлийн хугацааг профайллаж, хүйтэн эхлэлүүдийг илрүүлж, саатал үүсгэгч хүчин зүйлсийг тодорхойлж чаддаг. Эдгээр мэдээллүүд нь serverless гүйцэтгэлийн хэмжигдэхүүн дэх хэв маяг ба гажуудлыг илрүүлж, өгөгдөлд суурилсан оновчлол хийх боломжийг олгодог.

TTFB-г оновчтой болгох нь чухал боловч serverless орчин дахь зардал ба гүйцэтгэлийн тэнцвэр-ийг анхаарах нь бас хэрэгтэй. Урьдчилан тохируулсан зэрэгцүүлэлт ба edge байрлалууд нь latency-г сайжруулдаг боловч үйл ажиллагааны зардлыг нэмэгдүүлдэг. Харин зардлыг хэт хэмнэх нь хүйтэн эхлэлүүдийг ихэсгэж, TTFB-г нэмэгдүүлж, хэрэглэгчийн туршлага ба SEO-д сөргөөр нөлөөлдөг. Хамгийн тохиромжтой тэнцвэрийг олоход ачааллын хэв маяг, latency шаардлага, төсвийн хязгаарлалтыг нарийвчлан шинжлэх шаардлагатай.

Дүгнэж хэлэхэд, serverless TTFB-г оновчтой болгох үр дүнтэй арга хэмжээ нь:

• Хүйтэн эхлэлийн саатлыг бууруулахын тулд

Үр дүнгийн хувьд чухал програмуудад зориулсан Serverless архитектурыг TTFB-ийн ойлголтоор үнэлэх

Time to First Byte-г шинжлэх нь серверлесс архитектур нь гүйцэтгэлийн хувьд чухал програмуудад тохиромжтой эсэх талаар үнэ цэнэтэй ойлголт өгдөг. TTFB-ийн шинжилгээ нь шийдвэр гаргагчдад latency-ийн хэв маягийг ойлгох, боломжит саатлыг илрүүлэх, серверлесс шийдлүүд нь тэдний ачааллын хурдан хариу үйлдлийн шаардлагад нийцэж байгаа эсэхийг тодорхойлоход тусалдаг.

Serverless архитектурыг уламжлалт болон контейнержүүлсэн загваруудтай харьцуулахад TTFB болон нийт latency-ийн хувьд хэд хэдэн ялгаа гардаг. Уламжлалт серверүүд болон Kubernetes зэрэг контейнер зохион байгуулалтын платформууд нь байнгын runtime орчныг хадгалж, ойролцоогоор шууд хүсэлтийг боловсруулах боломжийг олгодог бөгөөд TTFB нь тогтвортой бага байдаг. Харин серверлесс функцууд нь хүйтэн эхлэл болон динамик нөөцийн хуваарилалтын улмаас latency нь хэлбэлзэлтэй байж болно. Гэсэн хэдий ч серверлесс нь автомат масштаблалт болон үйл ажиллагааны энгийн байдлаараа олон хэрэглээнд хүчтэй өрсөлдөгч болдог.

Хатуу latency шаардлагатай гүйцэтгэлийн хувьд чухал програмууд—жишээ нь бодит цагийн арилжааны платформууд, интерактив тоглоомын backend системүүд, телемедицин зэрэг—хүйтэн эхлэлийн улмаас үүсэх TTFB-ийн хэлбэлзэл нь хүлээн зөвшөөрөгдөшгүй байж болно. Ийм нөхцөлд контейнержүүлсэн эсвэл зориулалтын серверүүд нь илүү таамаглах боломжтой, тогтвортой latency-ийн хэв маягийг өгдөг. Харин latency-ийн шаардлага нь бага, жишээ нь үйл явдалд суурилсан workflow, багц боловсруулалт, бага ачаалалтай API-ууд зэрэг програмууд серверлессийн масштаблалт ба зардлын үр ашгаас ихээхэн ашиг хүртдэг.

Архитекторууд болон хөгжүүлэгчид серверлессийг нэвтрүүлэхдээ масштаблалт, зардал, TTFB-ийн тэнцвэрийг хадгалахад дараах хүчин зүйлсийг харгалзан үзэх хэрэгтэй:

• Ачааллын хэв маяг: Ихээхэн хэлбэлзэлтэй эсвэл таамаглашгүй ачаалал серверлессийн автомат масштаблалтанд тохиромжтой.
• Latency-ийн мэдрэг байдал: Тогтвортой бага TTFB шаарддаг програмууд контейнержүүлсэн эсвэл холимог аргыг илүүд үзэж болно.
• Үйл ажиллагааны ачаалал: Серверлесс нь удирдлагын төвөгтэй байдлыг бууруулж, хөгжүүлэлтийн мөчлөгийг түргэсгэдэг.
• Зардлын нөлөөлөл: Ашигласан хэмжээний төлбөр нь илүү эдийн засгийн байж болох ч урьдчилан тохируулсан зэрэгцүүлэлт эсвэл халалтын стратегиудтай үед нэмэгдэх боломжтой.

Ирээдүйд, серверлесс TTFB-ийн ирээдүй амжилттай байна. Үүлний үйлчилгээ үзүүлэгчид хүйтэн эхлэлийн latency-г бууруулахад хөрөнгө оруулалт хийсээр байгаа бөгөөд үүнд snapshot-д суурилсан контейнер эхлүүлэх, сайжруулсан runtime оновчлолууд, өргөжсөн edge computing боломжууд орно. Мөн шинэ стандартууд ба хэрэгслүүд серверлесс гүйцэтгэлийг илүү сайн харах ба хянах боломжийг бий болгох зорилготой.

Дүгнэж хэлэхэд, TTFB-ийн шинжилгээнд тулгуурласан серверлесс архитектурыг үнэлэх нь гүйцэтгэ