Linux Şəbəkə Tətbiq Performansı. Giriş

Veb proqramları indi hər yerdə istifadə olunur və bütün nəqliyyat protokolları arasında HTTP əsas payı tutur. Veb proqramların hazırlanmasının nüanslarını öyrənərkən insanların çoxu bu proqramların əslində işlədiyi əməliyyat sisteminə çox az diqqət yetirirlər. İnkişafın (Dev) və əməliyyatların (Ops) ayrılması vəziyyəti daha da pisləşdirdi. Lakin DevOps mədəniyyətinin yüksəlişi ilə tərtibatçılar tətbiqlərini buludda idarə etmək üçün məsuliyyət daşıyırlar, ona görə də əməliyyat sisteminin arxa hissəsi ilə hərtərəfli tanış olmaq onlar üçün çox faydalıdır. Bu, minlərlə və ya on minlərlə eyni vaxtda əlaqə üçün bir sistem yerləşdirməyə çalışırsınızsa xüsusilə faydalıdır.

Veb xidmətlərindəki məhdudiyyətlər digər proqramlardakı məhdudiyyətlərə çox oxşardır. İstər yük balanslaşdırıcıları, istərsə də verilənlər bazası serverləri olsun, bu proqramların hamısının yüksək performanslı mühitdə oxşar problemləri var. Bu əsas məhdudiyyətləri və ümumiyyətlə onları necə aradan qaldıracağınızı başa düşmək veb tətbiqlərinizin performansını və miqyasını qiymətləndirməyə kömək edəcəkdir.

Bu silsilə məqalələri yaxşı məlumatlı sistem memarları olmaq istəyən gənc tərtibatçıların suallarına cavab olaraq yazıram. Linux proqramlarının optimallaşdırılması üsullarını əməliyyat sistemi səviyyəsində necə işlədiyinin əsaslarına dalmadan aydın başa düşmək mümkün deyil. Tətbiq növlərinin çox olmasına baxmayaraq, bu seriyada brauzer və ya mətn redaktoru kimi masaüstü proqramlardan daha çox veb əsaslı proqramları araşdırmaq istəyirəm. Bu material Linux və ya Unix proqramlarının necə işlədiyini və onların yüksək performans üçün necə qurulduğunu anlamaq istəyən tərtibatçılar və memarlar üçün nəzərdə tutulub.

Linuxdur server otağı əməliyyat sistemi və əksər hallarda proqramlarınız bu ƏS-də işləyir. Mən "Linux" desəm də, çox vaxt əminliklə güman edə bilərsiniz ki, mən bütün Unix-ə bənzər əməliyyat sistemlərini nəzərdə tuturam. Bununla belə, müşayiət olunan kodu digər sistemlərdə sınaqdan keçirməmişəm. Beləliklə, FreeBSD və ya OpenBSD ilə maraqlanırsınızsa, nəticələriniz fərqli ola bilər. Mən Linux-a xas bir şey sınayanda onu qeyd edirəm.

Sıfırdan proqram yaratmaq üçün bu bilikdən istifadə edə bilsəniz və o, mükəmməl optimallaşdırılsa da, bunu etməmək daha yaxşıdır. Təşkilatınızın biznes proqramı üçün C və ya C++ dillərində yeni veb server yazsanız, bu, işinizdə son gününüz ola bilər. Bununla belə, bu proqramların strukturunu bilmək mövcud proqramları seçməkdə kömək edəcəkdir. Siz proses əsaslı sistemləri mövzu əsaslı sistemlərlə, eləcə də hadisə əsaslı sistemlərlə müqayisə edə biləcəksiniz. Nginx-in nə üçün Apache httpd-dən daha yaxşı performans göstərdiyini, Tornado əsaslı Python tətbiqinin Django əsaslı Python tətbiqi ilə müqayisədə niyə daha çox istifadəçiyə xidmət göstərə biləcəyini başa düşəcək və qiymətləndirəcəksiniz.

ZeroHTTPd: Öyrənmə Aləti

