Veb-ilovalar endi hamma joyda qo'llaniladi va barcha transport protokollari orasida HTTP asosiy ulushni egallaydi. Veb-ilovalarni ishlab chiqishning nuanslarini o'rganayotganda, ko'pchilik ushbu ilovalar aslida ishlaydigan operatsion tizimga juda kam e'tibor beradi. Rivojlanish (Dev) va operatsiyalarni (Ops) ajratish vaziyatni yanada yomonlashtirdi. Ammo DevOps madaniyatining o'sishi bilan ishlab chiquvchilar o'z ilovalarini bulutda ishga tushirish uchun mas'ul bo'lib qolishmoqda, shuning uchun ular uchun operatsion tizimning orqa tomoni bilan yaxshilab tanishish juda foydali. Bu, ayniqsa, bir vaqtning o'zida minglab yoki o'n minglab ulanishlar uchun tizimni o'rnatmoqchi bo'lsangiz foydali bo'ladi.
Veb-xizmatlardagi cheklovlar boshqa ilovalardagi cheklovlarga juda o'xshash. Bu yuk balanslagichlari yoki ma'lumotlar bazasi serverlari bo'ladimi, bu ilovalarning barchasi yuqori samarali muhitda o'xshash muammolarga ega. Ushbu asosiy cheklovlar va ularni qanday engib o'tishni tushunish veb-ilovalaringizning ishlashi va kengayish qobiliyatini baholashga yordam beradi.
Men ushbu turkum maqolalarni yaxshi ma'lumotga ega tizim arxitektori bo'lishni xohlaydigan yosh dasturchilarning savollariga javob sifatida yozyapman. Linux ilovalarini optimallashtirish usullarini, ularning operatsion tizim darajasida ishlash asoslarini tushunmasdan aniq tushunish mumkin emas. Ilovalarning ko'p turlari mavjud bo'lsa-da, men ushbu seriyada brauzer yoki matn muharriri kabi ish stoli ilovalarini emas, balki veb-ga asoslangan ilovalarni o'rganmoqchiman. Ushbu material Linux yoki Unix dasturlari qanday ishlashini va ularni yuqori samaradorlik uchun qanday tuzishni tushunishni istagan ishlab chiquvchilar va arxitektorlar uchun mo'ljallangan.
Linux bu server xonasi operatsion tizim va ko'pincha ilovalaringiz ushbu OTda ishlaydi. Garchi men "Linux" desam ham, ko'pincha unix-ga o'xshash barcha operatsion tizimlarni nazarda tutayotganimni ishonch bilan taxmin qilishingiz mumkin. Biroq, men boshqa tizimlarda hamrohlik kodini sinab ko'rmadim. Shunday qilib, agar siz FreeBSD yoki OpenBSD-ga qiziqsangiz, natijalaringiz farq qilishi mumkin. Men Linuxga xos biror narsani sinab ko'rganimda, men buni ta'kidlayman.
Ilovani noldan yaratish uchun ushbu bilimdan foydalanishingiz mumkin va u mukammal optimallashtirilsa ham, buni qilmaslik yaxshiroqdir. Tashkilotingizning biznes ilovasi uchun C yoki C++ tilida yangi veb-server yozsangiz, bu ishdagi oxirgi kuningiz bo'lishi mumkin. Biroq, ushbu ilovalarning tuzilishini bilish mavjud dasturlarni tanlashda yordam beradi. Siz jarayonga asoslangan tizimlarni mavzuga asoslangan tizimlar bilan bir qatorda voqealarga asoslangan tizimlar bilan solishtira olasiz. Nima uchun Nginx Apache httpd dan yaxshiroq ishlashini, nima uchun Tornado asosidagi Python ilovasi Django asosidagi Python ilovasiga nisbatan ko'proq foydalanuvchilarga xizmat ko'rsatishi mumkinligini tushunasiz va qadrlaysiz.
ZeroHTTPd: o'rganish vositasi
bu men o'qitish vositasi sifatida C tilida noldan yozgan veb-serverdir. Uning tashqi bog'liqligi yo'q, jumladan Redis-ga kirish. Biz o'z Redis protseduralarimizni bajaramiz. Batafsil ma'lumot uchun quyida ko'ring.
Garchi biz nazariyani uzoq muhokama qilishimiz mumkin bo'lsa-da, kod yozish, uni ishga tushirish va barcha server arxitekturalarini bir-biri bilan solishtirishdan yaxshiroq narsa yo'q. Bu eng aniq usul. Shuning uchun biz har bir modeldan foydalangan holda oddiy ZeroHTTPd veb-serverini yozamiz: jarayonga asoslangan, mavzuga asoslangan va voqealarga asoslangan. Keling, ushbu serverlarning har birini ko'rib chiqamiz va ularning bir-biriga nisbatan qanday ishlashini ko'rib chiqamiz. ZeroHTTPd bitta C faylida amalga oshiriladi.Hodisalarga asoslangan server o'z ichiga oladi , bitta sarlavha faylida keladigan ajoyib hash-jadvalni amalga oshirish. Boshqa hollarda, loyihani murakkablashtirmaslik uchun hech qanday bog'liqlik yo'q.
Kodda tushunishingizga yordam beradigan ko'plab sharhlar mavjud. Bir necha qator kodlarda oddiy veb-server bo'lgan ZeroHTTPd ham veb-ishlab chiqish uchun minimal ramka hisoblanadi. U cheklangan funksionallikka ega, lekin statik fayllar va juda oddiy "dinamik" sahifalarga xizmat ko'rsatishga qodir. Aytishim kerakki, ZeroHTTPd yuqori samarali Linux ilovalarini yaratishni o'rganish uchun yaxshi. Umuman olganda, aksariyat veb-xizmatlar so'rovlarni kutadi, ularni tekshiradi va qayta ishlaydi. ZeroHTTPd aynan shunday qiladi. Bu ishlab chiqarish emas, balki o'rganish uchun vositadir. Bu xatolarni hal qilishda unchalik yaxshi emas va eng yaxshi xavfsizlik amaliyotlari bilan maqtanish dargumon (ha, men foydalanardim) strcpy) yoki C tilining aqlli nayranglari.Lekin u o'z vazifasini yaxshi bajaradi deb umid qilaman.
ZeroHTTPd bosh sahifasi. U turli xil fayl turlarini, shu jumladan tasvirlarni chiqarishi mumkin
Mehmonlar kitobi uchun ariza
Zamonaviy veb-ilovalar odatda statik fayllar bilan cheklanmaydi. Ular turli ma'lumotlar bazalari, keshlar va boshqalar bilan murakkab o'zaro ta'sirga ega. Shunday qilib, biz "Mehmonlar kitobi" deb nomlangan oddiy veb-ilovani yaratamiz, unda tashrif buyuruvchilar o'z nomlari ostida yozuvlarni qoldiradilar. Mehmonlar kitobi avval qolgan yozuvlarni saqlaydi. Sahifaning pastki qismida tashrif buyuruvchilar hisoblagichi ham mavjud.
ZeroHTTPd "Mehmonlar kitobi" veb-ilovasi
Mehmonlar hisoblagichi va mehmonlar kitobi yozuvlari Redis-da saqlanadi. Redis bilan aloqa qilish uchun o'z protseduralari amalga oshiriladi, ular tashqi kutubxonaga bog'liq emas. Hammaga ochiq va yaxshi sinovdan o'tgan yechimlar mavjud bo'lganda, men homebrew kodini chiqarishning katta muxlisi emasman. Ammo ZeroHTTPd ning maqsadi Linux ishlashi va tashqi xizmatlarga kirishni o'rganishdir, HTTP so'rovlariga xizmat ko'rsatish esa ishlashga jiddiy ta'sir qiladi. Har bir server arxitekturasida Redis bilan aloqani to'liq nazorat qilishimiz kerak. Ba'zi arxitekturalarda biz blokirovka qiluvchi qo'ng'iroqlardan foydalanamiz, boshqalarida biz voqealarga asoslangan protseduralardan foydalanamiz. Tashqi Redis mijozlar kutubxonasidan foydalanish bu boshqaruvni ta'minlamaydi. Bundan tashqari, bizning Redis mijozimiz faqat bir nechta funktsiyalarni bajaradi (kalitni olish, sozlash va oshirish; massivni olish va qo'shish). Bundan tashqari, Redis protokoli juda oqlangan va sodda. Siz uni maxsus o'rgatishingiz shart emas. Protokolning barcha ishni yuzga yaqin kod satrida bajarishining o‘zi uning qanchalik puxta o‘ylanganligini ko‘rsatadi.
Quyidagi rasmda dastur mijoz (brauzer) so‘raganda nima qilishi ko‘rsatilgan /guestbookURL.
Mehmonlar kitobi ilovasi qanday ishlaydi
Mehmonlar kitobi sahifasini chiqarish kerak bo'lganda, shablonni xotiraga o'qish uchun fayl tizimiga bitta qo'ng'iroq va Redisga uchta tarmoq qo'ng'irog'i bo'ladi. Shablon fayli yuqoridagi skrinshotdagi sahifa uchun HTML tarkibining ko'p qismini o'z ichiga oladi. Shuningdek, kontentning dinamik qismi uchun maxsus joy egalari mavjud: xabarlar va tashrif buyuruvchilar hisoblagichi. Biz ularni Redis-dan olamiz, ularni sahifaga joylashtiramiz va mijozga to'liq shakllangan tarkibni taqdim etamiz. Redisga uchinchi qo'ng'iroqni oldini olish mumkin, chunki Redis oshirilganda yangi kalit qiymatini qaytaradi. Biroq, asinxron hodisalarga asoslangan arxitekturaga ega bo'lgan serverimiz uchun ko'plab tarmoq qo'ng'iroqlari o'rganish uchun yaxshi sinovdir. Shunday qilib, biz tashrif buyuruvchilar sonining Redis qaytish qiymatini o'chirib tashlaymiz va uni alohida qo'ng'iroq bilan so'raymiz.
Server arxitekturasi ZeroHTTPd
Biz ZeroHTTPd ning yettita versiyasini bir xil funksionallikka ega, ammo arxitekturasi turlicha yaratmoqdamiz:
- Takroriy
- Fork-server (har bir so'rov uchun bitta bola jarayoni)
- Pre-fork server (jarayonlarni oldindan forklash)
- Ijro tishlari bo'lgan server (har bir so'rov uchun bitta mavzu)
- Oldindan mavzu yaratish bilan server
- Arxitekturaga asoslangan
poll() - Arxitekturaga asoslangan
epoll
Biz serverni HTTP so'rovlari bilan yuklash orqali har bir arxitekturaning ishlashini o'lchaymiz. Ammo juda parallel arxitekturalarni solishtirganda, so'rovlar soni ortadi. Biz uch marta sinovdan o'tkazamiz va o'rtacha hisoblaymiz.
Sinov metodologiyasi
ZeroHTTPd yuk sinovini sozlash
Sinovlarni bajarishda barcha komponentlar bitta mashinada ishlamasligi muhim. Bunday holda, OS qo'shimcha rejalashtirish xarajatlarini oladi, chunki komponentlar CPU uchun raqobatlashadi. Tanlangan server arxitekturalarining har birining operatsion tizimining qo'shimcha xarajatlarini o'lchash ushbu mashqning eng muhim maqsadlaridan biridir. Ko'proq o'zgaruvchilarni qo'shish jarayonga zararli bo'ladi. Shuning uchun yuqoridagi rasmdagi sozlama eng yaxshi ishlaydi.
Ushbu serverlarning har biri nima qiladi?
- load.unixism.net: Bu erda biz yuguramiz
ab, Apache Benchmark yordam dasturi. U bizning server arxitekturasini sinab ko'rish uchun zarur bo'lgan yukni yaratadi. - nginx.unixism.net: Ba'zan biz server dasturining bir nechta nusxasini ishga tushirishni xohlaymiz. Buning uchun tegishli sozlamalarga ega Nginx server yuk balansi sifatida ishlaydi ab server jarayonlarimizga.
- zerohttpd.unixism.net: Bu yerda biz server dasturlarimizni bir vaqtning o'zida yetti xil arxitekturada ishga tushiramiz.
- redis.unixism.net: Bu server Redis demonini boshqaradi, bu yerda mehmonlar kitobi yozuvlari va tashrif buyuruvchilar hisoblagichlari saqlanadi.
Barcha serverlar bir xil protsessor yadrosida ishlaydi. G'oya har bir arxitekturaning maksimal ishlashini baholashdir. Barcha server dasturlari bir xil uskunada sinovdan o'tganligi sababli, bu taqqoslash uchun asosdir. Mening sinov sozlamalarim Digital Ocean'dan ijaraga olingan virtual serverlardan iborat.
Biz nimani o'lchaymiz?
Turli ko'rsatkichlarni o'lchashingiz mumkin. Biz ma'lum konfiguratsiyadagi har bir arxitekturaning ishlashini serverlarni turli darajadagi parallellikdagi so'rovlar bilan yuklash orqali baholaymiz: yuk bir vaqtning o'zida 20 dan 15 000 tagacha o'sadi.
Sinov natijalari
Quyidagi diagrammada serverlarning turli xil arxitekturadagi parallellik darajasidagi ishlashi ko'rsatilgan. Y o'qi - soniyada so'rovlar soni, x o'qi - parallel ulanishlar.
Quyida natijalar bilan jadval mavjud.
soniyada so'rovlar
parallellik
iterativ
sanchqi
oldindan vilka
oqim
oldingi oqim
so'rovnoma
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
katta tarqalish
2138
5000
-
katta tarqalish
1600
1100
2519
-
2235
8000
-
-
1200
katta tarqalish
2451
-
2100
10
-
-
katta tarqalish
-
2200
-
2200
11
-
-
-
-
2200
-
2122
12
-
-
-
-
970
-
1958
13
-
-
-
-
730
-
1897
14
-
-
-
-
590
-
1466
15
-
-
-
-
532
-
1281
Grafik va jadvaldan ko'rinib turibdiki, bir vaqtning o'zida 8000 dan ortiq so'rovlar bizda faqat ikkita o'yinchi qolgan: pre-fork va epoll. Yuk ortishi bilan so'rovga asoslangan server oqimli serverdan yomonroq ishlaydi. Tarmoqni yaratishdan oldingi arxitektura epoll uchun munosib raqobatchi bo'lib, Linux yadrosi ko'p sonli iplarni qanchalik yaxshi rejalashtirishidan dalolat beradi.
ZeroHTTPd manba kodi
ZeroHTTPd manba kodi . Har bir arxitektura uchun alohida katalog mavjud.
ZeroHTTPd │ ├── 01_iterativ │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking asosiy ──c. 04_ ip o'tkazish │ ├── main.c ├── 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └── main.c │ └── main.c ─Main.c ─── ├── indeks .html │ └── tux . png └── andozalar └── mehmonlar kitobi └── index.html
Barcha arxitekturalar uchun yettita katalogdan tashqari, yuqori darajadagi katalogda yana ikkitasi mavjud: ommaviy va shablonlar. Birinchisi index.html faylini va birinchi skrinshotdagi rasmni o'z ichiga oladi. Siz u erga boshqa fayl va papkalarni qo'yishingiz mumkin va ZeroHTTPd ushbu statik fayllarga hech qanday muammosiz xizmat qilishi kerak. Agar brauzerdagi yo'l umumiy papkadagi yo'lga to'g'ri kelsa, ZeroHTTPd ushbu katalogdan index.html faylini qidiradi. Mehmonlar kitobi uchun kontent dinamik ravishda yaratilgan. U faqat bosh sahifaga ega va uning mazmuni "shablonlar/guestbook/index.html" fayliga asoslangan. ZeroHTTPd kengaytma uchun osongina dinamik sahifalarni qo'shadi. G'oya shundan iboratki, foydalanuvchilar ushbu katalogga shablonlarni qo'shishlari va kerak bo'lganda ZeroHTTPdni kengaytirishlari mumkin.
Barcha yetti serverni yaratish uchun ishga tushiring make all yuqori darajadagi katalogdan - va barcha tuzilmalar ushbu katalogda paydo bo'ladi. Bajariladigan fayllar ishga tushirilgan katalogdagi umumiy va shablon kataloglarini qidiradi.
Linux API
Ushbu maqola seriyasidagi ma'lumotlarni tushunish uchun Linux API-ni yaxshi bilishingiz shart emas. Biroq, men ushbu mavzu bo'yicha ko'proq o'qishni tavsiya qilaman, Internetda ko'plab ma'lumot manbalari mavjud. Garchi biz Linux API'larining bir nechta toifalariga to'xtaladigan bo'lsak-da, bizning e'tiborimiz asosan jarayonlar, mavzular, hodisalar va tarmoq stekiga qaratiladi. Linux API haqidagi kitoblar va maqolalarga qo'shimcha ravishda, men tizim qo'ng'iroqlari va ishlatiladigan kutubxona funktsiyalari uchun mana o'qishni tavsiya qilaman.
Ishlash va masshtablilik
Ishlash va miqyoslilik haqida bitta eslatma. Nazariy jihatdan ular o'rtasida hech qanday aloqa yo'q. Sizda juda yaxshi ishlaydigan, javob vaqti bir necha millisekund bo'lgan veb-xizmatga ega bo'lishingiz mumkin, lekin u umuman miqyosda emas. Xuddi shunday, javob berish uchun bir necha soniya vaqt ketadigan yomon ishlaydigan veb-ilova bo'lishi mumkin, ammo u bir vaqtning o'zida o'n minglab foydalanuvchilarni boshqarish uchun o'nlab darajaga etadi. Biroq, yuqori mahsuldorlik va miqyoslilik kombinatsiyasi juda kuchli kombinatsiyadir. Yuqori unumdor ilovalar odatda resurslardan tejamkorlik bilan foydalanadi va shu tariqa serverda bir vaqtning o'zida ko'proq foydalanuvchilarga samarali xizmat qiladi, bu esa xarajatlarni kamaytiradi.
CPU va kiritish-chiqarish vazifalari
Nihoyat, hisoblashda har doim ikkita mumkin bo'lgan vazifalar turi mavjud: kiritish-chiqarish va protsessor uchun. Internet orqali so‘rovlarni qabul qilish (tarmoqli kiritish-chiqarish), fayllarga xizmat ko‘rsatish (tarmoq va diskdagi kiritish-chiqarish), ma’lumotlar bazasi bilan aloqa o‘rnatish (tarmoq va diskdagi kiritish-chiqarish) barcha kiritish-chiqarish faoliyati hisoblanadi. Ba'zi ma'lumotlar bazasi so'rovlari biroz CPU intensiv bo'lishi mumkin (saralash, o'rtacha million natijalar va boshqalar). Aksariyat veb-ilovalar mumkin bo'lgan maksimal kiritish-chiqarish bilan cheklanadi va protsessor kamdan-kam hollarda to'liq quvvat bilan ishlatiladi. Ba'zi bir kiritish-chiqarish vazifasi juda ko'p protsessor ishlatayotganini ko'rsangiz, bu, ehtimol, zaif dastur arxitekturasining belgisidir. Bu jarayonni boshqarish va kontekstni almashtirish uchun protsessor resurslari behuda sarflanishini anglatishi mumkin va bu mutlaqo foydali emas. Agar siz tasvirni qayta ishlash, audio fayllarni o'zgartirish yoki mashinani o'rganish kabi biror narsa bilan shug'ullanayotgan bo'lsangiz, dastur kuchli CPU resurslarini talab qiladi. Ammo ko'pgina ilovalar uchun bu shunday emas.
Server arxitekturalari haqida ko'proq bilib oling
Manba: www.habr.com