Jak otestovat, co snese httpd server?

[KtK]

Mam webovy server, a ocekavam na nem v brzke dobe prudky narust navstevnosti. (klasika LAMP, ale to ted asi neni dulezite). Rad bych, aby se to nezhroutilo, az to prijde, takze bych to rad nejak otetostoval predem. Vim, predem, kolik asi lidi najednou si k tomu webe sedne, a co tam tak budou delat. Jako test me napadlo jedine - na jinem pocitaci spoustet v adekvatni frekvenci odpovidajici mnozstvi instanci "wget -p <URL>", a sledovat, co se bude dit.
Nejaky lepsi napad? (krome koupeni si nejakeho botnetu z ruska )

[frelichl]

Zkus se podívat na http://httpd.apache.org/docs/2.0/programs/ab.html když nic jiného, můžeš si tam aspoň nastavit, kolik "klientů" zároveň to bude používat.

[Marty]

Jen tak mimochodem, na jakém cca. HW to běží a co myslíš tou velkou návštěvností? Předpokládají se pak velké objemy dat (video), nebo prostě hodně hitů na "běžných" stránkách?

[KtK]

Ciste phpkem pohaneny html + nejaky ty obrazky. Je to o tom, ze si na jeden vecer sedne k tem strankam radove stovky, mozna 1000 lidi. Nekteri to budou vyuzivat vice, nekteri mene.
HW je virtualni v xenu, ma to 0,5GB ramky, cpu prideleno tusim 800MHz.

A ted mam dilema, jestli to vystaci, nebo to stehovat na jiny zelezo, coz by byly naklady.

[mraky]

Na tyhle věci se výborně hodí JMeter od Apache. Kdybys potřeboval rozjet opravdu velkou zátěž, tak můžeš JMeter spustit distribuovaně na více počítačích a dát tomu pořádnej kotel.

[Petrik]

Ciste phpkem pohaneny html + nejaky ty obrazky. Je to o tom, ze si na jeden vecer sedne k tem strankam radove stovky, mozna 1000 lidi. Nekteri to budou vyuzivat vice, nekteri mene.
HW je virtualni v xenu, ma to 0,5GB ramky, cpu prideleno tusim 800MHz.

A ted mam dilema, jestli to vystaci, nebo to stehovat na jiny zelezo, coz by byly naklady.

1000 lidi server s 0.5GB RAM podle me nema sanci zvladnout. Zkus si vygooglit, jak nastavit apache,aby jedno spojeni na apache zralo co nejmene RAM, a spocitej orientacni spotrebu RAM na spojeni, jsou na to vzorce, ale tipuji, ze to je bez sance. 1000 spojeni najednou je uz docela mazec. Navic ti tam bezi databaze, pokud jedno spojeni na apache znamena jedno spojeni do databaze, tak je to opet dalsi RAM navic. Jestli to nepouziva sessions, tak by to mohl zachranit squid jako httpd accelerator, hodne webu to s uspechem pouziva, zkus si o tom neco najit.

[tomase]

Uz pri 200 ludoch dostaval nas server (C2D 2.2GHz, 3GB RAM, Raptor) slusne naprdel, takze 1000 ludi ten tvoj neda

[Petrik]

Uz pri 200 ludoch dostaval nas server (C2D 2.2GHz, 3GB RAM, Raptor) slusne naprdel, takze 1000 ludi ten tvoj neda

Zkuste ten squid, co jsem cetl a i podle zkusenosti znamych dokaze zdvoj az zpetinasobit vykon serveru.

http://en.wikipedia.org/wiki/Squid_%28software%29

[tomase]

Vymenili sme zelezo (quad, 8GB ram) a 32bit system nahradili 64bit a uz to fici jak po masle

[Fox!MURDER]

jedna vec je 1000 lidi, jina vec je 1000 paralelnich konekci.

zrovna v pohode to asi stihat nebude, ale pokud uzivatel klikne v te webove aplikaci radove jednou za 5 vterin, tak to vychazi cca na 400 konekci naraz. coz uz je lepsi, ale to zelezo na to neni idealni. mozna by bylo i reseni rozdelit to na aplikacni cast (apache+php) a statickou cast (napr. lighttpd, nginx, etc.)

