glug: configurazione apache+php [OT]

s.sartini s.sartini@linux.it
Mer 26 Gen 2005 11:29:44 CET



>>Uhm, potrei sbagliarmi ma l'unico vero vantaggio nell'avere un modulo di 
>>apache č il fatto che č + facile aggiornarlo (invece che ricompilare 
>>tutto apache alla bisogna si ricompila solo il modulo).
>>Il discorso della memoria condivisa non mi convince, quando Apache 
>>carica un .so di fatto č "come se" fosse stato linkato nell'eseguibile, 
>>non č una libreria condivisa gestita dal kernel di linux e quindi 
>>"shared" per definizione quando usata come condivisa.
>>Ogni istanza di apache (httpd) si porterā dietro il modulo .so del php, 
>>senza nessun vantaggio in termini di risparmio di memoria, e con invece 
>>un certo overhead ogni volta che viene spawnato un nuvo child di apache.

Marco Masetti ha scritto:

> Guarda qui (nella sezione background):
> 
> http://httpd.apache.org/docs-2.0/dso.html
> 
> comunque hai ragione per quanto riguarda l'overhead.
> 
> Ciao,
> Marco.

Interessante, ma io nn vedo la parte relativa al risparmio della 
memoria, nemmeno nel paragrafo sotto in cui si parla di Vantaggi e 
Svantaggi. Da programmatore leggo: "...Dynamic Shared Objects (DSO) 
[which] provides a way to build a piece of program code in a special 
format for loading it at run-time into the address space of an 
executable program."
Se il programma carica del codice nel PROPRIO Address-space, allora č 
come se fosse stato linkato staticamente...
C'č da dire che le librerie linkate dinamicamente dal php quando lo si 
compila (sia che si generi un .so che una libreria linkata 
successivamente in apache) rimangono appunto dinamiche, quindi in realtā 
sia che si metta nell'eseguibile sia che si compili un .so, una buona 
parte del php rimane "shared" (aggiungo: per fortuna :)

Ho messo OT nel subject perchč effettivamente sono ben poche le 
situazioni in cui un utente linux normale (=chi mette sul suo PC 
apache+php+mysql per fare delle prove) deve preoccuparsi di questi 
dettagli, la comoditā di poter ricompilare (o sostituire, per chi lavora 
coi precompilati) il modulo php al volo č talmente preponderante 
rispetto al famoso overhead da non doversi nemmeno porre il problema, 
tantopiu' per chi usa Apache 2.* che lo fa di default, pero' esistono 
alcuni casi specifici di server in cui un 20% di rallentamento (o anche 
solo un 5%) puo' voler dire trovarsi di fronte a molti guai, a fronte di 
un PHP che verrā toccato raramente, se non mai...

E poi lo confesso: un httpd "monolitico" (con anche i suoi modulini 
giusti linkati a compile-time) mi da molta + sicurezza di uno che ad 
ogni esecuzione va a raccogliere in giro dei .so e se li carica in 
memoria, e sarei disposto a "spendere" anche 500k in + di occupazione di 
memoria se fosse necessario :D

Ciaps :)

ste





Maggiori informazioni sulla lista glug