Линукс сүлжээний програмын гүйцэтгэл. Оршил

Вэб програмууд одоо хаа сайгүй ашиглагдаж байгаа бөгөөд бүх тээврийн протоколуудын дунд HTTP хамгийн их хувийг эзэлдэг. Вэб програм хөгжүүлэлтийн нарийн ширийн зүйлийг судлахдаа ихэнх хүмүүс эдгээр програмууд ажиллаж байгаа үйлдлийн системд маш бага анхаарал хандуулдаг. Хөгжил (Dev) болон үйл ажиллагаа (Ops) хоёрыг салгаснаар нөхцөл байдлыг улам дордуулсан. Гэвч DevOps соёл хөгжихийн хэрээр хөгжүүлэгчид өөрсдийн аппликешнүүдийг үүлэн дээр ажиллуулах үүрэгтэй болж байгаа тул үйлдлийн системийн арын хэсгийг сайтар мэддэг байх нь тэдэнд маш хэрэгтэй юм. Хэрэв та мянга мянган эсвэл хэдэн арван мянган нэгэн зэрэг холболт хийх системийг байрлуулах гэж байгаа бол энэ нь ялангуяа ашигтай байдаг.

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

Би сайн мэдээлэлтэй системийн архитектор болох хүсэлтэй залуу хөгжүүлэгчдийн асуултын хариуд энэхүү цуврал нийтлэлийг бичиж байна. Линуксийн хэрэглээний оновчлолын арга техникийг үйлдлийн системийн түвшинд хэрхэн ажилладагийг ойлгохгүйгээр тодорхой ойлгох боломжгүй юм. Хэдийгээр олон төрлийн програмууд байдаг ч энэ цувралд би хөтөч, текст засварлагч гэх мэт ширээний программ гэхээсээ илүү вэб дээр суурилсан програмуудыг судлахыг хүсч байна. Энэхүү материал нь Линукс эсвэл Юникс програмууд хэрхэн ажилладаг, тэдгээрийг хэрхэн өндөр гүйцэтгэлтэй болгох талаар ойлгохыг хүсдэг хөгжүүлэгчид болон архитекторуудад зориулагдсан болно.

Линукс бол серверийн өрөө үйлдлийн систем, ихэвчлэн таны програмууд энэ үйлдлийн систем дээр ажилладаг. Хэдийгээр би "Линукс" гэж хэлдэг ч ихэнх тохиолдолд та бүх Unix-тэй төстэй үйлдлийн системийг ерөнхийд нь хэлж байна гэж таамаглаж болно. Гэсэн хэдий ч би дагалдах кодыг бусад систем дээр туршиж үзээгүй. Тиймээс, хэрэв та FreeBSD эсвэл OpenBSD-г сонирхож байгаа бол таны үр дүн өөр байж болно. Би Linux-д зориулсан ямар нэг зүйлийг туршиж үзэхэд үүнийг зааж өгдөг.

Хэдийгээр та энэ мэдлэгийг ашиглан програмыг эхнээс нь бүтээх боломжтой бөгөөд энэ нь төгс оновчтой байх болно, гэхдээ үүнийг хийхгүй байх нь дээр. Хэрэв та байгууллагынхаа бизнесийн програмд ​​зориулж C эсвэл C++ хэлээр шинэ вэб сервер бичвэл энэ нь таны ажлын сүүлийн өдөр байж магадгүй юм. Гэсэн хэдий ч эдгээр програмуудын бүтцийг мэдэх нь одоо байгаа програмуудыг сонгоход тусална. Та процесст суурилсан системийг урсгалд суурилсан системүүд болон үйл явдалд суурилсан системүүдтэй харьцуулах боломжтой болно. Та Nginx яагаад Apache httpd-ээс илүү сайн ажилладаг, яагаад Tornado дээр суурилсан Python програм нь Django-д суурилсан Python програмтай харьцуулахад илүү олон хэрэглэгчдэд үйлчлэх боломжтойг ойлгож, үнэлэх болно.

