Considerazioni sulle prestazioni di PHP?

Question

Sto costruendo un sito PHP , ma per ora l'unico PHP che sto usando è una mezza dozzina di inclusioni su alcune pagine. (Probabilmente userò alcune query di database alla fine.)

Le semplici istruzioni include () sono una preoccupazione per la velocità o il ridimensionamento, al contrario di HTML statico? Quali tipi di cose tendono a far impantanare un sito?

Answer 1

In senso stretto, l'HTML diretto servirà sempre più velocemente di un approccio lato server poiché il server non deve interpretare il codice.

Per rispondere alla domanda più grande, ci sono una serie di cose che causeranno l'arresto del tuo sito; non esiste una soglia specifica per quando il codice sta causando il problema rispetto a PHP. (tieni presente che molti dei siti di Yahoo sono basati su PHP, quindi non pensare che PHP non possa ridimensionare).

Una cosa che ho notato è che i siti guidati da PHP che sono i più lenti sono quelli che includono più di quanto è necessario per visualizzare una pagina specifica. OSCommerce (oscommerce.com) è uno dei più popolari carrelli della spesa basati su PHP. Ha una cattiva abitudine, tuttavia, di includere tutte le loro funzionalità principali (nel caso sia necessario) in ogni singola pagina. Quindi, anche se non è necessario visualizzare un 'riquadro informativo', la funzione viene caricata. D'altra parte, ci sono molti framework PHP là fuori (come CakePHP, Symfony e CodeIgniter) che adottano un approccio "caricalo quando ne hai bisogno".

Vorrei consigliare quanto segue:

1. Non includere più funzionalità di quelle necessarie per una pagina specifica
2. Mantieni separate le funzioni di base (usa un approccio MVC quando possibile)
3. Usa require_once invece di include se pensi di avere inclusioni nidificate (ad es. la pagina A include il file B che include il file C). Ciò eviterà di includere lo stesso file più di una volta. Arresterà anche il processo se non è possibile trovare un file; aiutando così il processo di risoluzione dei problemi;)
4. Se possibile, memorizza nella cache le pagine statiche come HTML, per evitare di dover ripetere l'analisi quando le cose non cambiano

Answer 2

Certamente () è più lento delle pagine statiche. Tuttavia, con i sistemi moderni non è probabile che lo vedrai come un collo di bottiglia per molto tempo, se mai. I vantaggi dell'utilizzo includono per mantenere aggiornate le parti comuni del tuo sito superando il piccolo impatto sulle prestazioni, a mio avviso (avere una navigazione diversa su una pagina perché ti sei dimenticato di aggiornarlo porta a una brutta esperienza per l'utente, e quindi a cattive sensazioni sulla tua sito / azienda / altro).

L'uso della cache non è di grande aiuto: il codice della cache sarà più lento di un semplice include (). L'unica volta che la cache sarà di beneficio se si eseguono calcoli ad alta intensità di calcolo (molto raro, su pagine Web) o si acquisiscono dati da un database.

Answer 3

Sembra che tu stia partecipando a un po 'di ottimizzazione prematura. Se l'applicazione non viene creata, mentre le preoccupazioni relative alle prestazioni sono utili, la tua preoccupazione principale dovrebbe essere quella di scrivere l'app.

Include sono un dato di fatto. Non preoccuparti del numero, preoccupati di mantenere il tuo codice ben organizzato (la struttura delle cartelle PEAR è una cosa adorabile, se non sai di cosa sto parlando guarda la struttura dei file di classe di Zend Framework).

Concentrati su come scrivere l'applicazione con una ragionevole quantità di astrazione. Raggruppa tutte le tue chiamate DB in una classe (o classi) in modo da ridurre al minimo la duplicazione del codice (principi KISS e tutti) e quando arriva il momento di refactoring e ottimizzare le tue query, si trovano in posizione centrale. Inizia anche con alcuni test unitari per prevenire la regressione.

Una volta che l'applicazione è attiva e funzionante, non chiederci cosa è più veloce o migliore poiché dipende da ogni applicazione quale sarà il tuo collo di bottiglia. Si può scoprire che, anche se hai un sacco di inclusioni, i tuoi loop stanno consumando il tuo tempo, o altro. Usa XDebug e profila il tuo codice una volta attivo e funzionante. Cerca i segmenti di codice che stanno consumando una quantità sproporzionata di tempo, quindi il refactor. Se ti concentri troppo ora sul colpo di performance tra include e include_once finirai per inseguire un fantasma quando quelle richieste di arricciatura in esecuzione in sincronia stanno facendo colazione.

