ვებ აპლიკაციები ახლა ყველგან გამოიყენება და ყველა სატრანსპორტო პროტოკოლს შორის HTTP უჭირავს ლომის წილს. ვებ აპლიკაციების განვითარების ნიუანსების შესწავლისას, ადამიანების უმეტესობა ძალიან მცირე ყურადღებას აქცევს ოპერაციულ სისტემას, სადაც რეალურად მუშაობს ეს აპლიკაციები. განვითარების (Dev) და ოპერაციების (Ops) გამიჯვნა მხოლოდ აუარესებს სიტუაციას. მაგრამ DevOps კულტურის ამაღლებასთან ერთად, დეველოპერები პასუხისმგებელნი ხდებიან თავიანთი აპლიკაციების ღრუბელში გაშვებაზე, ამიტომ მათთვის ძალიან სასარგებლოა ოპერაციული სისტემის უკანა ნაწილის საფუძვლიანად გაცნობა. ეს განსაკუთრებით სასარგებლოა, თუ თქვენ ცდილობთ სისტემის დანერგვას ათასობით ან ათიათასობით ერთდროულ კავშირზე.

ვებ სერვისებში შეზღუდვები ძალიან ჰგავს სხვა აპლიკაციების შეზღუდვებს. იქნება ეს დატვირთვის ბალანსერები თუ მონაცემთა ბაზის სერვერები, ყველა ამ აპლიკაციას აქვს მსგავსი პრობლემები მაღალი ხარისხის გარემოში. ამ ფუნდამენტური შეზღუდვებისა და ზოგადად მათი დაძლევის გაგება დაგეხმარებათ შეაფასოთ თქვენი ვებ აპლიკაციების შესრულება და მასშტაბურობა.

მე ვწერ სტატიების ამ სერიას ახალგაზრდა დეველოპერების კითხვების პასუხად, რომლებსაც სურთ გახდნენ კარგად ინფორმირებული სისტემების არქიტექტორები. შეუძლებელია Linux აპლიკაციების ოპტიმიზაციის ტექნიკის ნათლად გაგება ოპერაციული სისტემის დონეზე მათი მუშაობის საფუძვლების გარეშე. მიუხედავად იმისა, რომ არსებობს მრავალი სახის აპლიკაციები, ამ სერიაში მე მსურს შევისწავლო ვებ-ზე დაფუძნებული აპლიკაციები და არა დესკტოპის პროგრამები, როგორიცაა ბრაუზერი ან ტექსტური რედაქტორი. ეს მასალა განკუთვნილია დეველოპერებისთვის და არქიტექტორებისთვის, რომელთაც სურთ გაიგონ, როგორ მუშაობს Linux ან Unix პროგრამები და როგორ ააწყონ ისინი მაღალი წარმადობისთვის.

Linux არის სერვერის ოთახი ოპერაციული სისტემა და ყველაზე ხშირად თქვენი აპლიკაციები მუშაობს ამ OS-ზე. მიუხედავად იმისა, რომ მე ვამბობ "Linux", უმეტეს დროს შეგიძლიათ უსაფრთხოდ ვივარაუდოთ, რომ ვგულისხმობ ზოგადად Unix-ის მსგავს ოპერაციულ სისტემას. თუმცა, მე არ გამომიცდია თანმხლები კოდი სხვა სისტემებზე. ასე რომ, თუ გაინტერესებთ FreeBSD ან OpenBSD, თქვენი შედეგები შეიძლება განსხვავდებოდეს. როცა Linux-ის სპეციფიკურ რამეს ვცდილობ, აღვნიშნო.

