Kuriant tinklalapius, nepriklausomai nuo naudojamų priemonių, labai svarbu žinoti, nors teoriniame lygyje, ką gali išlaikyti Jūsų sprendimas ir platforma. Net jei Jūsų tinklalapis yra visiškai statinis. Kodėl? Pagalvokim – tinklalapis yra toks „sutvėrimas“, kurį tuo pačiu metu gali lankyti nuo vieno iki kelių tūkstančių lankytojų, be to, tuo pat metu jie gali užklausi kelis skirtingus puslapius. O dar yra indeksaciją atliekantys paieškos robotai ir jų gali ateiti tuo pačiu metu keletas skirtingų, kurie yra visiškai nesusitarę, bet gali įvaryti ir „šoko“ visam Jūsų tinklalapiui ar net serveriui.

Pastaba: Rusijos blogsferoje ne kartą teko skaityti kaip Yandex indeksavimo robotai dėl niekam nežinomų priežasčių pradėdavo labai intensyviai indeksuoti puslapius. Pagal serverio įrašus jie užklausdavo apie 10 puslapių kas 0.1 sekundės – tokį krūvį pasiruošęs atlaikyti ne kiekvienas serveris (100 puslapių kas sekundę, neskaitant lankytojų).

Taigi, kaip darbe ar prieš paleidimą simuliuoti apkrovą, kurios gali sulaukti tinklalapis? Juk neprašysi kolegos ar kolegų laikyti nuspaustą F5 mygtuką ir juk nesamdysi 1000 kiniečių, kad jie simuliuotų apkrovą (nors ši idėja man visai patinka, tik reikia gero ryšio su Kinija). O Jūs tuo metu stebėsite kaip ir kas vykstą Jūsų serveryje.

Šiaip šiam reikalui sukurta daug įrankių, tereikia apsilankyti Google ir truputį paieškoti, atsisiųsti, įdiegti ir naudotis. O tie, kas nuo seno naudojasi Apache HTTPD žino, kad į programų paketą įeina ir toks įrankis kaip programa. Unix/Linux ir MAC OS X operacinėse sistemose jos pavadinimas yra , o Microsoft Windows operacinėje sistemoje tai yra .exe.

