Nginx эсвэл Caddy: хурдны ялагч HTTPS-ийн ажлыг үнэгүй хийхгүй

Хоёр цөмд хийсэн нийтлэгдсэн хэмжилтэд Nginx статик HTTPS файл үйлчлэх хурд, тогтмол ачааллын p99 хоцролт, CPU ба RAM-ийн хэрэглээгээр давуу гарсан. Caddy хүсэлт бүрт шинэ TLS холболт үүсгэх сорилд илүү олон холболт боловсруулсан бөгөөд сертификатыг автоматаар удирддаг. Жижиг VPS-д аль нь дээр вэ гэдэг нь үйлчилгээ ямар ачаалалтай, HTTPS-ийн өдөр тутмын ажлыг хэрхэн зохион байгуулахаас хамаарна.

Статик файл их үйлчилдэг, цөмийн нөөц шахуу серверт Nginx-ийн хэмжигдсэн давуу тал хэрэг болно. Цөөн домэйнтэй аппликейшнийг reverse proxy-оор нийтэлж, сертификат авах, сунгах ажлыг цөөлөх нь чухал бол Caddy тохиромжтой. Proxy-ийн дээд хурдыг харьцуулахдаа анхны тохиргоо болон арын холболтыг дахин ашигладаг тохиргооны үр дүнг ялгах шаардлагатай: энэ өөрчлөлт хэмжилтийн дүр зургийг эрс өөрчилжээ.

Хоёр цөмийн үр дүн ямар орчинд гарсан бэ?

Туршилтад Nginx 1.31.6, Caddy 2.11.6-ийг нэг компьютер дээр тус бүр хоёр физик цөмд хязгаарлаж ажиллуулсан. Ачаалал үүсгэгч болон proxy-ийн арын үйлчилгээ өөр цөм ашигласан ч Docker-ийн дотоод сүлжээ, санах ой, үйлдлийн системийн сүлжээний давхаргыг хуваалцжээ. Хүсэлтүүд HTTP/1.1-ээр дамжсан; шахалтыг ашиглаагүй, хандалтын логийг унтрааж, HTTPS сорилд ижил өөрөө гарын үсэг зурсан сертификат хэрэглэсэн.

Ийм орчинд гарсан секунд тутмын хүсэлтийн тоо нь интернетээр холбогддог VPS-ийн баталгаат хурд биш. Бодит сүлжээ, хост дээрх бусад ачаалал, шахалт, кэш болон арын аппликейшний хариулах хугацаа өөр байж болно. Caddy-ийн автомат HTTPS-ийг сорилын үеэр унтраасан тул хурдны хүснэгт сертификат авах, сунгах ажиллагааны нөлөөг хэмжээгүй; энэ ажлыг тусдаа удирдлагын давуу тал гэж үзэх ёстой.

Статик файл ба шинэ TLS холболтын ялагч яагаад өөр вэ?

Нэг КБ хэмжээтэй HTTPS файлыг Nginx секундэд 79 169, Caddy 29 449 удаа амжилттай үйлчилсэн. Файлын хэмжээ 100 КБ болоход Nginx-ийн үр дүн секундэд 14 998, Caddy-ийнх 12 785 хүсэлт болж, зөрүү мэдэгдэхүйц багассан. Тиймээс нэг жижиг файлын харьцааг бүх төрлийн контентод хамааруулж болохгүй: хэмжээ болон дамжуулах ажлын жин өөрчлөгдөхөд хоёр серверийн зөрүү мөн өөрчлөгджээ.

Хүсэлт бүрт шинэ TLS 1.3 холболт үүсгэсэн сорилд Caddy секундэд 4 274, Nginx 3 531 холболт боловсруулсан. Гэвч тэр сорилын p99 хоцролт Nginx-д 32.1 мс, Caddy-д 44.9 мс байв. Нэг секундэд дууссан холболтын тоо илүү байх нь хамгийн удаан хариулсан хүсэлтүүд ч хурдан байсан гэсэн үг биш; эдгээр нь өөр асуултад хариулдаг хэмжүүрүүд юм.