მიუხედავად იმისა, რომ თქვენ შეგიძლიათ გამოიყენოთ ეს ცოდნა ნულიდან აპლიკაციის შესაქმნელად და ის იდეალურად ოპტიმიზირებული იქნება, უმჯობესია არ გააკეთოთ ეს. თუ დაწერთ ახალ ვებ სერვერს C ან C++-ში თქვენი ორგანიზაციის ბიზნეს აპლიკაციისთვის, ეს შეიძლება იყოს თქვენი სამუშაო ბოლო დღე. თუმცა, ამ აპლიკაციების სტრუქტურის ცოდნა დაგეხმარებათ არსებული პროგრამების არჩევაში. თქვენ შეძლებთ პროცესზე დაფუძნებული სისტემების შედარება ძაფებზე დაფუძნებულ სისტემებთან, ასევე მოვლენებზე დაფუძნებულ სისტემებთან. თქვენ მიხვდებით და შეაფასებთ, რატომ მუშაობს Nginx Apache httpd-ზე უკეთესად, რატომ შეუძლია Tornado-ზე დაფუძნებული Python აპლიკაცია მოემსახუროს უფრო მეტ მომხმარებელს Django-ზე დაფუძნებულ Python აპლიკაციასთან შედარებით.

ZeroHTTPd: სასწავლო ინსტრუმენტი

ZeroHTTPd არის ვებ სერვერი, რომელიც მე დავწერე ნულიდან C-ში, როგორც სასწავლო ინსტრუმენტი. მას არ აქვს გარე დამოკიდებულებები, მათ შორის წვდომა Redis-ზე. ჩვენ ვატარებთ საკუთარ რედის პროცედურებს. იხილეთ ქვემოთ დამატებითი დეტალებისთვის.

მიუხედავად იმისა, რომ თეორიის ვრცლად განხილვა შეგვეძლო, არაფერია უკეთესი, ვიდრე კოდის დაწერა, მისი გაშვება და ყველა სერვერის არქიტექტურის ერთმანეთთან შედარება. ეს ყველაზე აშკარა მეთოდია. ამიტომ, ჩვენ დავწერთ მარტივ ZeroHTTPd ვებ სერვერს თითოეული მოდელის გამოყენებით: პროცესზე დაფუძნებული, ძაფებზე დაფუძნებული და მოვლენებზე დაფუძნებული. მოდით, გადავხედოთ თითოეულ ამ სერვერს და ვნახოთ, როგორ მუშაობენ ისინი ერთმანეთთან შედარებით. ZeroHTTPd დანერგილია ერთ C ფაილში. მოვლენებზე დაფუძნებული სერვერი მოიცავს უთაშ, ჰეშის ცხრილის შესანიშნავი განხორციელება, რომელიც მოდის ერთი სათაურის ფაილში. სხვა შემთხვევებში, არ არსებობს დამოკიდებულებები, რათა არ გაართულოს პროექტი.

კოდში ბევრი კომენტარია, რაც გაგებაში დაგეხმარებათ. როგორც მარტივი ვებ სერვერი კოდის რამდენიმე სტრიქონში, ZeroHTTPd ასევე არის მინიმალური ჩარჩო ვებ განვითარებისთვის. მას აქვს შეზღუდული ფუნქციონირება, მაგრამ შეუძლია სტატიკური ფაილების და ძალიან მარტივი "დინამიური" გვერდების მომსახურება. უნდა ვთქვა, რომ ZeroHTTPd კარგია იმისთვის, რომ ისწავლოთ თუ როგორ შექმნათ მაღალი ხარისხის Linux აპლიკაციები. ზოგადად, ვებ სერვისების უმეტესობა ელოდება მოთხოვნებს, ამოწმებს მათ და ამუშავებს მათ. ეს არის ზუსტად ის, რასაც ZeroHTTPd გააკეთებს. ეს არის სწავლის საშუალება და არა წარმოებისთვის. ეს არ არის შესანიშნავი შეცდომების დამუშავებაში და ნაკლებად სავარაუდოა, რომ დაიკვეხნოს უსაფრთხოების საუკეთესო პრაქტიკით (ოჰ, მე გამოვიყენე strcpy) ან C ენის ჭკვიანური ხრიკები.მაგრამ იმედი მაქვს ის თავის საქმეს კარგად გააკეთებს.

ZeroHTTPd მთავარი გვერდი. მას შეუძლია გამოიტანოს სხვადასხვა ტიპის ფაილები, სურათების ჩათვლით