ZeroHTTPd tədris vasitəsi kimi C dilində sıfırdan yazdığım veb serverdir. Onun Redis-ə çıxış daxil olmaqla heç bir xarici asılılığı yoxdur. Biz öz Redis prosedurlarımızı icra edirik. Daha ətraflı məlumat üçün aşağıya baxın.

Nəzəriyyəni uzun-uzadı müzakirə edə bilsək də, kod yazmaq, onu işə salmaq və bütün server arxitekturalarını bir-biri ilə müqayisə etməkdən daha yaxşı bir şey yoxdur. Bu, ən bariz üsuldur. Buna görə də, hər bir modeldən istifadə edərək sadə ZeroHTTPd veb serveri yazacağıq: proses əsaslı, mövzu əsaslı və hadisə əsaslı. Gəlin bu serverlərin hər birini nəzərdən keçirək və onların bir-biri ilə müqayisədə necə işlədiyini görək. ZeroHTTPd tək C faylında həyata keçirilir.Hadisə əsaslı server daxildir uthash, tək başlıq faylında gələn əla hash cədvəli tətbiqi. Digər hallarda, layihəni çətinləşdirməmək üçün heç bir asılılıq yoxdur.

Anlamağınıza kömək etmək üçün kodda çoxlu şərhlər var. Bir neçə kod sətirindən ibarət sadə veb server olan ZeroHTTPd həm də veb inkişafı üçün minimal çərçivədir. Onun məhdud funksionallığı var, lakin statik fayllara və çox sadə "dinamik" səhifələrə xidmət göstərə bilir. Deməliyəm ki, ZeroHTTPd yüksək performanslı Linux proqramları yaratmağı öyrənmək üçün yaxşıdır. Ümumiyyətlə, əksər veb xidmətləri sorğuları gözləyir, yoxlayır və emal edir. ZeroHTTPd tam olaraq bunu edəcək. Bu istehsal deyil, öyrənmək üçün bir vasitədir. Səhvlərin idarə edilməsində əla deyil və ən yaxşı təhlükəsizlik təcrübələri ilə öyünmək ehtimalı azdır (oh, bəli, istifadə etdim strcpy) və ya C dilinin ağıllı fəndləri.Ancaq ümid edirəm ki, o, öz işini yaxşı görür.

Linux Şəbəkə Tətbiq Performansı. Giriş
ZeroHTTPd ana səhifəsi. Şəkillər daxil olmaqla müxtəlif fayl növlərini çıxara bilər

Qonaq Kitabı Tətbiqi

Müasir veb proqramlar adətən statik fayllarla məhdudlaşmır. Onların müxtəlif verilənlər bazaları, keşlər və s. ilə mürəkkəb qarşılıqlı əlaqəsi var. Beləliklə, biz ziyarətçilərin öz adları altında qeydlər buraxdığı "Qonaq kitabı" adlı sadə veb proqram yaradacağıq. Qonaq kitab mağazası girişləri daha əvvəl buraxdı. Səhifənin aşağı hissəsində ziyarətçi sayğacı da var.

Linux Şəbəkə Tətbiq Performansı. Giriş
Veb tətbiqi "Qonaq kitabı" ZeroHTTPd

Ziyarətçi sayğacı və qonaq kitabçası qeydləri Redis-də saxlanılır. Redis ilə əlaqə üçün öz prosedurları həyata keçirilir, onlar xarici kitabxanadan asılı deyildir. Mən ictimaiyyətə açıq və yaxşı sınaqdan keçmiş həllər mövcud olduqda homebrew kodunu yaymağın böyük tərəfdarı deyiləm. Lakin ZeroHTTPd-nin məqsədi Linux performansını və xarici xidmətlərə çıxışı öyrənməkdir, halbuki HTTP sorğularına xidmət göstərmək performansa ciddi təsir göstərir. Biz hər bir server arxitekturamızda Redis ilə ünsiyyətə tam nəzarət etməliyik. Bəzi arxitekturalarda biz bloklama zənglərindən, digərlərində isə hadisəyə əsaslanan prosedurlardan istifadə edirik. Xarici Redis müştəri kitabxanasından istifadə bu nəzarəti təmin etməyəcək. Bundan əlavə, kiçik Redis müştərimiz yalnız bir neçə funksiyanı yerinə yetirir (açar əldə etmək, qurmaq və artırmaq; massiv əldə etmək və əlavə etmək). Bundan əlavə, Redis protokolu son dərəcə zərif və sadədir. Bunu xüsusi olaraq öyrətməyə də ehtiyac yoxdur. Protokolun bütün işləri yüzə yaxın kod sətirində yerinə yetirməsi onun nə qədər yaxşı düşünülmüş olduğunu göstərir.

