Apache najcesce ne moze da digne toliko instanci PHP-a odjednom. Tj. Apache koji vrti PHP forkuje procese unapred, po jedan za svaku konekciju. Dodatno, apache ima limit broja procesa koji mogu da budu podignuti. Kada web server udari u taj limit apache drzi konekciju dok se ne pojavi slobodan proces da je preuzme (ili dok konekcija ne timeout-uje). Znaci, ti efektivno ogranicavas broj konekcija na serveru, a samim tim i broj aktivnih PHP skripti. (Ova vrednost stoji u config fajlu, promenjljiva je).

Apache ima konfigurabilni limit u broju requestova koje moze da izvrsi u svakom trenutku. To je nkrgovic pomenuo. Naravno u realnosti taj broj je neka idelana varijanta jer neki requestovi traju duze od drugih i nisu svi requesti zahtevi za izvrsenjem PHP skripte, tako da je efektivan broj PHP scripti izvrsavanih odjednom obicno znacajno manji.

Koliko je meni poznato svaki PHP skript je izolovan u odnosu na drugi aktivni skript. Sam zend engine se brine da svaki dobije potrebnu kolicinu memorije do nekog maksimuma koje je definisan ili u PHP.ini ili ogranicenjem sistemske memorije. Pretpostavljam da se potrebna kolicina dinamicki dodeljuje u koracima od recimo 1024kb.
U sustini koliko koji skript zauzima memorije nije preterano bitno (naravno u nekim razumnim granicama) ono sto je mnogo vaznije je da se skript sto brze izvrsi jer zavrsetkom skripta oslobadjaju se svi resurski koje je skript zauzimao. Izuzetak je persiztentna konekcija na bazu koja se ne oslobadja zavrsetkom skripta.

Ako se vratimo na tvoj primer 100MB memorije zauzete u jednom trenutku nije nista, tako da to ne treba da te brine, posto se sve vraca sistemu cim se skiptovi zavrse. Ako znamo da je vreme izvrsavanja skripta najcesce mnogo manje od 1sec, onda ti je jasno da ce 100 istovremeno aktivnih pristupa skipti znacti visemilionsku dnevnu posetu sajtu, sto ipak retki sajtovi postizu i u najcescem slucaju kolicina memorije koju PHP zauzima tu predstavlja najmanju brigu.

Mislim da je ovo relativno u odnosu na ucitane apache module, kao i pridruzene ekstenzije php-u...

Ovo stoji: definitivno na memoriju koju koristi sam php skript ide, ajde da kazem overhead, koji daju httpd proces i svi njegovi dodaci, ukljucujuci tu php. Ono sto sam pricao se odnosi na broj aktivnih httpd procesa, koji su, po pravilu, par MB, tako da je skript od 100K tu vise-manje nebitan... zato i kazem da je ogranicenje na broju podignutih procesa pravi limit. Izvinjenje sto se nisam bio jasan.

To kako kernel radi alokaciju i dealokaciju memorije, bilo OS, bilo Zend, to je prica za sebe. Pre svega, kernel alocira u blokovima mnogo manjim od 1024k, a plus sto je alokacija/dealokacija relativno spora operacija... ali to je mnogo ozbiljnija prica od ove. Sto se tice PHP programera svodi se na to da ce sistem (iliti dobar administrator) tako podesiti tu vrednost da apache ne moze da pojede toliko memorije da to ugrozi stabilnost sistema. Sve dok skripte na sistemu ne zahtevaju od administratora da menja memory_limit u php.ini ne ocekuj probleme... :)

Muchísimas gracias amigos You've been very helpful!

Sada je mnogo jasnije sta se desava sa serverom! I sada se lepo vidi cemu sluzi connection timeout
Iskreno, zamisljao sam se da je apac pametniji i da nekako kesira skripte koje se stalno vrte a ne da stalno drlja po memoriji i alocira resurse 1000000 puta za istu skriptu. No, mozda sve to dodje sa PHP6 i kompajliranjem...

Na mojoj skripti, memory_get_peak_usage(true) je pokazao povecanje u koracima od 256KB. Bio na 512, pa 768 i sada alocira 1024 za skriptu koja zauzima 780KB.

Znaci:

1. brzina izvrsavanja skripte je najvaznija
2. ne razmisljaj o mem ako skripta konzumira < memory_limit u php.ini
3. nastavi da programiras

Hvala jos jednom

hm...

zavisi od prirode sajta.

Apache trosi memoriju za procese, tu su drugi alati da kesiraju fajlove i u to rade u zajednickom adresnom prostoru...


_{[Ovu poruku je menjao agvozden dana 09.12.2009. u 22:33 GMT+1]}