ZeroHTTPd: Сурах хэрэгсэл

ZeroHTTPd бол миний Си хэл дээр эхнээс нь заах хэрэгсэл болгон бичсэн вэб сервер юм. Энэ нь Redis-д хандах зэрэг гадны хамааралгүй. Бид өөрсдийн Redis процедурыг хэрэгжүүлдэг. Дэлгэрэнгүй мэдээллийг доороос үзнэ үү.

Хэдийгээр бид онолын талаар урт удаан ярилцаж болох ч код бичих, ажиллуулах, серверийн бүх архитектурыг бие биетэйгээ харьцуулахаас илүү сайн зүйл байхгүй. Энэ бол хамгийн ойлгомжтой арга юм. Тиймээс бид загвар бүрийг ашиглан энгийн ZeroHTTPd вэб сервер бичих болно: процесс дээр суурилсан, урсгалд суурилсан, үйл явдалд суурилсан. Эдгээр серверүүд тус бүрийг шалгаж, бие биентэйгээ харьцуулахад хэрхэн ажилладагийг харцгаая. ZeroHTTPd нь нэг С файлд хэрэгждэг.Үйл явдалд суурилсан серверт орно ухаш, нэг толгой файлд ирдэг гайхалтай хэш хүснэгтийн хэрэгжилт. Бусад тохиолдолд төслийг хүндрүүлэхгүйн тулд ямар ч хамаарал байхгүй.

Кодод ойлгоход тань туслах олон тайлбар бий. Хэдэн мөр кодын энгийн вэб сервер болох ZeroHTTPd нь вэб хөгжүүлэлтийн хамгийн бага хүрээ юм. Энэ нь хязгаарлагдмал функцтэй боловч статик файлууд болон маш энгийн "динамик" хуудсуудад үйлчлэх чадвартай. ZeroHTTPd нь өндөр хүчин чадалтай Линукс програмуудыг хэрхэн бүтээх талаар сурахад тохиромжтой гэдгийг би хэлэх ёстой. Ерөнхийдөө ихэнх вэб үйлчилгээ нь хүсэлтийг хүлээж, шалгаж, боловсруулдаг. Үүнийг ZeroHTTPd яг хийх болно. Энэ бол үйлдвэрлэл биш, суралцах хэрэгсэл юм. Энэ нь алдаатай ажиллахад тийм ч сайн биш бөгөөд аюулгүй байдлын шилдэг туршлагуудаараа сайрхах магадлал багатай (өө тийм, би ашигласан strcpy) эсвэл Си хэлний ухаалаг заль мэх.Гэхдээ энэ нь үүргээ сайн биелүүлнэ гэж найдаж байна.

Линукс сүлжээний програмын гүйцэтгэл. Оршил
ZeroHTTPd нүүр хуудас. Энэ нь зураг гэх мэт өөр өөр төрлийн файлуудыг гаргаж авах боломжтой

Зочны дэвтэр програм

Орчин үеийн вэб програмууд нь ихэвчлэн статик файлаар хязгаарлагдахгүй. Тэд янз бүрийн мэдээллийн сан, кэш гэх мэт нарийн төвөгтэй харилцан үйлчлэлтэй байдаг. Тиймээс бид "Зочин дэвтэр" нэртэй энгийн вэб програмыг бий болгох бөгөөд зочдод өөрсдийн нэрийн дор оруулга үлдээдэг. Зочны номонд өмнө нь үлдээсэн бичлэгүүд хадгалагдана. Мөн хуудасны доод талд зочдын тоолуур байдаг.

Линукс сүлжээний програмын гүйцэтгэл. Оршил
"Зочин ном" ZeroHTTPd вэб програм