სტუმრების წიგნის აპლიკაცია

თანამედროვე ვებ აპლიკაციები ჩვეულებრივ არ შემოიფარგლება მხოლოდ სტატიკური ფაილებით. მათ აქვთ რთული ურთიერთქმედება სხვადასხვა მონაცემთა ბაზებთან, ქეშებთან და ა.შ. ასე რომ, ჩვენ შევქმნით მარტივ ვებ აპლიკაციას სახელწოდებით "სტუმრების წიგნი", სადაც ვიზიტორები თავიანთი სახელების ქვეშ ტოვებენ ჩანაწერებს. სტუმრების წიგნების მაღაზიებში ჩანაწერები ადრე დარჩა. გვერდის ბოლოში ასევე არის ვიზიტორთა მრიცხველი.

ვებ აპლიკაცია "სტუმრების წიგნი" ZeroHTTPd

ვიზიტორთა მრიცხველი და სტუმრების წიგნის ჩანაწერები ინახება Redis-ში. Redis-თან კომუნიკაციისთვის, დანერგილია საკუთარი პროცედურები, ისინი არ არის დამოკიდებული გარე ბიბლიოთეკაზე. მე არ ვარ homebrew კოდის გამოქვეყნების დიდი გულშემატკივარი, როდესაც არის საჯაროდ ხელმისაწვდომი და კარგად გამოცდილი გადაწყვეტილებები. მაგრამ ZeroHTTPd-ის მიზანია ლინუქსის მუშაობის შესწავლა და გარე სერვისებზე წვდომა, ხოლო HTTP მოთხოვნის მომსახურებას სერიოზული გავლენა აქვს შესრულებაზე. ჩვენ სრულად უნდა ვაკონტროლოთ კომუნიკაციები Redis-თან თითოეულ ჩვენს სერვერის არქიტექტურაში. ზოგიერთ არქიტექტურაში ვიყენებთ დაბლოკვის ზარებს, ზოგში ვიყენებთ მოვლენებზე დაფუძნებულ პროცედურებს. გარე Redis კლიენტის ბიბლიოთეკის გამოყენება არ უზრუნველყოფს ამ კონტროლს. გარდა ამისა, ჩვენი პატარა Redis კლიენტი ასრულებს მხოლოდ რამდენიმე ფუნქციას (გასაღების მიღება, დაყენება და გაზრდა; მასივის მიღება და დამატება). გარდა ამისა, Redis პროტოკოლი ძალიან ელეგანტური და მარტივია. თქვენ არც კი გჭირდებათ ამის სპეციალურად სწავლება. ის ფაქტი, რომ პროტოკოლი ასრულებს ყველა სამუშაოს კოდის დაახლოებით ასი ხაზით, აჩვენებს, თუ რამდენად კარგად არის გააზრებული.

შემდეგი სურათი გვიჩვენებს, რას აკეთებს აპლიკაცია კლიენტის (ბრაუზერის) მოთხოვნისას /guestbookURL.

როგორ მუშაობს სტუმრების წიგნის აპლიკაცია

როდესაც სტუმრების წიგნის გვერდი უნდა გაიცეს, არის ერთი ზარი ფაილურ სისტემაში შაბლონის მეხსიერებაში წასაკითხად და სამი ქსელის ზარი Redis-ზე. შაბლონის ფაილი შეიცავს გვერდის HTML კონტენტის უმეტეს ნაწილს ზემოთ მოცემულ ეკრანის სურათზე. ასევე არის კონტენტის დინამიური ნაწილისთვის სპეციალური ჩანაცვლება: პოსტები და ვიზიტორთა მრიცხველი. ჩვენ მათ ვიღებთ Redis-ისგან, ჩავსვით გვერდზე და ვაწვდით კლიენტს სრულად ჩამოყალიბებულ კონტენტს. Redis-ზე მესამე ზარის თავიდან აცილება შესაძლებელია, რადგან Redis აბრუნებს გასაღების ახალ მნიშვნელობას გაზრდისას. თუმცა, ჩვენი სერვერისთვის, რომელსაც აქვს ასინქრონული მოვლენებზე დაფუძნებული არქიტექტურა, ბევრი ქსელური ზარი კარგი ტესტია სასწავლო მიზნებისთვის. ასე რომ, ჩვენ უარვყოფთ ვიზიტორთა რაოდენობის Redis-ის დაბრუნების მნიშვნელობას და ვკითხულობთ მას ცალკე გამოძახებით.