() – tai puiki programa, dirbanti komandinėje eilutėje (angl. command prompt, command line), kuri leidžia simuliuoti serverio apkrovą bei po testo parodo truputį statistikos. Pilną naudojimo komandinės eilutės raktų sąrašą galite rasti puslapyje (http://httpd.apache.org/docs/2.0/programs/ab.html), o aš parodysiu keletą naudojimo pavyzdžių.

Paprasčiausią veiksmą, kurį galima atlikti, tai su nusiųsti vieną užklausą ir pažiūrėti ką išves ši programa.

Apache Benchmark screenshot 1

Programa parodo:

  • Serverio programinę įrangą (savaime aišku, jei serveris šią informaciją perduoda per HTTP antraštes) – Server Software;
  • Serverio pavadinimą – Server Hostname;
  • Serverio naudojamą prievadą – Server Port;
  • Kelią iki užklausto dokumento – Document Path;
  • Dokumento didį – Document Length;
  • Vienalaikiškumo lygis – Concurrency Level;
  • Laikas per kurį įvyko testas – Time taken for tests;
  • Kiek užklausų buvo atlikta – Complete requests;
  • Nepavykusių užklausų skaičius – Failed requests;
  • Srauto klaidų skaičius – Broken pipe errors;
  • Iš viso persiųsta – Total transferred;
  • Persiųsta HTML kodo – HTML transferred;
  • Užklausų per sekundė – Requests per second;
  • Laikas užklausai – Time per request;
  • Persiuntimo greitis – Transfer rate.

Berods viskas yra paprasta. Viena užklausa, kuri pavyko. O jei mes paleisime tokias užklausas vieną po kitos ir taip darysime 30 sekundžių? Kaip? O labai paprastai – tam yra raktas -t. Jis leidžia nurodyti kiek laiko reikia daryti užklausas.

Apache Benchmark screenshot 2

Taigi matome 28 užklausas, kurios puikiausiai nukeliavo iki serverio. Viena po kitos. Ir esant tokiam apkrovimui, mes matome, kad serveris gali atlaikyti 0.91 užklausą per sekundę, na, teoriškai gali, jei jos atkeliauja viena po kitos.

Pastaba: skriptas serverio pusėje specialiai „stabdo“ ir naudoja daug atminties. Jis jungiasi prie duomenų bazės, padaro 2 užklausas, užkrauna kelis kartus kelių kB failą, naudoja Smarty, specialiai padaryta pauzė 1 sekundei. Be to, dėl dinaminio turinio (ji genetuoja PHP), mes galime nekreipti dėmesio į „Failed requests“ skaičių prie „Length“ užrašo – turinys yra dinaminis ir jo kiekis keičiasi su kiekviena užklausa.

Bet kai tinklalapis veikia gyvai, kai jį naršo lankytojai, tai nėra viena užklausa ir net ne viena po kitos – jų būna keletas ir jos vykdomos tuo pat metu, taip atsiranda užklausų vienalaikiškumas. Taigi suemituokime tokią situaciją. Tam yra raktas -c – vienalaikiškumas (angl. concurrency). Šio parametro pagalba mes galime nurodyti kiek užklausų turi nusiųsti vienu metu. Pradžiai neblogai būtų įvesti 10 (blogiui dar neatėjo laikas).

Apache Benchmark screenshot 3

Taigi dabar gauname, kad užklausos buvo vykdytos vienu metu. Jei vykdomos užklausos viena po kitos, jas gali apdoroti vienas procesas mūsų serveryje, vadinasi vykdant daug užklausų vienu metu – mums prireiks daug procesų serveryje vienu metu.

Pastaba: Vienai užklausai apdoroti reikalingas vienas procesas, kuris gali pasiimti visus serverio resursus. Jei užklausos atkeliauja viena po kitos, procesai turi vienas po kito (o gal ir tas pats) jas apdoroti ir jiems visiškai nestigs resursų.

Esant kelioms užklausoms vienu metu, procesai, apdorojantys šiuos procesus jau turi pasidalinti serverio resursais. Pavyzdžiui, 1.3.33 naudoja apie 17 MB atminties, todėl Jūs patys galite pasiskaičiuoti, ką gali Jūsų technika ir kokios yra ribos.

Bandydami didinti užklausų vienu metu skaičių mes galime gauti štai tokią lentelę:

Nr. Vienalaikiškumo lygis Kiek užklausų buvo atlikta Užklausų per sekundė Laikas užklausai
1 1 28 0,91 1094,00
2 10 274 9,12 1096,64
3 50 858 28,60 1748,37
4 100 1349 44,96 2224,09
5 200 1064 34,96 5720,30
6 300 1263 42,02 7136,90
7 400 753 24,84 16103,05
8 500 783 25,18 19853,13
9 600 991 28,70 20905,55
10 999 901 21,40 46683,57

Kaip matome iš skaičių, kurie niekada nemeluoja, kad esant mano serverio sąlygoms, kuo daugiau lankytojų, tuo daugiau jie laukia, kol gaus puslapį – serveris turi baigtinį resursų skaičių (CPU, atmintis, kieto disko ir magistralių greitis) ir kuo daugiau lankytojų, tuo daugiau jų sunaudojama. O esant 400 užklausoms vienu metu, mes pradedame jausti (gerai, matyti) blogį – atsakymas į užklausą perkopė 10 sekundžių pauzę, o apdorojamų užklausų kiekis sumažėjo dvigubai.

Pastaba: atskleisiu paslaptį – tai virtualus serveris, turintis apie 192 MB operatyvios atminties, CentOS 4, 1.3.33, PHP 5.2.0, MySQL 5.0.20, todėl viskas atrodo taip tragiškai, bet tai labai geras pavyzdys šiam straipsniui. Be to, nepamirškite apie specialiai sukurtą skriptą šiam straipsniui.

Darant tokius testus Jūsų, kaip sistemos administratoriaus ir/ar programuotojo užduotis – rasti tas vietas, kurios stabdo ir jas panaikinti. Priežasčių gali būti daug, todėl Jūsų gali laukti sudėtingas ir ilgas darbas, kol viskas veiks taip kaip Jus tikitės ar norite. Tai gali buti operatyvios atminties stoka (ir tada sistema pradeda tam tikrus procesus perkelti iš operatyvios atminties į sukeitimo atmintį, angl. swap), per lėtas centrinis procesorius (ir tada procesai pradeda laukti savo eilės), per lėtas kietas diskas (nespėjama duomenų skaityti/rašyti), blogai sukonfigūruotas HTTP serveris (trūksta procesų užklausoms apdoroti arba procesų yra per daug ir jie sunaudoja visą laisvą atmintį), netinkama failų sistema, netinkama failų padėtis arba kiekis kataloge, netinkamos užklausos į bazę, netinkama bazės struktūra ar kitos priežastis, visų čia neišvardinsi.

Savaime aišku, neparodo visų šių vietų, čia jau žmogaus darbas, rasti šias vietas, bet jos pagalbą galite rasti Jūsų sukurto produkto galimybių ribas, rasti optimalią serverio konfigūraciją, patikrinti serverio resursų naudojimą apkrovimo metu dar prieš projekto paleidimą.

O dabar pažiūrėkime į tamsiąją šio įrankio pusę. Dėl ko jis yra blogis gėrio rankose? Tereikia tinklapyje rasti ilgai ir sunkiai generuojamą puslapį (o geriausia tai daryti su atvirojo kodo sistemomis) ir su šiuo įrankiu, turint gerą interneto ryšį, pradėti „daryti testus“ su šiuo puslapiu, padidinus užklausų vienu metu skaičių virš tūkstančio, ir kad jis testųsi gerokai ilgiau nei 30 sekundžių. Jei apkrovimas ženkliai padidės, tam tikros tinklalapių talpinimo tarnybos Jūsų tinklapį gali atjungti be jokių paaiškinimų; Jūsų lankytojai tuo metu gali būti nepatenkinti dėl lėto tinklalapio veikimo. O tai yra tikras blogis. Priėjimą prie tokio įrankio turi kiekvienas. Ir jeigu Microsoft Windows aplinkoje jo galimybės yra nors kažkiek apribotos (man nepavyko įvesti -t ar -c didesnį nei 50), tai Unix aplinkoje šie parametrai gali būti itin dideli.

Pastaba pabaiga: aš žinau, kad mokyti blogų dalykų yra negerai, bet tai padaryti gali bet kas, kas jau moka naudotis ar bet kokia panašios paskirties programine įranga. Savaime aišku, nuo tokio tipo atakų irgi įmanoma apsisaugoti (ugniasienės, papildomi moduliai), bet apie tai tegul papasakoja kas nors kitas.

Panašūs straipsniai


“Apache Benchmark – blogis gėrio rankose” komentarų: 6

  1. Blogorama #283 : nežinau.lt

    […] Naujų virusų mutacijas per biologijos pamokas? Gal jums pasirodys juokinga, bet imkime ir išveskime paraleles su rimtais svetainių įrangos testavimo įrankiais, kurie žioplių ir piktava…. O juk tokie ir panašūs įrankiai taip lengvai pasiekiami! Šiaip mintis, kuri kilo skaitant […]

  2. Žilvinas Sadauskas

    Nu sakyčiau labai vykęs straipsnis :). +++

  3. geriBatai

    Šiaip pastaba, kad viską dar blogiau pavaizduot - norint pradėti daryti tokius testus net ir gero ryšio nereikia…


  4. Na, stengiausi, šiam straipsniui parašyti prireikė beveik 24 valandų. Šiaip turiu daug minčių apie ką galima parašyti, bet laiko trūkumas padaro savo.

  5. beck

    Labai jau siaurai apie ab čia parašyta, kitą kartą testuokis su apache22, bet ne su senom versijom.

  6. Tygas

    Įdomu kiek hostingo kompanijų apsaugo nuo tokių mėgėjų.

Rašyti komentarą

Jūs privalote prisijungti jeigu norite rašyti komentarą.