Aşağıdakı şəkildə müştəri (brauzer) tələb etdikdə tətbiqin nə etdiyini göstərir /guestbookURL.

Linux Şəbəkə Tətbiq Performansı. Giriş
Qonaq kitabı tətbiqi necə işləyir

Qonaq kitab səhifəsi buraxılmalı olduqda, şablonu yaddaşa oxumaq üçün fayl sisteminə bir zəng və Redis-ə üç şəbəkə zəngi olur. Şablon faylı yuxarıdakı ekran görüntüsündə səhifə üçün HTML məzmununun əksəriyyətini ehtiva edir. Məzmunun dinamik hissəsi üçün xüsusi yer tutucular da var: yazılar və ziyarətçi sayğacı. Biz onları Redis-dən alırıq, səhifəyə daxil edirik və müştərini tam formalaşmış məzmunla təmin edirik. Redis-ə üçüncü zəngdən qaçmaq olar, çünki Redis artırıldıqda yeni açar dəyərini qaytarır. Bununla belə, asinxron hadisəyə əsaslanan arxitekturaya malik olan serverimiz üçün çoxlu şəbəkə zəngləri öyrənmə məqsədləri üçün yaxşı bir sınaqdır. Beləliklə, biz ziyarətçilərin sayının Redis qaytarma dəyərini atırıq və onu ayrıca zənglə sorğulayırıq.

Server arxitekturaları ZeroHTTPd

Biz ZeroHTTPd-nin eyni funksional, lakin fərqli arxitekturaya malik yeddi versiyasını qururuq:

  • İterativ
  • Fork server (hər sorğu üçün bir uşaq proses)
  • Pre-fork server (proseslərin əvvəlcədən forklaşdırılması)
  • İcra başlıqları olan server (hər sorğu üçün bir mövzu)
  • Əvvəlcədən mövzu yaradılması ilə server
  • Memarlıq əsaslıdır poll()
  • Memarlıq əsaslıdır epoll

Biz serveri HTTP sorğuları ilə yükləməklə hər bir arxitekturanın performansını ölçürük. Lakin yüksək paralel arxitekturaları müqayisə edərkən sorğuların sayı artır. Üç dəfə test edirik və orta hesablayırıq.

Test metodologiyası

Linux Şəbəkə Tətbiq Performansı. Giriş
ZeroHTTPd yük testi quraşdırması

Testlər apararkən bütün komponentlərin eyni maşında işləməməsi vacibdir. Bu halda, komponentlər CPU üçün rəqabət apardığı üçün ƏS əlavə planlaşdırma xərclərinə məruz qalır. Seçilmiş server arxitekturalarının hər birinin əməliyyat sisteminin yükünün ölçülməsi bu məşqin ən mühüm məqsədlərindən biridir. Daha çox dəyişən əlavə etmək prosesə zərər verəcəkdir. Buna görə yuxarıdakı şəkildəki parametr ən yaxşı işləyir.

Bu serverlərin hər biri nə edir?

  • load.unixism.net: Bu, qaçdığımız yerdir ab, Apache Benchmark yardım proqramı. O, server arxitekturamızı sınamaq üçün lazım olan yükü yaradır.
  • nginx.unixism.net: Bəzən biz server proqramının birdən çox nümunəsini işə salmaq istəyirik. Bunun üçün müvafiq parametrlərə malik Nginx serveri gələn yük balanslaşdırıcısı kimi işləyir ab server proseslərimizə.
  • zerohttpd.unixism.net: Burada biz server proqramlarımızı bir-bir yeddi fərqli arxitekturada işlədirik.
  • redis.unixism.net: Bu server qonaq dəftəri qeydlərinin və ziyarətçi sayğaclarının saxlandığı Redis demonunu idarə edir.

