Уеб приложенията вече се използват навсякъде и сред всички транспортни протоколи HTTP заема лъвския дял. Когато изучават нюансите на разработката на уеб приложения, повечето хора обръщат много малко внимание на операционната система, където тези приложения действително се изпълняват. Разделянето на разработката (Dev) и операциите (Ops) само влоши ситуацията. Но с възхода на DevOps културата, разработчиците стават отговорни за изпълнението на своите приложения в облака, така че е много полезно за тях да се запознаят подробно с бекенда на операционната система. Това е особено полезно, ако се опитвате да разположите система за хиляди или десетки хиляди едновременни връзки.

Ограниченията в уеб услугите са много подобни на тези в други приложения. Независимо дали става въпрос за балансьори на натоварването или сървъри на бази данни, всички тези приложения имат подобни проблеми в среда с висока производителност. Разбирането на тези основни ограничения и как да ги преодолеете като цяло ще ви помогне да оцените производителността и скалируемостта на вашите уеб приложения.

Пиша тази поредица от статии в отговор на въпроси от млади разработчици, които искат да станат добре информирани системни архитекти. Невъзможно е ясно да се разберат техниките за оптимизиране на Linux приложения, без да се потопите в основите на това как работят на ниво операционна система. Въпреки че има много видове приложения, в тази поредица искам да изследвам уеб базирани приложения, а не настолни приложения като браузър или текстов редактор. Този материал е предназначен за разработчици и архитекти, които искат да разберат как работят Linux или Unix програмите и как да ги структурират за висока производителност.

Linux е сървърно помещение операционна система и най-често вашите приложения работят на тази ОС. Въпреки че казвам „Linux“, през повечето време можете спокойно да предположите, че имам предвид всички Unix-подобни операционни системи като цяло. Въпреки това не съм тествал придружаващия код на други системи. Така че, ако се интересувате от FreeBSD или OpenBSD, вашите резултати може да варират. Когато опитам нещо специфично за Linux, го посочвам.

Въпреки че можете да използвате това знание, за да създадете приложение от нулата и то ще бъде идеално оптимизирано, най-добре е да не правите това. Ако пишете нов уеб сървър на C или C++ за бизнес приложение на вашата организация, това може да е последният ви ден на работа. Познаването на структурата на тези приложения обаче ще помогне при избора на съществуващи програми. Ще можете да сравните системи, базирани на процеси, със системи, базирани на нишки, както и такива, базирани на събития. Ще разберете и оцените защо Nginx работи по-добре от Apache httpd, защо базирано на Tornado Python приложение може да обслужва повече потребители в сравнение с базирано на Django Python приложение.

ZeroHTTPd: Инструмент за обучение

Нула HTTPd е уеб сървър, който написах от нулата на C като инструмент за обучение. Той няма външни зависимости, включително достъп до Redis. Ние провеждаме собствени Redis процедури. Вижте по-долу за повече подробности.

Въпреки че можем да обсъждаме теорията надълго и нашироко, няма нищо по-добро от писането на код, стартирането му и сравняването на всички сървърни архитектури една с друга. Това е най-очевидният метод. Затова ще напишем прост уеб сървър ZeroHTTPd, като използваме всеки модел: базиран на процеси, базиран на нишки и базиран на събития. Нека да проверим всеки от тези сървъри и да видим как се представят в сравнение един с друг. ZeroHTTPd е внедрен в един файл C. Базираният на събития сървър включва uthash, страхотна реализация на хеш таблица, която идва в един заглавен файл. В останалите случаи няма зависимости, за да не се усложнява проекта.

В кода има много коментари, които да ви помогнат да разберете. Тъй като е прост уеб сървър в няколко реда код, ZeroHTTPd също е минимална рамка за уеб разработка. Има ограничена функционалност, но е в състояние да обслужва статични файлове и много прости "динамични" страници. Трябва да кажа, че ZeroHTTPd е добър за научаване как да създавате високопроизводителни Linux приложения. Като цяло повечето уеб услуги чакат заявки, проверяват ги и ги обработват. Точно това ще направи ZeroHTTPd. Това е инструмент за учене, а не за производство. Не е добър при обработката на грешки и е малко вероятно да се похвали с най-добри практики за сигурност (о, да, използвах strcpy) или хитрите трикове на езика C. Но се надявам, че върши работата си добре.

ZeroHTTPd начална страница. Може да извежда различни типове файлове, включително изображения

Приложение Книга за гости

Съвременните уеб приложения обикновено не се ограничават до статични файлове. Те имат сложни взаимодействия с различни бази данни, кешове и т.н. Така че ще създадем просто уеб приложение, наречено „Книга за гости“, където посетителите оставят записи под техните имена. Книгата за гости съхранява записи, оставени по-рано. В долната част на страницата има и брояч на посетителите.

Уеб приложение "Книга за гости" ZeroHTTPd

Броячът на посетителите и записите в книгата за гости се съхраняват в Redis. За комуникация с Redis се прилагат собствени процедури, те не зависят от външната библиотека. Не съм голям фен на внедряването на homebrew код, когато има публично достъпни и добре тествани решения. Но целта на ZeroHTTPd е да изследва производителността на Linux и достъпа до външни услуги, докато обслужването на HTTP заявки има сериозно въздействие върху производителността. Трябва напълно да контролираме комуникациите с Redis във всяка от нашите сървърни архитектури. В някои архитектури използваме блокиращи повиквания, в други използваме процедури, базирани на събития. Използването на външна клиентска библиотека на Redis няма да осигури този контрол. Освен това нашият малък Redis клиент изпълнява само няколко функции (получаване, настройка и увеличаване на ключ; получаване и добавяне към масив). Освен това протоколът Redis е изключително елегантен и прост. Дори не е нужно да го преподавате специално. Самият факт, че протоколът върши цялата работа в около сто реда код, показва колко добре е обмислен.