Зочны тоолуур болон зочны дэвтрийн оруулгуудыг Redis-д хадгалдаг. Редистэй харилцахдаа өөрийн процедурыг хэрэгжүүлдэг бөгөөд тэдгээр нь гадаад номын сангаас хамаардаггүй. Олон нийтэд нээлттэй, сайн туршсан шийдлүүд байгаа үед би homebrew кодыг гаргах тийм ч их шүтэн бишрэгч биш. Гэхдээ ZeroHTTPd-ийн зорилго нь Linux-ийн гүйцэтгэл, гадаад үйлчилгээнд хандах хандалтыг судлах бөгөөд HTTP хүсэлтэд үйлчлэх нь гүйцэтгэлд ноцтой нөлөөлдөг. Бид серверийн архитектур бүрт Redis-тай харилцах харилцааг бүрэн хянах ёстой. Зарим архитектурт бид хаах дуудлагыг ашигладаг бол заримд нь үйл явдалд суурилсан процедурыг ашигладаг. Гадаад Redis клиент номын санг ашиглах нь энэ хяналтыг хангахгүй. Нэмж дурдахад, манай бяцхан Redis үйлчлүүлэгч хэдхэн функцийг гүйцэтгэдэг (түлхүүр авах, тохируулах, нэмэгдүүлэх; массив авах, нэмэх). Нэмж дурдахад Redis протокол нь маш гоёмсог бөгөөд энгийн байдаг. Та үүнийг тусгайлан заах шаардлагагүй. Протокол нь зуу орчим мөр кодын дотор бүх ажлыг гүйцэтгэдэг нь түүнийг хэр сайн бодож байгааг харуулж байна.

Дараах зураг нь үйлчлүүлэгч (хөтөч) хүсэлт гаргах үед програм юу хийдгийг харуулж байна /guestbookURL.

Линукс сүлжээний програмын гүйцэтгэл. Оршил
Зочны дэвтэр програм хэрхэн ажилладаг

Зочны номын хуудас гаргах шаардлагатай үед загварыг санах ойд унших файлын систем рүү нэг дуудлага, Redis руу гурван сүлжээний дуудлага ирдэг. Загварын файл нь дээрх дэлгэцийн агшин дахь хуудасны ихэнх HTML контентыг агуулна. Мөн агуулгын динамик хэсэгт зориулсан тусгай орлуулагч байдаг: нийтлэлүүд болон зочдын тоолуур. Бид Redis-аас тэдгээрийг хүлээн авч, хуудсанд оруулж, үйлчлүүлэгчийг бүрэн агуулгаар нь хангадаг. Редис нь нэмэгдсэн үед шинэ түлхүүр утгыг буцаадаг тул Redis руу гурав дахь дуудлага хийхээс зайлсхийх боломжтой. Гэсэн хэдий ч үйл явдалд суурилсан асинхрон архитектуртай манай серверийн хувьд олон тооны сүлжээний дуудлага нь суралцах зорилгоор сайн тест болдог. Тиймээс бид зочдын тооны Redis-ийн буцах утгыг хасч, тусдаа дуудлагаар асуудаг.

Серверийн архитектур ZeroHTTPd

Бид ижил ажиллагаатай боловч өөр өөр архитектуртай ZeroHTTPd-ийн долоон хувилбарыг бүтээж байна.

  • Давталттай
  • Сэрээ сервер (хүсэлт бүрт нэг хүүхэд процесс)
  • Урьдчилан салаа сервер (процессыг урьдчилан салаалах)
  • Гүйцэтгэх хэлхээтэй сервер (хүсэлт бүрт нэг урсгал)
  • Урьдчилан урсгал үүсгэсэн сервер
  • Архитектурт суурилсан poll()
  • Архитектурт суурилсан epoll

Бид серверийг HTTP хүсэлтээр ачаалах замаар архитектур бүрийн гүйцэтгэлийг хэмждэг. Гэхдээ маш зэрэгцээ архитектурыг харьцуулах үед асуулгын тоо нэмэгддэг. Бид гурван удаа тест хийж, дундажийг тооцдог.