სერვერის არქიტექტურები ZeroHTTPd

ჩვენ ვაშენებთ ZeroHTTPd-ის შვიდ ვერსიას იგივე ფუნქციონალურობით, მაგრამ განსხვავებული არქიტექტურით:

• განმეორებითი
• Fork სერვერი (ერთი ბავშვის პროცესი თითო მოთხოვნაზე)
• წინასწარ ჩანგალი სერვერი (პროცესების წინასწარ ჩანგალი)
• სერვერი შესრულების ძაფებით (თითო თემა თითო მოთხოვნაზე)
• სერვერი წინასწარ თემის შექმნით
• არქიტექტურაზე დაფუძნებული poll()
• არქიტექტურაზე დაფუძნებული epoll

ჩვენ ვზომავთ თითოეული არქიტექტურის მუშაობას სერვერის HTTP მოთხოვნებით ჩატვირთვის გზით. მაგრამ ძალიან პარალელური არქიტექტურების შედარებისას, მოთხოვნების რაოდენობა იზრდება. ვამოწმებთ სამჯერ და ვიანგარიშებთ საშუალოს.

ტესტირების მეთოდოლოგია

ZeroHTTPd დატვირთვის ტესტირების დაყენება

მნიშვნელოვანია, რომ ტესტების გაშვებისას, ყველა კომპონენტი არ იმუშაოს ერთ მანქანაზე. ამ შემთხვევაში, OS ექვემდებარება დამატებით დაგეგმვას, რადგან კომპონენტები კონკურენციას უწევენ CPU-ს. თითოეული შერჩეული სერვერის არქიტექტურის ოპერაციული სისტემის ზედნადების გაზომვა ამ სავარჯიშოს ერთ-ერთი ყველაზე მნიშვნელოვანი მიზანია. მეტი ცვლადის დამატება პროცესისთვის საზიანო გახდება. ამიტომ, სურათზე მოცემული პარამეტრი საუკეთესოდ მუშაობს.

რას აკეთებს თითოეული ეს სერვერი?

• load.unixism.net: სწორედ აქ გავდივართ ab, Apache Benchmark უტილიტა. ის წარმოქმნის დატვირთვას, რომელიც საჭიროა ჩვენი სერვერის არქიტექტურის შესამოწმებლად.
• nginx.unixism.net: ზოგჯერ გვსურს სერვერის პროგრამის ერთზე მეტი ეგზემპლარის გაშვება. ამისათვის Nginx სერვერი შესაბამისი პარამეტრებით მუშაობს როგორც დატვირთვის ბალანსერი, საიდანაც მოდის ab ჩვენი სერვერის პროცესებზე.
• zerohttpd.unixism.net: აქ ჩვენ ვაწარმოებთ ჩვენს სერვერულ პროგრამებს შვიდ სხვადასხვა არქიტექტურაზე, ერთდროულად.
• redis.unixism.net: ეს სერვერი აწარმოებს Redis daemon-ს, სადაც ინახება სტუმრების წიგნის ჩანაწერები და ვიზიტორთა მრიცხველები.

ყველა სერვერი მუშაობს იმავე პროცესორის ბირთვზე. იდეა არის თითოეული არქიტექტურის მაქსიმალური შესრულების შეფასება. ვინაიდან ყველა სერვერის პროგრამა ტესტირება ხდება ერთსა და იმავე აპარატურაზე, ეს არის შედარების საბაზისო ხაზი. ჩემი სატესტო დაყენება შედგება ციფრული ოკეანისგან დაქირავებული ვირტუალური სერვერებისგან.

რას ვზომავთ?

