Веб-апликациите сега се користат насекаде, а меѓу сите транспортни протоколи, HTTP го зазема лавовскиот дел. Кога ги проучуваат нијансите на развој на веб-апликации, повеќето луѓе посветуваат многу малку внимание на оперативниот систем каде што всушност работат овие апликации. Поделбата на развојот (Dev) и операциите (Ops) само ја влоши ситуацијата. Но, со подемот на културата на DevOps, програмерите стануваат одговорни за извршување на нивните апликации во облакот, па затоа е многу корисно за нив темелно да се запознаат со задниот дел на оперативниот систем. Ова е особено корисно ако се обидувате да распоредите систем за илјадници или десетици илјади истовремени врски.

Ограничувањата во веб-услугите се многу слични на оние во другите апликации. Без разлика дали се работи за балансери на оптоварување или сервери на бази на податоци, сите овие апликации имаат слични проблеми во опкружување со високи перформанси. Разбирањето на овие фундаментални ограничувања и како да ги надминете воопшто ќе ви помогне да ги оцените перформансите и приспособливоста на вашите веб-апликации.

Ја пишувам оваа серија написи како одговор на прашања од млади програмери кои сакаат да станат добро информирани системски архитекти. Невозможно е јасно да се разберат техниките за оптимизација на апликации на Линукс без да се нурне во основите за тоа како тие работат на ниво на оперативен систем. Иако има многу видови на апликации, во оваа серија сакам да истражувам апликации базирани на веб наместо десктоп апликации како што се прелистувач или уредувач на текст. Овој материјал е наменет за програмери и архитекти кои сакаат да разберат како функционираат програмите на Linux или Unix и како да ги структурираат за високи перформанси.

Линукс е сервер соба оперативен систем, а најчесто вашите апликации работат на овој ОС. Иако велам „Linux“, најчесто можете безбедно да претпоставите дека мислам на сите оперативни системи слични на Unix воопшто. Сепак, не го тестирав придружниот код на други системи. Значи, ако сте заинтересирани за FreeBSD или OpenBSD, вашите резултати може да се разликуваат. Кога пробувам нешто специфично за Linux, го истакнувам.

Иако можете да го користите ова знаење за да создадете апликација од нула и таа ќе биде совршено оптимизирана, најдобро е да не го правите тоа. Ако напишете нов веб-сервер во C или C++ за деловната апликација на вашата организација, ова може да биде вашиот последен ден на работа. Сепак, познавањето на структурата на овие апликации ќе помогне во изборот на постоечките програми. Ќе можете да споредувате системи засновани на процеси со системи засновани на нишки, како и системи засновани на настани. Ќе разберете и цените зошто Nginx работи подобро од Apache httpd, зошто апликацијата Python базирана на Tornado може да опслужува повеќе корисници во споредба со апликацијата Python базирана на Џанго.

ZeroHTTPd: Алатка за учење

ZeroHTTPd е веб-сервер што го напишав од почеток во C како алатка за учење. Нема надворешни зависности, вклучително и пристап до Redis. Ние ги водиме нашите сопствени процедури за Редис. Погледнете подолу за повеќе детали.

Иако би можеле долго да разговараме за теоријата, нема ништо подобро од пишување код, негово извршување и споредување на сите архитектури на серверот една со друга. Ова е најочигледниот метод. Затоа, ќе напишеме едноставен веб-сервер ZeroHTTPd користејќи го секој модел: базиран на процес, базиран на нишки и базиран на настани. Ајде да го провериме секој од овие сервери и да видиме како тие функционираат во споредба еден со друг. ZeroHTTPd се имплементира во една датотека C. Серверот базиран на настани вклучува уташ, одлична имплементација на хаш табела која доаѓа во една датотека со заглавие. Во други случаи, нема зависности, за да не се комплицира проектот.

Има многу коментари во кодот за да ви помогнат да разберете. Бидејќи е едноставен веб-сервер во неколку линии код, ZeroHTTPd е исто така минимална рамка за развој на веб. Има ограничена функционалност, но е способен да опслужува статични датотеки и многу едноставни „динамични“ страници. Морам да кажам дека ZeroHTTPd е добар за учење како да креирате Линукс апликации со високи перформанси. Во голема мера, повеќето веб-услуги чекаат барања, ги проверуваат и обработуваат. Ова е токму она што ќе го направи ZeroHTTPd. Ова е алатка за учење, а не за производство. Не е одличен во справувањето со грешки и веројатно нема да се пофали со најдобрите безбедносни практики (о, да, користев strcpy) или паметните трикови на јазикот C. Но, се надевам дека добро си ја врши работата.

Почетна страница ZeroHTTPd. Може да емитува различни типови на датотеки, вклучувајќи слики

Апликација за книга за гости