Ердийн үйлчилгээнд клиент холболтоо дахин ашиглаж болох учраас шинэ handshake-ийн сорил бүх HTTPS хүсэлтийн зан төлөвийг төлөөлөхгүй. Харин богино хугацаанд олон шинэ клиент холбогдох ачаалалд тэр үзүүлэлт ач холбогдолтой. Статик контент давамгайлсан үйлчилгээний хувьд файл үйлчлэх сорил илүү ойр, аппликейшний хариуг дамжуулдаг үйлчилгээний хувьд арын холболтын тохиргоо илүү чухал болно.

Reverse proxy дээр тохиргоо үр дүнг хэрхэн өөрчилсөн бэ?

Ерэн секундийн тогтвортой ачаалалд арын үйлчилгээний хаяг руу шууд заасан Nginx-ийн proxy_pass тохиргоо секундэд 627 амжилттай хүсэлт боловсруулж, нийт 44 005 алдаа өгсөн. Caddy-ийн анхны reverse_proxy тохиргоо секундэд 6 885 амжилттай хүсэлт боловсруулж, 74 алдаа өгчээ. Энэ нь серверүүдийн тогтмол хурдны эрэмбэ биш: тухайн Nginx тохиргоо арын TCP холболтыг дахин ашиглаагүй тул локал портын нөөцөө шавхсан.

Арийн үйлчилгээг upstream бүлгээр заасны дараа Nginx секундэд 22 153 амжилттай хүсэлт хүрч, алдаа бүртгэгдээгүй. Nginx-ийн upstream лавлагаанд 1.29.7-оос эхлэн ийм бүлгийн холболт хадгалах сан анхнаасаа идэвхтэй, харин өмнөх хувилбаруудад keepalive болон proxy-ийн холбогдох параметрийг тусад нь тохируулах шаардлагатайг заасан. Тиймээс ижил нэртэй proxy тохиргоо хувилбараасаа шалтгаалан өөр зан төлөвтэй байж болно.

Caddy арын холболтыг дахин ашигладаг ч нэг backend-д хадгалах сул холболтын үндсэн хязгаар 32 гэдгийг reverse_proxy лавлагаа тодорхойлдог. Туршилтад энэ санг 128 болгон өсгөхөд ерэн секундийн үр дүн секундэд 18 048 амжилттай хүсэлт хүрч, алдаа арилсан. Тухайн Nginx-ийн зассан тохиргооны дээд үр дүнг арын үйлчилгээ хязгаарлаж байсан тул эдгээр тооноос хоёр серверийн боломжит дээд хурдны зөрүүг тогтоох боломжгүй.

p99, CPU ба RAM жижиг VPS-д юу хэлж байна вэ?

Секундэд тогтмол 5 000 HTTPS proxy хүсэлт өгсөн тусдаа сорилд Nginx-ийн upstream тохиргооны p99 хоцролт 0.68 мс, Caddy-ийн анхны тохиргооных 2.52 мс байв. p99 гэдэг нь хүсэлтийн 99 хувь тухайн хугацаанд багтаж дууссаныг илэрхийлдэг. Энэ бол дээд хурдны сорилын p99 биш; тогтмол ачааллын үеийн удаан хариуг харуулсан хэмжүүр юм.

Мөн ачаалалд Nginx 0.23, Caddy 0.50 цөм ашиглажээ. Сул үеийн санах ойн хэрэглээ Nginx-д 3.6 MiB, Caddy-д 10.0 MiB; оргил хэрэглээ нь тус бүр 18.0 ба 44.8 MiB байсан. RAM-ийн дүнг контейнерийн хэмжүүрээр, хуудасны кэшийг оролцуулан авсан учир өөр VPS дээрх аппликейшний нийт хэрэглээтэй шууд адилтгаж болохгүй. CPU-ийн зөрүү цөмөө бусад процесстой хуваалцдаг машинд илүү мэдрэгдэх магадлалтай.

Caddy-ийн p99 зарим давталтад хэлбэлзсэн бол Nginx-ийнх тухайн сорилд тогтвортой байсныг хэмжилт тэмдэглэжээ. Тиймээс ганц p99 тоог бүх серверт үйлчлэх баталгаа гэж үзэхгүй, харин ижил ачаалалд хоёр тохиргооны хариу хэр өөр байсныг харуулах баримт гэж унших нь зөв. Хэрэглэгчид хүрэх нийт хугацаанд арын аппликейшн, сүлжээ болон хостын ачаалал бас нөлөөлнө.

HTTPS-ийн өдөр тутмын ажил хаана үлдэх вэ?

Caddy-ийн Automatic HTTPS баримтад тохиргоонд шаардлага хангасан домэйн байвал сертификат авах, сунгах, HTTP хүсэлтийг HTTPS рүү шилжүүлэх ажиллагаа автоматаар явагддаг гэж заасан. Нийтийн домэйны DNS бүртгэл сервер рүү заах, хэрэгтэй портууд нээлттэй байх, Caddy-ийн өгөгдлийн сан бичих боломжтой бөгөөд тогтвортой хадгалагдах нөхцөл шаардлагатай. Эдгээрийг бүрдүүлсэн жижиг VPS-д сертификатын хугацаа болон шилжүүлэлтийн дүрмийг гараар зохицуулах ажил цөөрнө.

Nginx-ийн SSL модулийн лавлагаа сертификат, хувийн түлхүүр, TLS протокол, session cache-ийг тус тусад нь тохируулах боломжийг харуулдаг. Энэ нь TLS-ийн нарийн тохиргоог хянах шаардлагатай үед хэрэгтэй. Харин эдгээр тохиргоо сертификат авах, хугацаанд нь сунгах ажиллагааг өөрсдөө гүйцэтгэдэггүй; Nginx ашиглагч үүнийг тусдаа хэрэгсэл эсвэл ажлын урсгалтай холбож зохион байгуулна.

Ингэснээр сонголтын өртөг нь зөвхөн серверийн хурд эсвэл лицензийн төлбөрөөр хэмжигдэхгүй. Сертификатын сунгалт, DNS ба сүлжээний нөхцөл, proxy-ийн арын холболтыг хэн хариуцах нь өдөр тутмын ажлын нэг хэсэг. Caddy энэ ажлын сертификаттай холбоотой хэсгийг автоматжуулдаг бол Nginx нарийн TLS тохиргоо болон хэмжилтэд харагдсан нөөцийн давуу талыг өгдөг.

Аль сонголт жижиг VPS-д тохирох вэ?

Шинээр цөөн домэйнтэй аппликейшн нийтэлж, HTTPS-ийн тохиргоо ба сунгалтад зарцуулах цагаа багасгахыг хүсвэл Caddy оновчтой эхлэл. Статик HTTPS хүсэлт ихтэй, цөмийн нөөц хязгаартай эсвэл тогтмол ачааллын p99 чухал үйлчилгээний хувьд Nginx-ийн давуу тал илүү шууд хамаарна. Аль хэдийн Nginx ажиллуулж, сертификатын удирдлага нь найдвартай автоматжсан бол зөвхөн энэ ялгаанаас болж сервер солих шаардлага үүсэхгүй.

Reverse proxy давамгайлсан үйлчилгээний шийдвэрийг серверийн нэрээс илүү арын холболтын дахин ашиглалт шийдэж мэднэ. Нийтлэгдсэн сорилд хоёр серверийн анхны тохиргоог өөрчилсний дараа алдаа, боловсруулсан хүсэлтийн тоо эрс өөр болсон. Иймээс жижиг VPS-ийн бодит сонголт нь өөрийн статик файл ба аппликейшний ачаалал, сул CPU, p99 хоцролт болон сертификатын удирдлагад зарцуулах ажлын нийлбэр юм.

Мөн уншаарай:

• OBS эсвэл Streamlabs: 1080p60 дээр CPU-ийн 11 пунктын зөрүү гарчээ
• Jira эсвэл Linear: хурдны ялгаа админы ажлыг нууж чадна
• Bootstrapping эсвэл VC: $1 саяын ARR хүрэхэд хурдны зөрүү эхэлдэг