2012-07-13 11 views
16

Per dare qualche contesto:Come funziona davvero l'utilizzo della memoria PHP di apache?

Ho avuto una discussione con un collega di recente sull'uso di Autoloaders in PHP. Stavo discutendo a favore di loro, lui contro.

Il mio punto di vista è che i caricatori automatici possono aiutare a ridurre al minimo la dipendenza manuale dell'origine, che a sua volta può aiutare a ridurre la quantità di memoria consumata quando si includono molti file di grandi dimensioni che potrebbero non essere necessari.

La sua risposta è stata che includere file non necessari non è un grosso problema perché dopo che un file è stato incluso una volta che viene tenuto in memoria dal processo figlio Apache e questa porzione di memoria sarà disponibile per le richieste successive. Sostiene che non dovresti preoccuparti della quantità di file inclusi perché abbastanza presto saranno tutti caricati in memoria e utilizzati on-demand dalla memoria. Quindi la memoria è meno di un problema e il sovraccarico di cercare di trovare il file che ti serve sul filesystem è molto più preoccupante.

È un ragazzo intelligente e tende a sapere di cosa sta parlando. Tuttavia, ho sempre pensato che la memoria utilizzata da Apache e PHP fosse specifica per quella particolare richiesta gestita. Ad ogni richiesta viene assegnata una quantità di memoria pari all'opzione memory_limit PHP e qualsiasi compilazione ed elaborazione di origine è valida solo per la vita della richiesta.

Anche con cache op-code come APC, ho pensato che la singola richiesta deve ancora caricare ogni file nella sua porzione di memoria e che APC è solo una scorciatoia per averlo precompilato per il processo di risposta .

Ho cercato una documentazione su questo ma non sono riuscito a trovare nulla finora. Lo apprezzerei davvero se qualcuno potesse indicarmi qualsiasi documentazione utile su questo argomento.

UPDATE:

solo per chiarire, la parte discussione caricatore automatico era più di un contesto :).

Potrebbe non essere stato chiaro ma la mia domanda principale è se Apache riunirà le sue risorse per rispondere a più richieste (specialmente la memoria utilizzata dai file inclusi), o se ciascuna richiesta dovrà recuperare il codice richiesto per soddisfare il percorso di esecuzione in isolamento da altre richieste gestite dallo stesso processo.

ad es .: I file 1, 2, 3 e 4 sono della stessa dimensione di 100 KB ciascuno. Richiedere un include file di 1, 2 e 3. Richiesta B include file di 1, 2, 3 e 4.

Nella sua mente sta pensando che richiedono un consumerà 300 KB per la totalità di esso è l'esecuzione e Richiesta B solo la volontà consumare ulteriori 100 KB poiché i file 1,2 e 3 sono già in memoria.

Nella mia mente sono 300KB e 400KB perché sono entrambi elaborati indipendentemente (se per lo stesso processo).

Questo lo riporta alla sua argomentazione secondo cui "basta includere il lotto in quanto lo userete comunque" in contrapposizione al mio "include solo ciò che è necessario per mantenere la dimensione della richiesta verso il basso".

Questo è abbastanza fondamentale per il modo in cui mi avvicino alla costruzione di un sito Web PHP, quindi sarei curioso di sapere se sono fuori luogo qui.

Sono sempre stato convinto che per la memoria di siti Web su larga scala sia la risorsa più preziosa e più preoccupante dei controlli del file system per un autoloader che è probabilmente memorizzato nella cache dal kernel.

Hai ragione, è il momento di fare un punto di riferimento!

risposta

2

Sei il ninja più saggio, cavalletta.

I caricatori automatici non caricano il file di classe finché non viene richiesta la classe. Ciò significa che useranno al massimo la stessa quantità di memoria di quella manuale, ma in genere molto meno.

Le classi vengono lette di nuovo dal file ogni richiesta, anche se un thread di apache può gestire più richieste, in modo che gli eventi dei tuoi amici siano tutti letti 'non reggono l'acqua.

Si può provare mettendo un eco "pippo"; sopra la definizione della classe nel file di classe. Vedrai ad ogni nuova richiesta che la linea verrà eseguita indipendentemente dal fatto che tu autolieni o includi manualmente l'intero mondo dei file di classe all'inizio.