Современите веб-апликации обично не се ограничени на статични датотеки. Тие имаат сложени интеракции со различни бази на податоци, кешови, итн. Така, ќе создадеме едноставна веб-апликација наречена „Книга за гости“ каде што посетителите оставаат записи под нивните имиња. Записите во продавниците за гостински книги беа оставени порано. На дното на страницата има и бројач за посетители.

Веб апликација „Книга за гости“ ZeroHTTPd

Бројачот на посетители и записите во книгата за гости се зачувани во Redis. За комуникација со Редис се спроведуваат сопствени процедури, тие не зависат од надворешната библиотека. Не сум голем обожавател на објавување код за домашна подготовка кога има јавно достапни и добро тестирани решенија. Но, целта на ZeroHTTPd е да ги проучува перформансите на Линукс и пристапот до надворешните услуги, додека опслужувањето на барањата за HTTP има сериозно влијание врз перформансите. Мора целосно да ги контролираме комуникациите со Redis во секоја наша архитектура на серверот. Во некои архитектури користиме блокирачки повици, во други користиме процедури базирани на настани. Користењето на надворешна библиотека на клиенти на Redis нема да ја обезбеди оваа контрола. Дополнително, нашиот мал клиент Redis извршува само неколку функции (добивање, поставување и зголемување на клучот; добивање и додавање на низа). Покрај тоа, протоколот Redis е исклучително елегантен и едноставен. Дури и не треба посебно да го учите. Самиот факт дека протоколот ја врши целата работа во околу сто линии код покажува колку е добро осмислен.

Следната слика покажува што прави апликацијата кога клиентот (прелистувачот) бара /guestbookURL.

Како функционира апликацијата за книга за гости

Кога треба да се издаде страница од книгата за гости, има еден повик до датотечниот систем за читање на шаблонот во меморијата и три мрежни повици до Redis. Датотеката со шаблон содржи најголем дел од содржината на HTML за страницата на сликата од екранот погоре. Има и посебни места за динамички дел од содржината: објави и бројач на посетители. Ги добиваме од Редис, ги вметнуваме на страницата и му обезбедуваме на клиентот целосно формирана содржина. Третиот повик до Redis може да се избегне бидејќи Redis ја враќа новата клучна вредност кога се зголемува. Сепак, за нашиот сервер, кој има асинхрона архитектура базирана на настани, многу мрежни повици се добар тест за цели на учење. Така, ја отфрламе повратната вредност на Redis на бројот на посетители и ја бараме со посебен повик.

Архитектури на серверот ZeroHTTPd

Градиме седум верзии на ZeroHTTPd со иста функционалност, но различни архитектури:

• Итеративен
• Форк сервер (еден дете процес по барање)
• Пред-форк сервер (пред-форкинг на процеси)
• Сервер со нишки за извршување (една нишка по барање)
• Сервер со креирање пред нишка
• Заснована на архитектура poll()
• Заснована на архитектура epoll

Ние ги мериме перформансите на секоја архитектура со вчитување на серверот со HTTP барања. Но, кога се споредуваат високо паралелни архитектури, бројот на барања се зголемува. Ние тестираме три пати и го пресметуваме просекот.

Методологија на тестирање

Поставување за тестирање на оптоварување ZeroHTTPd

Важно е при извршувањето на тестовите, сите компоненти да не работат на иста машина. Во овој случај, ОС има дополнителни трошоци за распоред бидејќи компонентите се натпреваруваат за процесорот. Мерењето на оперативниот систем на секоја од избраните архитектури на серверот е една од најважните цели на оваа вежба. Додавањето повеќе променливи ќе стане штетно за процесот. Затоа, поставката на сликата погоре функционира најдобро.

Што прави секој од овие сервери?

• load.unixism.net: Ова е местото каде што трчаме ab, алатката Apache Benchmark. Го генерира оптоварувањето потребно за тестирање на архитектурите на нашите сервери.
• nginx.unixism.net: Понекогаш сакаме да извршиме повеќе од една инстанца на серверска програма. За да го направите ова, серверот Nginx со соодветни поставки работи како балансер на оптоварување од кој доаѓа ab на процесите на нашиот сервер.
• zerohttpd.unixism.net: Овде ги извршуваме нашите серверски програми на седум различни архитектури, една по една.
• redis.unixism.net: Овој сервер го извршува демонот Redis, каде што се зачувуваат записите во книгата на гости и бројачите на посетители.

Сите сервери работат на исто јадро на процесорот. Идејата е да се проценат максималните перформанси на секоја архитектура. Бидејќи сите серверски програми се тестираат на ист хардвер, ова е основна линија за споредба. Моето тест поставување се состои од виртуелни сервери изнајмени од Digital Ocean.

Што мериме?

Можете да измерите различни индикатори. Ние ги оценуваме перформансите на секоја архитектура во дадена конфигурација со вчитување на серверите со барања на различни нивоа на паралелизам: оптоварувањето расте од 20 на 15 истовремени корисници.

Резултати од тестот

Следниот графикон ги прикажува перформансите на серверите на различни архитектури на различни нивоа на паралелизам. y-оската е бројот на барања во секунда, а x-оската е паралелни врски.

Подолу е табела со резултатите.

барања во секунда

паралелизам
итеративен
вилушка
пред-вилушка
стриминг
пред-стриминг
внатре
епол

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 симултани барања ни остануваат само двајца играчи: пред-форк и епол. Како што се зголемува оптоварувањето, серверот базиран на анкети работи полошо од стриминг. Архитектурата на нишката пред создавањето е достоен конкурент на епол, доказ за тоа колку добро кернелот на Линукс закажува голем број нишки.

Изворниот код на ZeroHTTPd

Изворниот код на ZeroHTTPd тука. За секоја архитектура има посебен директориум.

ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking ├──. 04_ нишки │ ├── main.c ├── 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └─├ └──├─── main.c ─ ├── индекс .html │ └── смокинг . png └── шаблони └── книга за гости └── индекс.html

Покрај седумте директориуми за сите архитектури, има уште два во директориумот на највисоко ниво: јавни и шаблони. Првата ја содржи датотеката index.html и сликата од првата слика од екранот. Можете да ставите други датотеки и папки таму, а ZeroHTTPd треба да ги опслужува тие статични датотеки без никакви проблеми. Ако патеката во прелистувачот се совпаѓа со патеката во јавната папка, тогаш ZeroHTTPd ја бара датотеката index.html во овој директориум. Содржината за книгата за гости се генерира динамично. Има само почетна страница, а нејзината содржина се заснова на датотеката „шаблони/книга за гости/index.html“. ZeroHTTPd лесно додава динамични страници за проширување. Идејата е дека корисниците можат да додаваат шаблони во овој директориум и да го прошират ZeroHTTPd по потреба.

За да ги изградите сите седум сервери, стартувајте make all од директориумот на највисоко ниво - и сите градби ќе се појават во овој директориум. Извршните датотеки бараат директориуми за јавни и шаблони во директориумот од кој се стартуваат.

Linux API

Не треба да сте добро упатени во Linux API за да ги разберете информациите во оваа серија на написи. Сепак, препорачувам да прочитате повеќе на оваа тема; има многу референтни ресурси на Интернет. Иако ќе допреме на неколку категории на Linux API, нашиот фокус ќе биде првенствено на процесите, нишките, настаните и мрежниот стек. Покрај книгите и написите за Linux API, препорачувам и читање мана за системски повици и користени функции на библиотеката.

Перформанси и приспособливост

Една забелешка за перформансите и приспособливоста. Теоретски, нема врска меѓу нив. Може да имате веб-услуга што работи многу добро, со време на одговор од неколку милисекунди, но воопшто не се зголемува. Слично на тоа, може да има веб-апликација со слаба работа на која и се потребни неколку секунди за да одговори, но се намалува за десетици за да се справи со десетици илјади истовремени корисници. Сепак, комбинацијата на високи перформанси и приспособливост е многу моќна комбинација. Апликациите со високи перформанси генерално ги користат ресурсите умерено и на тој начин ефикасно опслужуваат повеќе истовремени корисници на серверот, намалувајќи ги трошоците.

CPU и I/O задачи

Конечно, во компјутерите секогаш постојат два можни типа на задачи: за влез/излез и процесор. Примање барања преку Интернет (мрежна I/O), сервисирање на датотеки (мрежна и диск В/И), комуникација со базата на податоци (мрежа и диск I/O) се сите I/O активности. Некои барања за базата на податоци може да бидат малку интензивни на процесорот (сортирање, просечен милион резултати итн.). Повеќето веб-апликации се ограничени со максималниот можен влез/излез, а процесорот ретко се користи со полн капацитет. Кога ќе видите дека некоја I/O задача користи многу процесор, тоа е најверојатно знак за лоша архитектура на апликацијата. Ова може да значи дека ресурсите на процесорот се трошат на управување со процесите и префрлување контекст - и тоа не е сосема корисно. Ако правите нешто како обработка на слики, конверзија на аудио датотеки или машинско учење, тогаш апликацијата бара моќни ресурси на процесорот. Но, за повеќето апликации тоа не е случај.

Дознајте повеќе за архитектурите на серверот

1. Дел I: Итеративна архитектура
2. Дел II. Форк сервери
3. Дел III. Пред-форк сервери
4. Дел IV. Сервери со нишки за извршување
5. Дел V. Сервери со претходно навој
6. Дел VI. Архитектура базирана на Пол
7. Дел VII. архитектура базирана на епол

Извор: www.habr.com