Bütün serverlər eyni prosessor nüvəsində işləyir. İdeya hər bir arxitekturanın maksimum performansını qiymətləndirməkdir. Bütün server proqramları eyni aparatda sınaqdan keçirildiyi üçün bu, müqayisə üçün əsasdır. Test quraşdırmam Digital Ocean-dan icarəyə götürülmüş virtual serverlərdən ibarətdir.

Nəyi ölçürük?

Müxtəlif göstəriciləri ölçə bilərsiniz. Verilmiş konfiqurasiyada hər bir arxitekturanın performansını müxtəlif paralellik səviyyələrində sorğularla serverləri yükləməklə qiymətləndiririk: yük eyni vaxtda 20-dən 15 istifadəçiyə qədər artır.

Test nəticələri

Aşağıdakı diaqram müxtəlif paralellik səviyyələrində müxtəlif arxitekturalarda serverlərin performansını göstərir. Y oxu saniyədə sorğuların sayı, x oxu paralel bağlantılardır.

Linux Şəbəkə Tətbiq Performansı. Giriş

Linux Şəbəkə Tətbiq Performansı. Giriş

Linux Şəbəkə Tətbiq Performansı. Giriş

Aşağıda nəticələri olan bir cədvəl var.

saniyədə sorğular

paralellik
iterativ
çəngəl
ön çəngəl
axın
pre-streaming
səsvermə
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
böyük yayılma
2138

5000
-
böyük yayılma
1600
1100
2519
-
2235

8000
-
-
1200
böyük yayılma
2451
-
2100

10 000
-
-
böyük yayılma
-
2200
-
2200

11 000
-
-
-
-
2200
-
2122

12 000
-
-
-
-
970
-
1958

13 000
-
-
-
-
730
-
1897

14 000
-
-
-
-
590
-
1466

15 000
-
-
-
-
532
-
1281

Qrafikdən və cədvəldən görünür ki, eyni vaxtda 8000-dən çox sorğu bizə yalnız iki oyunçu qalıb: pre-fork və epoll. Yük artdıqca, sorğuya əsaslanan server axın serverindən daha pis işləyir. Mövzudan əvvəl yaradılan arxitektura epoll üçün layiqli rəqibdir, Linux nüvəsinin çoxlu sayda ipləri necə yaxşı planlaşdırdığının sübutudur.

ZeroHTTPd Mənbə Kodu

ZeroHTTPd Mənbə Kodu burada. Hər arxitektura üçün ayrıca qovluq var.

ZeroHTTPd │ ├── 01_iterativ │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking əsas ──c.───04 05_ iplik │ ├── main.c ├── 06_prethreading │ ├── main.c ├── 07_sorğu │ ├── main.c ├── XNUMX_epoll │ └── əsas.c ──── əsas.c ─ ─ ─ ─ ─ açıq ─ ├── indeks .html │ └── tux . png └── şablonları └── qonaq kitabı └── index.html

Bütün arxitekturalar üçün yeddi kataloqdan əlavə, yuxarı səviyyəli kataloqda daha ikisi var: ictimai və şablonlar. Birincisi index.html faylını və ilk skrinşotdakı şəkli ehtiva edir. Oraya başqa fayl və qovluqlar qoya bilərsiniz və ZeroHTTPd bu statik faylları heç bir problem olmadan xidmət etməlidir. Brauzerdəki yol ümumi qovluqdakı yola uyğun gəlirsə, ZeroHTTPd bu kataloqda index.html faylını axtarır. Qonaq kitabı üçün məzmun dinamik şəkildə yaradılır. Onun yalnız əsas səhifəsi var və onun məzmunu 'templates/guestbook/index.html' faylına əsaslanır. ZeroHTTPd asanlıqla genişləndirmə üçün dinamik səhifələr əlavə edir. İdeya ondan ibarətdir ki, istifadəçilər bu qovluğa şablonlar əlavə edə və lazım olduqda ZeroHTTPd-ni genişləndirə bilərlər.