თქვენ შეგიძლიათ გაზომოთ სხვადასხვა ინდიკატორები. ჩვენ ვაფასებთ თითოეული არქიტექტურის მუშაობას მოცემულ კონფიგურაციაში სერვერების მოთხოვნით პარალელურობის სხვადასხვა დონეზე: დატვირთვა იზრდება 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 000
-
-
დიდი გავრცელება
-
2200
-
2200

11 000
-
-
-
-
2200
-
2122

12 000
-
-
-
-
970
-
1958

13 000
-
-
-
-
730
-
1897

14 000
-
-
-
-
590
-
1466

15 000
-
-
-
-
532
-
1281

გრაფიკიდან და ცხრილიდან ჩანს, რომ 8000 ერთდროულ მოთხოვნაზე მხოლოდ ორი მოთამაშე დარჩა: პრე-ფორკი და ეპოლი. დატვირთვის მატებასთან ერთად, გამოკითხვაზე დაფუძნებული სერვერი უფრო უარესად მუშაობს, ვიდრე ნაკადი. ძაფების შექმნამდე არქიტექტურა ღირსეული კონკურენტია epoll-ისთვის, რაც მოწმობს იმაზე, თუ რამდენად კარგად აწყობს ლინუქსის ბირთვი დიდი რაოდენობით ძაფებს.

ZeroHTTPd წყაროს კოდი

ZeroHTTPd წყაროს კოდი აქ. თითოეული არქიტექტურისთვის არის ცალკე დირექტორია.

ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking ├── 04_ ძაფები │ ├── მთავარი.c ├── მთავარი. ├── ინდექსი .html │ └── tux . png └── შაბლონები └── სტუმრების წიგნი └── index.html

ყველა არქიტექტურისთვის შვიდი დირექტორიის გარდა, უმაღლესი დონის დირექტორიაში არის კიდევ ორი: საჯარო და შაბლონები. პირველი შეიცავს 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-სთვის. ინტერნეტით მოთხოვნის მიღება (ქსელის I/O), ფაილების მომსახურება (ქსელის და დისკის I/O), მონაცემთა ბაზასთან კომუნიკაცია (ქსელი და დისკის I/O) ყველა I/O აქტივობაა. მონაცემთა ბაზის ზოგიერთი მოთხოვნა შეიძლება იყოს ცოტა ინტენსიური CPU (დახარისხება, საშუალოდ მილიონი შედეგი და ა.შ.). ვებ აპლიკაციების უმეტესობა შეზღუდულია მაქსიმალური შესაძლო I/O-ით და პროცესორი იშვიათად გამოიყენება სრული სიმძლავრით. როდესაც ხედავთ, რომ ზოგიერთი I/O ამოცანა იყენებს უამრავ CPU-ს, ეს, სავარაუდოდ, ცუდი აპლიკაციის არქიტექტურის ნიშანია. ეს შეიძლება ნიშნავს, რომ პროცესორის რესურსები იხარჯება პროცესის მენეჯმენტზე და კონტექსტის გადართვაზე - და ეს მთლად სასარგებლო არ არის. თუ თქვენ აკეთებთ ისეთ რამეს, როგორიცაა სურათის დამუშავება, აუდიო ფაილის კონვერტაცია ან მანქანური სწავლება, მაშინ აპლიკაცია მოითხოვს მძლავრ CPU რესურსებს. მაგრამ აპლიკაციების უმეტესობისთვის ეს ასე არ არის.

შეიტყვეთ მეტი სერვერის არქიტექტურის შესახებ

1. ნაწილი I: განმეორებითი არქიტექტურა
2. ნაწილი II. Fork სერვერები
3. III ნაწილი. წინასწარ ჩანგალი სერვერები
4. ნაწილი IV. სერვერები შესრულების ძაფებით
5. ნაწილი V. წინასწარ ხრახნიანი სერვერები
6. ნაწილი VI. პოლზე დაფუძნებული არქიტექტურა
7. ნაწილი VII. ეპოლზე დაფუძნებული არქიტექტურა

წყარო: www.habr.com