Non sono riuscito a trovare alcuna buona documentazione concisa su questo - potrei scrivere alcuni con alcuni esempi di utilizzo della memoria - come ho dovuto anche spiegare questo agli altri e mostrare le prove per farlo sprofondare. Penso la gente di Zend non pensava che nessuno avrebbe visto i vantaggi del caricamento automatico.

Sì, apc e così via (come tutte le soluzioni di caching) possono superare i risul- tati negativi e persino ottenere piccoli guadagni in termini di prestazioni, ma si consuma molta memoria non necessaria se lo si fa su un numero non banale di librerie e serve un gran numero di clienti. Prova qualcosa Come caricare una parte sana delle librerie di pere in un enorme file di inclusione mentre gestisci 500 connessioni che colpiscono la tua pagina allo stesso tempo.

Anche usando cose come Apc si beneficia dell'utilizzo di autoloader con qualsiasi classe non assegnata a un nome (la maggior parte del codice php attualmente esistente) in quanto può aiutare ad evitare l'inquinamento dello spazio dei nomi globale quando si tratta di grandi umbers di librerie di classi.

4

Ecco come si vincono gli argomenti: eseguire benchmark realistici ed essere sul lato destro dei numeri.

Ho avuto questa stessa discussione, quindi ho provato un esperimento. Usando APC, ho provato un'app Kohana con un singolo include monolitico (contenente tutto Kohana) e con il caricatore automatico standard. Il risultato finale è stato che l'inclusione singola era più veloce a un tasso statisticamente irrilevante (inferiore all'1%) ma utilizzato un po 'più di memoria (secondo le funzioni di memoria di PHP). Eseguire il test senza APC (o XCache, ecc.) È inutile, quindi non mi sono preoccupato.

Quindi la mia conclusione era continuare a utilizzare l'autoloading perché è molto più semplice da usare. Prova la stessa cosa con la tua app e mostra ai tuoi amici i risultati.

Ora non è necessario indovinare.

Disclaimer: Non stavo usando Apache. Non posso sottolineare abbastanza per eseguire i tuoi benchmark sul tuo hardware sulla tua app. Non fidarti che la mia esperienza sarà tua.

+0

Grazie Matthew, ho apportato una modifica al post originale nel caso in cui questo aiuti, ma eseguirò sicuramente alcuni test! – Sirhara

+0

Non sono sicuro di come mod_php gestisca la stessa pagina, ma se si utilizza una cache di opcode, i file PHP saranno sicuramente nella memoria condivisa. Il modo in cui capisco vanilla PHP, è che su ogni richiesta il file viene aperto, analizzato ed eseguito ... quindi non sono sicuro di dove si sarebbe verificata la condivisione della memoria. Penso che si arrivi ancora al benchmarking ... usa qualcosa come 'ab' per eseguire i test. Sono sicuro che vedrai che l'uso del caricamento automatico dipende o meno dalle preferenze personali ... Non penso che le prestazioni saranno significativamente diverse. – Matthew

0

Questo è il mio parere.

penso autoloader sono una pessima idea per i seguenti motivi

  1. mi piace sapere cosa e dove i miei script si accaparrano i dati/codice.Semplifica il debug.
  2. Questo ha anche problemi di configurazione in quanto se uno dei tuoi sviluppatori cambia il file (aggiornamento ecc.) O la configurazione e le cose smettono di funzionare è più difficile scoprire dove è rotto.
  3. Penso anche che sia una programmazione pigra.

Per quanto riguarda i problemi di memoria/preformance, è altrettanto economico acquistare un po 'più di memoria per il computer se è in difficoltà.

+1

potresti approfondire un po 'il motivo per cui pensi che si tratti di programmazione pigra? Sono curioso perché sembra abbastanza ragionevole avere una funzione di autoloader. – Dave

+1

@Dave - Penso che sia pigro non essere esplicito su ciò che costituisce il tuo script e fare affidamento sull'interprete per trovare il codice appropriato. Aiuta anche con la documentazione e la manutenzione futura. Perché è così difficile scrivere in 'require'? –

+0

@Ed si può sostenere che, a parità di condizioni, un programmatore pigro è migliore di uno che sta lavorando sodo tutto il tempo –

Problemi correlati