Anche se nel frattempo, i migliori suggerimenti sono consultare il manuale di php.net e assicurarsi che se c'è una funzione integrata che fa qualcosa che stai cercando di fare, usala! Le estensioni basate su C di PHP saranno sempre più veloci di qualsiasi codice PHP che potresti scrivere e rimarrai sorpreso di quanto già stai facendo.

Ma ancora una volta, non posso sottolinearlo abbastanza, l'ottimizzazione prematura è MALE !!! Basta far decollare l'applicazione con buoni livelli di astrazione, profilarla, quindi correggere ciò che effettivamente sta mangiando il tuo tempo piuttosto che fissare ciò che pensi possa farti perdere tempo.

Answer 4

Nah include bene, niente di cui preoccuparsi.

Potresti pensare di modificare un po 'le intestazioni della cache a un certo punto, ma a meno che tu non ottenga hit significative, non dovrebbe essere un problema. Supponendo che si tratti di tutti i dati statici, potresti anche considerare di convertire l'intero sito in HTML statico (modo più semplice: scrivere uno script che acquisisce ogni pagina tramite il server web e lo scarica in una struttura di directory corrispondente)

La maggior parte delle applicazioni Web è limitata dalla velocità del loro database (o qualunque sia la loro memoria esterna, ma 9/10 volte che sarà un database), il codice dell'applicazione raramente è motivo di preoccupazione e non suona come se stessi facendo qualcosa di cui devi ancora preoccuparti.

Answer 5

Prima di prendere decisioni di lunga durata su come strutturare il codice per il tuo sito, ti consiglio di leggere un po 'su Modello-Vista-Controller modello di progettazione. Mentre ce ne sono altri, sembra che questo stia guadagnando molto terreno nei circoli di sviluppo web e sicuramente ci sarà per un po '. Potresti dare un'occhiata ad alcuni degli altri modelli di design suggeriti da Martin Fowler nel suo Patterns of Enterprise Application Architettura prima di prendere qualsiasi decisione finale su quale tipo di design si adatta meglio alle tue esigenze.

A seconda delle dimensioni e dell'ambito del progetto, potresti voler scegliere un framework già pronto per PHP come Zend Framework o PHP On Trax oppure puoi decidere di creare la tua soluzione.

In particolare per quanto riguarda il rendering del contenuto HTML, ti consiglio caldamente di utilizzare una qualche forma di modello per mantenere la tua logica di business separata dalla tua logica di visualizzazione. Ho scoperto che questa semplice regola del mio sviluppo mi ha permesso di risparmiare ore di lavoro quando l'una o l'altra dovevano essere cambiate. Ho usato http://www.smarty.net/">Smarty e so che la maggior parte dei framework là fuori hanno un proprio sistema di template o forniscono un'architettura plug-in che ti consente di usare il tuo proprio metodo preferito. Mentre osservi le possibili soluzioni, ti consiglio di cercarne una in grado di creare versioni memorizzate nella cache.

Infine, se sei preoccupato per la velocità del back-end, ti consiglio vivamente di cercare modi per ridurre al minimo le chiamate nell'archivio dati back-end (sia esso un database o solo file di sistema). Cerca di evitare il caricamento e il rendering di troppi contenuti (ad esempio un report di grandi dimensioni archiviato in una tabella che contiene centinaia di record) contemporaneamente. Se possibile, cercare modi per far caricare alla volta l'interfaccia di bit di dati più piccoli alla volta. E se sei particolarmente preoccupato per il tempo di caricamento effettivo del tuo contenuto html e dei suoi CSS, Javascript o altre dipendenze, ti consiglio di leggere questi suggerimenti dei ragazzi di Yahoo !.

Answer 6

Per aggiungere ciò che JayTee ha menzionato: caricare la funzionalità quando ne hai bisogno. Se non stai usando nessuno dei framework che lo fanno automaticamente, potresti voler esaminare la funzionalità __autoload () che è stata introdotta in PHP5 - in sostanza, la tua logica può essere invocata quando crei un'istanza di una particolare classe se non è già caricato. Questo ti dà la possibilità di includere () un file che definisce quella classe su richiesta.

Answer 7

La cosa più grande che puoi fare per velocizzare la tua applicazione è usare una cache Opcode, come APC . C'è un eccellente elenco e una descrizione disponibili su Wikipedia .

Per quanto riguarda le semplici inclusioni, fare attenzione a non includere troppi file su ogni richiesta poiché l'I / O del disco può causare il ridimensionamento corretto dell'applicazione. Alcune dozzine di inclusioni dovrebbero andare bene, ma in genere è una buona idea raggruppare i file più comunemente inclusi in un singolo script in modo da avere solo una inclusione. Il costo in memoria di avere alcune classi qua e là che non è necessario caricare sarà migliore del costo dell'I / O del disco per l'inclusione di centinaia di file più piccoli.