Следната фигура показва какво прави приложението, когато клиентът (браузърът) поиска /guestbookURL.

Как работи приложението книга за гости

Когато страницата на книгата за гости трябва да бъде издадена, има едно извикване към файловата система за четене на шаблона в паметта и три мрежови повиквания към Redis. Шаблонният файл съдържа по-голямата част от HTML съдържанието за страницата на екранната снимка по-горе. Има и специални контейнери за динамичната част от съдържанието: публикации и брояч на посетители. Ние ги получаваме от Redis, вмъкваме ги в страницата и предоставяме на клиента напълно оформено съдържание. Третото извикване на Redis може да бъде избегнато, защото Redis връща новата стойност на ключа, когато се увеличи. За нашия сървър обаче, който има асинхронна архитектура, базирана на събития, много мрежови повиквания са добър тест за учебни цели. Така че отхвърляме върнатата от Redis стойност на броя посетители и я отправяме с отделно извикване.

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

Ние изграждаме седем версии на ZeroHTTPd със същата функционалност, но различни архитектури:

• Итеративен
• Fork сървър (един дъщерен процес на заявка)
• Pre-fork сървър (предварително разклоняване на процеси)
• Сървър с нишки за изпълнение (една нишка на заявка)
• Сървър с предварително създаване на нишка
• Базиран на архитектура 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 000 едновременни потребители.

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

Следната диаграма показва производителността на сървъри на различни архитектури на различни нива на паралелизъм. Оста 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 000
-
-
голямо разпространение
-
2200
-
2200

11 000
-
-
-
-
2200
-
2122

12 000
-
-
-
-
970
-
1958

13 000
-
-
-
-
730
-
1897

14 000
-
-
-
-
590
-
1466

15 000
-
-
-
-
532
-
1281

От графиката и таблицата може да се види, че над 8000 едновременни заявки имаме само двама останали играчи: pre-fork и epoll. С нарастването на натоварването сървърът, базиран на анкети, се представя по-лошо от стрийминг. Архитектурата за предварително създаване на нишки е достоен конкурент на epoll, доказателство за това колко добре ядрото на Linux планира голям брой нишки.

ZeroHTTPd изходен код

ZeroHTTPd изходен код тук. За всяка архитектура има отделна директория.

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

В допълнение към седемте директории за всички архитектури, има още две в директорията от най-високо ниво: публична и шаблони. Първият съдържа файла index.html и изображението от първата екранна снимка. Можете да поставите други файлове и папки там и ZeroHTTPd трябва да обслужва тези статични файлове без никакви проблеми. Ако пътят в браузъра съвпада с пътя в публичната папка, тогава ZeroHTTPd търси файла index.html в тази директория. Съдържанието на книгата за гости се генерира динамично. Той има само начална страница и съдържанието му е базирано на файла 'templates/guestbook/index.html'. ZeroHTTPd лесно добавя динамични страници за разширение. Идеята е, че потребителите могат да добавят шаблони към тази директория и да разширяват ZeroHTTPd според нуждите.

За да изградите всичките седем сървъра, стартирайте make all от директорията от най-високо ниво - и всички компилации ще се показват в тази директория. Изпълнимите файлове търсят публичните и шаблонните директории в директорията, от която са стартирани.

Linux API

Не е необходимо да сте добре запознати с Linux API, за да разберете информацията в тази поредица от статии. Все пак препоръчвам да прочетете повече по тази тема; има много справочни ресурси в Интернет. Въпреки че ще се докоснем до няколко категории API на Linux, фокусът ни ще бъде основно върху процесите, нишките, събитията и мрежовия стек. В допълнение към книгите и статиите за Linux API, препоръчвам също да четете мана за системни извиквания и използвани библиотечни функции.

Производителност и мащабируемост

Една забележка относно производителността и скалируемостта. Теоретично между тях няма връзка. Можете да имате уеб услуга, която работи много добре, с време за реакция от няколко милисекунди, но тя изобщо не се мащабира. По същия начин може да има слабо работещо уеб приложение, което отнема няколко секунди, за да отговори, но то се мащабира с десетки, за да се справи с десетки хиляди едновременни потребители. Комбинацията от висока производителност и мащабируемост обаче е много мощна комбинация. Високопроизводителните приложения обикновено използват ресурсите пестеливо и по този начин обслужват ефективно повече едновременни потребители на сървъра, намалявайки разходите.

CPU и I/O задачи

И накрая, в компютрите винаги има два възможни типа задачи: за I/O и CPU. Получаване на заявки по интернет (мрежов I/O), обслужване на файлове (мрежов и дисков I/O), комуникация с базата данни (мрежов и дисков I/O) са всички I/O дейности. Някои заявки към база данни може да натоварват малко процесора (сортиране, осредняване на милион резултати и т.н.). Повечето уеб приложения са ограничени от максималния възможен I/O и процесорът рядко се използва с пълен капацитет. Когато видите, че някаква I/O задача използва много CPU, това най-вероятно е знак за лоша архитектура на приложението. Това може да означава, че ресурсите на процесора се губят за управление на процеси и превключване на контекста - и това не е напълно полезно. Ако правите нещо като обработка на изображения, конвертиране на аудио файлове или машинно обучение, тогава приложението изисква мощни ресурси на процесора. Но за повечето приложения това не е така.

Научете повече за сървърните архитектури

1. Част I: Итеративна архитектура
2. Част II. Fork сървъри
3. Част III. Pre-fork сървъри
4. Част IV. Сървъри с нишки за изпълнение
5. Част V. Предварително свързани сървъри
6. Част VI. Базирана на Pol архитектура
7. Част VII. базирана на epoll архитектура

Източник: www.habr.com