Туршилтын арга зүй

Линукс сүлжээний програмын гүйцэтгэл. Оршил
ZeroHTTPd ачааллын туршилтын тохиргоо

Туршилтыг ажиллуулахдаа бүх бүрэлдэхүүн хэсгүүд нэг машин дээр ажиллахгүй байх нь чухал юм. Энэ тохиолдолд бүрэлдэхүүн хэсгүүд нь CPU-ийн төлөө өрсөлдөж байгаа тул үйлдлийн систем нь нэмэлт хуваарийн зардал гаргадаг. Сонгосон серверийн архитектур бүрийн үйлдлийн системийн нэмэлт зардлыг хэмжих нь энэ дасгалын хамгийн чухал зорилтуудын нэг юм. Илүү олон хувьсагч нэмэх нь үйл явцад сөргөөр нөлөөлнө. Тиймээс дээрх зураг дээрх тохиргоо хамгийн сайн ажилладаг.

Эдгээр сервер бүр юу хийдэг вэ?

  • load.unixism.net: Энд л бид гүйдэг ab, Apache Benchmark хэрэгсэл. Энэ нь манай серверийн архитектурыг туршихад шаардлагатай ачааллыг бий болгодог.
  • nginx.unixism.net: Заримдаа бид серверийн програмын нэгээс олон хувилбарыг ажиллуулахыг хүсдэг. Үүнийг хийхийн тулд тохирох тохиргоотой Nginx сервер нь ачааллын тэнцвэржүүлэгчийн үүрэг гүйцэтгэдэг ab манай серверийн процессууд.
  • zerohttpd.unixism.net: Энд бид серверийн програмуудаа долоон өөр архитектур дээр нэг нэгээр нь ажиллуулдаг.
  • redis.unixism.net: Энэ сервер нь Redis демоныг ажиллуулдаг бөгөөд энд зочны дэвтэр болон зочдын тоолуур хадгалагддаг.

Бүх серверүүд ижил процессорын цөм дээр ажилладаг. Архитектур бүрийн хамгийн дээд гүйцэтгэлийг үнэлэх санаа юм. Бүх серверийн программуудыг нэг техник хангамж дээр туршиж үздэг тул энэ нь харьцуулах суурь үзүүлэлт юм. Миний туршилтын тохиргоо нь Digital Ocean-аас түрээсэлсэн виртуал серверүүдээс бүрддэг.

Бид юу хэмжиж байна вэ?

Та янз бүрийн үзүүлэлтүүдийг хэмжиж болно. Бид өгөгдсөн тохиргооны архитектур бүрийн гүйцэтгэлийг янз бүрийн түвшний параллелизмын хүсэлт бүхий серверүүдийг ачаалах замаар үнэлдэг: ачаалал 20-15 зэрэгцэн ажилладаг хэрэглэгчдэд нэмэгддэг.

Тестийн үр дүн

Дараах диаграм нь параллелизмын янз бүрийн түвшний өөр өөр архитектур дээрх серверүүдийн гүйцэтгэлийг харуулж байна. Y тэнхлэг нь секундэд ирэх хүсэлтийн тоо, x тэнхлэг нь зэрэгцээ холболтууд юм.

Линукс сүлжээний програмын гүйцэтгэл. Оршил

Линукс сүлжээний програмын гүйцэтгэл. Оршил

Линукс сүлжээний програмын гүйцэтгэл. Оршил

Үр дүнгийн хүснэгтийг доор харуулав.

секунд тутамд хүсэлт

параллелизм
давталттай
сэрээ
урьдчилан сэрээ
урсгал
урьдчилсан дамжуулалт
санал асуулга
epoll

20
7
112
2100
1800
2250
1900
2050

50
7
190
2200
1700
2200
2000
2000

100
7
245
2200
1700
2200
2150
2100