dalsi vec je, ze pokud tech aktualne zobrazovanejch obrazku bude radove velkej objem (vic nez treba 200MB), mohly by mit problem disky. nevim co v tom virtualu je, ale do cache uz se to nevejde a zadny uberpole tam nejspis nebude...

[Petrik]

chce to proste vic RAM, pul giga je fest malo. Budto to zacne dropovat konexe, nebo to zacne swapovat, coz je snad jeste horsi, v lepsim pripade nastane DoS, v horsim to pujde do kytek uplne

Jedna zajimavost na konec: ve firme, kde ted pracuji, se zabyvame dataminingem ojetych aut ze stranek autobazaru v EU, mame na to armadu downloaderu jedouci pres proxy servery po celem svete, takze nemame problem vytvorit treba 1000 spojeni z unikatnich IP adres. Predevsim u mensich serveru si museme davat bacha na pocet spojeni, abychom je nesestrelili, coz se jinak stava pomerne casto

[KtK]

Diky kluci, to mi asi tak nejak celkove staci. zkusim nejaky ty benchmarky, a uvidime. Udelaly se i nejaky opitmalizace v aplikacni casti, aby to zbytecne nesahalo do db a tak podobne. Pak dam vedet, jak to dopadlo.

[Jezevec]

Jeste by tu byla varianta, ze ten svuj web napises v C/C++ jako modul do Apache, vykon tim znasobis o min 2 rady, ale samo neni to easy a vetsinou vyjde levnejs vykonejsi zelezo.

[Petrik]

Jeste by tu byla varianta, ze ten svuj web napises v C/C++ jako modul do Apache, vykon tim znasobis o min 2 rady, ale samo neni to easy a vetsinou vyjde levnejs vykonejsi zelezo.

Ja vidim jako nejvetsi problem toho serveru nedostatek RAM pro thready/instance apache2 pro obsluhu prichozich spojeni. Pokud si to dobre pamatuji, tak jedno spojeni typicky spotrebuje cca 5MB RAM, pro 1000 spojeni to tedy dela cca 5GB a to nepocitam nejake ty spojeni do databaze, coz je RAM navic za kazde spojeni.

[sasha]

pri tech cislech co jsi uvedl se ve vetsine pripadech co znam pouziva proxy, ktera cachuje kontent pro uzivatele, je to opravdu poradny rozdil...

[Petrik]

pri tech cislech co jsi uvedl se ve vetsine pripadech co znam pouziva proxy, ktera cachuje kontent pro uzivatele, je to opravdu poradny rozdil...

Ano, to jsem sem psal, problem nastava, kdyz server pouziva sessions. Nebo to lze nejak resit?

[sasha]

navysenim vykonu

ne popravde pro vytizenejsi servry uz pak loadbalancing

[KtK]

Tak jsem slibil, ze dam vedet jak to dopadlo, tak cinim - dali jsme to na lepsi zelezo a byl klid

[Petrik]

Tak jsem slibil, ze dam vedet jak to dopadlo, tak cinim - dali jsme to na lepsi zelezo a byl klid

skoda, docela by me zajimalo, pri kolika spojenich by to slo do kytek kazdopadne spravna volba

[svaca]

Hmm mereni jsem si nikdy nedelal, ale rozhodne nejde rict jen, ze "ocekavam hodne lidi", problem je komplexnejsi ...
Asi nejvic zalezi na nastaveni Apache, to se da hodne zmrsit, dale samozrejme pomuze squid na predcacheovani, hodne zavisi na te napsane aplikaci, co obsluhuje LAMP a jak prasacky/indexove ma osetrene dotazy do SQL ... atd.... atd ... Apache je sileny srout pameti, ale take zalezi na nastaveni, da se nastavit tak, aby uplne vystavil RAM, otazka je jestli je to potreba A pokud mas 32bit system (coz je asi uplne nejhorsi) tak Mysql ti stejne poradne nevyuzije vice jak 2G RAM i kdyz mas PAE

A kdyz uz apache nestaci, tak je tu loadbalancing a nebo lighttpd