Jak otestovat, co snese httpd server?

[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