200
7
330
2300
1750
2300
2200
2100

300
-
380
2200
1800
2400
2250
2150

400
-
410
2200
1750
2600
2000
2000

500
-
440
2300
1850
2700
1900
2212

600
-
460
2400
1800
2500
1700
2519

700
-
460
2400
1600
2490
1550
2607

800
-
460
2400
1600
2540
1400
2553

900
-
460
2300
1600
2472
1200
2567

1000
-
475
2300
1700
2485
1150
2439

1500
-
490
2400
1550
2620
900
2479

2000
-
350
2400
1400
2396
550
2200

2500
-
280
2100
1300
2453
490
2262

3000
-
280
1900
1250
2502
том тархалт
2138

5000
-
том тархалт
1600
1100
2519
-
2235

8000
-
-
1200
том тархалт
2451
-
2100

10
-
-
том тархалт
-
2200
-
2200

11
-
-
-
-
2200
-
2122

12
-
-
-
-
970
-
1958

13
-
-
-
-
730
-
1897

14
-
-
-
-
590
-
1466

15
-
-
-
-
532
-
1281

График болон хүснэгтээс харахад нэгэн зэрэг 8000 гаруй хүсэлт гаргавал бидэнд хоёрхон тоглогч үлдсэн нь урьдчилсан сэрээ болон epoll юм. Ачаалал ихсэх тусам санал асуулгад суурилсан сервер нь урсгалтай серверээс муу ажилладаг. Thread-pro-creation архитектур нь epoll-ийн зохистой өрсөлдөгч бөгөөд Линукс цөм нь олон тооны хэлхээг хэр сайн хуваарьдаг болохыг гэрчилж байна.

ZeroHTTPd эх код

ZeroHTTPd эх код энд. Архитектур бүрийн хувьд тусдаа лавлах байдаг.

ZeroHTTPd │ ├── 01_давталт │ ├── main.c ├── 02_салаа │ ├── main.c ├── 03_preforking үндсэн ──c.─c. 04_ урсгалтай │ ├── үндсэн.c ├── 05_prethreading │ ├── main.c ├── 06_санал асуулга │ ├── main.c ├── 07_epoll │ └── main.c │ └── main.c ── олон нийтэд нээлттэй болгох ── ├── индекс .html │ └── tux . png └── загварууд └── зочны дэвтэр └── index.html

Бүх архитектурт зориулсан долоон лавлахаас гадна дээд түвшний лавлах хоёр өөр байдаг: public болон templates. Эхнийх нь index.html файл болон эхний дэлгэцийн агшингийн зургийг агуулна. Та тэнд өөр файл, хавтас байрлуулж болох бөгөөд ZeroHTTPd нь тэдгээр статик файлуудыг ямар ч асуудалгүйгээр ажиллуулах ёстой. Хөтөч дэх зам нь нийтийн хавтсанд байгаа замтай таарч байвал ZeroHTTPd энэ директороос index.html файлыг хайдаг. Зочны номын агуулгыг динамикаар үүсгэдэг. Энэ нь зөвхөн нүүр хуудастай бөгөөд агуулга нь 'templates/guestbook/index.html' файл дээр суурилдаг. ZeroHTTPd нь өргөтгөлийн динамик хуудсыг хялбархан нэмдэг. Гол санаа нь хэрэглэгчид энэ санд загвар нэмж, шаардлагатай бол ZeroHTTPd-г өргөтгөх боломжтой.

Бүх долоон серверийг бүтээхийн тулд ажиллуулна уу make all дээд түвшний лавлахаас - бүх бүтээцүүд энэ директорт гарч ирнэ. Гүйцэтгэх боломжтой файлууд нь эхлүүлсэн лавлах дотроос нийтийн болон загварын лавлахуудыг хайдаг.

Linux API

