glug: configurazione apache+php (risposta molto lunga...)

[s.sartini]

Marco Masetti ha scritto:
> Ok, la risposta e' stata gia' data dal Debe, ed adesso che il php respira ritorniamo sui nostri passi e cerchiamo di capire qualcosa...
> 
> 
>>Hai verificato se apache carica php4_module?
> 
> un modulo puo' essere staticamente compilato con apache (e quindi sara' gia' presente in ogni processo httpd) oppure puo' essere caricato dinamicamente allo start up del processo principale.
> Il vantaggio di caricare un modulo dinamicamente al runtime e' che verra' condiviso da piu' processi e quindi risparmieremo parecchia ram durante l'esecuzione, guarda questo estratto del comando top:
> 
>  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND 
>  9479 root      15   0  2912 2028  1976 S     0.0  0.3   0:00 httpd
>  9499 webAppal  15   0  4168 3776  3060 S     0.5  0.7   0:04 httpd
> 
> che ci dice che ogni processo httpd figlio (quelli per interdeci che servono le richieste http) occupa circa 3.7 Mb in RAM (colonna RSS), ma di cui ben 3 Mb sono moduli shared (colonna SHARE), e questo ci permette di farne girare un bel po' (o almeno di dire non e' certo per colpa di apache che siamo a corto di Ram...).
> I moduli condivisi hanno estensione '.so'.

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.

Ste