Bütün yeddi serveri qurmaq üçün işə salın make all yuxarı səviyyəli kataloqdan - və bütün quruluşlar bu kataloqda görünəcək. İcra edilə bilən fayllar işə salındıqları qovluqda ümumi və şablon qovluqlarını axtarır.

Linux API

Bu məqalə seriyasındakı məlumatları başa düşmək üçün Linux API-ni yaxşı bilməyinizə ehtiyac yoxdur. Bununla belə, bu mövzuda daha çox oxumağı məsləhət görürəm, İnternetdə çoxlu istinad resursları var. Linux API-lərinin bir neçə kateqoriyasına toxunsaq da, diqqətimiz ilk növbədə proseslər, mövzular, hadisələr və şəbəkə yığını üzərində olacaq. Linux API haqqında kitab və məqalələrə əlavə olaraq, sistem zəngləri və istifadə olunan kitabxana funksiyaları üçün də mana oxumağı tövsiyə edirəm.

Performans və Ölçeklenebilirlik

Performans və genişlənmə haqqında bir qeyd. Nəzəri cəhətdən onların arasında heç bir əlaqə yoxdur. Bir neçə millisaniyəlik cavab müddəti ilə çox yaxşı işləyən veb xidmətiniz ola bilər, lakin o, heç bir şəkildə ölçülənmir. Eyni şəkildə, cavab verməsi bir neçə saniyə çəkən zəif işləyən veb tətbiqi ola bilər, lakin o, eyni vaxtda on minlərlə istifadəçini idarə etmək üçün onlarla ölçü götürür. Bununla belə, yüksək performans və miqyaslılığın birləşməsi çox güclü birləşmədir. Yüksək performanslı proqramlar ümumiyyətlə resurslardan qənaətlə istifadə edir və beləliklə, serverdə daha çox eyni vaxtda işləyən istifadəçilərə səmərəli şəkildə xidmət edir, xərcləri azaldır.

CPU və I/O tapşırıqları

Nəhayət, hesablamada həmişə iki mümkün tapşırıq növü var: I/O və CPU üçün. İnternet üzərindən sorğuların qəbulu (şəbəkə I/O), fayllara xidmət göstərilməsi (şəbəkə və diskin I/O), verilənlər bazası ilə əlaqə (şəbəkə və disk I/O) bütün I/O fəaliyyətləridir. Bəzi verilənlər bazası sorğuları bir az CPU intensiv ola bilər (çeşidləmə, orta hesabla bir milyon nəticə və s.). Əksər veb proqramlar mümkün olan maksimum I/O ilə məhdudlaşır və prosessor nadir hallarda tam gücü ilə istifadə olunur. Bəzi I/O tapşırıqlarının çoxlu CPU istifadə etdiyini görəndə, bu, çox güman ki, zəif proqram arxitekturasının əlamətidir. Bu, CPU resurslarının prosesin idarə edilməsinə və kontekstlərin dəyişdirilməsinə sərf edildiyini ifadə edə bilər - və bu, tamamilə faydalı deyil. Şəkillərin işlənməsi, audio faylın çevrilməsi və ya maşın öyrənməsi kimi bir şey edirsinizsə, o zaman proqram güclü CPU resursları tələb edir. Lakin əksər proqramlar üçün bu belə deyil.

Server arxitekturaları haqqında daha çox məlumat əldə edin

  1. I hissə: İterativ memarlıq
  2. II hissə. Çəngəl serverləri
  3. III hissə. Pre-çəngəl serverlər
  4. IV hissə. İcra başlıqları olan serverlər
  5. Hissə V. Əvvəlcədən yivli serverlər
  6. VI hissə. Pol əsaslı memarlıq
  7. VII hissə. epoll əsaslı memarlıq

Mənbə: www.habr.com

Добавить комментарий