Энэ цуврал нийтлэл дэх мэдээллийг ойлгохын тулд та Linux API-г сайн мэддэг байх шаардлагагүй. Гэсэн хэдий ч би энэ сэдвээр илүү ихийг уншихыг зөвлөж байна, Интернет дээр олон лавлах эх сурвалжууд байдаг. Хэдийгээр бид Linux API-ийн хэд хэдэн категорийн талаар ярих боловч голчлон процесс, урсгал, үйл явдал, сүлжээний стек дээр анхаарлаа хандуулах болно. Би Linux API-ийн тухай ном, нийтлэлээс гадна системийн дуудлага болон ашигласан номын сангийн функцүүдэд зориулсан мана уншихыг зөвлөж байна.

Гүйцэтгэл ба өргөтгөх чадвар

Гүйцэтгэл болон өргөтгөх чадварын талаар нэг тэмдэглэл. Онолын хувьд тэдний хооронд ямар ч холбоо байхгүй. Та маш сайн ажилладаг вэб үйлчилгээтэй байж болно, хариу өгөх хугацаа хэдхэн миллисекунд байдаг, гэхдээ энэ нь огт масштабтай байдаггүй. Үүний нэгэн адил, хариу өгөхөд хэдхэн секунд зарцуулдаг муу гүйцэтгэлтэй вэб програм байж болох ч хэдэн арван мянган хэрэглэгчдийг зохицуулахын тулд хэдэн арван хувиар томордог. Гэсэн хэдий ч өндөр гүйцэтгэл, өргөтгөх чадварын хослол нь маш хүчирхэг хослол юм. Өндөр гүйцэтгэлтэй программууд нь ерөнхийдөө нөөцийг хэмнэлттэй ашигладаг бөгөөд ингэснээр сервер дээр илүү олон хэрэглэгчдэд нэгэн зэрэг үр дүнтэй үйлчилж, зардлыг бууруулдаг.

CPU болон I/O даалгавар

Эцэст нь хэлэхэд, тооцоолоход үргэлж хоёр төрлийн даалгавар байдаг: I/O болон CPU. Интернэтээр хүсэлт хүлээн авах (сүлжээний оролт гаралт), файлд үйлчлэх (сүлжээ ба дискний оролт гаралт), мэдээллийн сантай харилцах (сүлжээ ба дискний оролт гаралт) нь бүгд оролт гаралтын үйл ажиллагаа юм. Өгөгдлийн сангийн зарим асуулга нь CPU-ийн ачаалал ихтэй байж болно (ангилах, дунджаар нэг сая үр дүн гэх мэт). Ихэнх вэб програмууд нь боломжит I/O-оор хязгаарлагддаг бөгөөд процессорыг бүрэн хүчин чадлаараа ашиглах нь ховор байдаг. Зарим оролт гаралтын ажил их хэмжээний CPU ашиглаж байгааг харахад энэ нь програмын архитектур муу байгаагийн шинж юм. Энэ нь процессын удирдлага болон контекст шилжихэд CPU-ийн нөөцийг дэмий үрж байна гэсэн үг бөгөөд энэ нь тийм ч ашигтай биш юм. Хэрэв та зураг боловсруулах, аудио файл хөрвүүлэх эсвэл машин сурах гэх мэт зүйл хийж байгаа бол програм нь хүчирхэг CPU нөөц шаарддаг. Гэхдээ ихэнх програмуудын хувьд энэ нь тийм биш юм.

Серверийн архитектурын талаар илүү ихийг олж мэдэх

  1. I хэсэг: Давталтын архитектур
  2. II хэсэг. Сэрээ серверүүд
  3. III хэсэг. Урьдчилан сэргийлэх серверүүд
  4. IV хэсэг. Гүйцэтгэлийн урсгалтай серверүүд
  5. V хэсэг. Урьдчилан дамжуулсан серверүүд
  6. VI хэсэг. Пол дээр суурилсан архитектур
  7. VII хэсэг. epoll дээр суурилсан архитектур

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх