Le miniature generate da PHP vengono caricate lentamente

Domanda Parte A ▉ (100 premi, assegnati)
La domanda principale era come rendere questo sito, caricare più velocemente. Per prima cosa dovevamo leggere queste cascate. Grazie a tutti per i suggerimenti sull'analisi della lettura a cascata. Evidente dai vari grafici a cascata mostrati qui è il principale collo di bottiglia: le miniature generate da PHP. Il caricamento jquery senza protocollo da CDN consigliato da David ha ottenuto la mia ricompensa, sebbene abbia reso il mio sito solo il 3% più veloce in generale e pur non rispondendo al principale collo di bottiglia del sito. È tempo di chiarire la mia domanda e, un'altra grazia:

Domanda Parte B ▉ (100 premi assegnati)
Il nuovo obiettivo era ora quello di risolvere il problema che avevano le 6 immagini jpg, che stanno causando la maggior parte del ritardo di caricamento. Queste 6 immagini sono miniature generate da PHP, minuscole e solo 3 ~ 5 kb, ma si caricano in modo relativamente molto lento. Notare il " tempo al primo byte " sui vari grafici. Il problema rimase irrisolto, ma una ricompensa andò a James, che riparò l'errore di intestazione sottolineato da RedBot : "Una richiesta condizionale If-Modified-Since ha restituito il contenuto completo invariato". .

Domanda Parte C ▉ (la mia ultima ricompensa: 250 punti)
Sfortunatamente, dopo che è stato corretto anche l'errore di intestazione di REdbot.org, il ritardo causato dalle immagini generate da PHP è rimasto intatto. Cosa diavolo stanno pensando queste minuscole miniature da 3 ~ 5Kb? Tutte queste informazioni di intestazione possono inviare un razzo sulla luna e ritorno. Qualsiasi suggerimento su questo collo di bottiglia è molto apprezzato e trattato come una possibile risposta, dal momento che sono bloccato su questo problema di collo di bottiglia già da sette mesi. Grazie in anticipo.

[Alcune informazioni di base sul mio sito: CSS è in alto. JS in basso (Jquery, JQuery UI, ha acquistato i motori menu awm / menu.js, le schede js engine, il video swfobject.js) Le linee nere sulla seconda immagine mostrano cosa sta iniziando cosa caricare. Il robot arrabbiato è il mio animale domestico "ZAM". È innocuo e spesso più felice.]

Carica cascata: cronologica | http://webpagetest.org

Domini paralleli raggruppati | http://webpagetest.org

Cascata Site-Perf | http://site-perf.com

Cascata degli strumenti di Pingdom | http://tools.pingdom.com

Cascata GTmetrix | http://gtmetrix.com

Innanzitutto, l'utilizzo di più domini richiede diverse ricerche DNS. Faresti meglio a combinare molte di quelle immagini in uno sprite invece di diffondere le richieste.

In secondo luogo, quando carico la tua pagina, vedo la maggior parte dei blocchi (~ 1.25s) su all.js. Vedo che inizia con (una vecchia versione di) jQuery. Dovresti fare riferimento a questo da Google CDN, non solo per ridurre i tempi di caricamento , ma potenzialmente evitare una richiesta HTTP per esso interamente.

In particolare, le librerie dell'interfaccia utente jQuery e jQuery più recenti possono essere referenziate a questi URL (vedi questo post se sei interessato al motivo per cui ho omesso http:):

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

Se stai utilizzando uno dei temi dell'interfaccia utente jQuery predefiniti, puoi anche estrarre il CSS e le immagini dalla CDN di Google .

Con l'hosting jQuery ottimizzato, dovresti anche combinare awmlib2.js e tooltiplib.jsin un singolo file.

Se affronti queste cose, dovresti vedere un miglioramento significativo.

Ho avuto un problema simile a pochi giorni fa e ho trovato head.js . È un plug-in Javascript che ti consente di caricare tutti i file JS in parallelo. Spero che aiuti.

Sono tutt'altro che un esperto ma ...

A questo proposito: "Una richiesta condizionale If-Modified-Since ha restituito il contenuto completo invariato." e i miei commenti.

Il codice utilizzato per generare le anteprime dovrebbe verificare quanto segue:

1. Esiste una versione cache dell'anteprima.
2. La versione memorizzata nella cache è più recente dell'immagine originale?

Se uno di questi è falso, l'anteprima deve essere generata e restituita, qualunque cosa accada. Se sono entrambi veri, è necessario effettuare il seguente controllo:

1. Esiste un'intestazione HTTP_IF_MODIFIED_SINCE
2. L'ultima modifica della versione cache è la stessa di HTTP_IF_MODIFIED_SINCE

Se uno di questi è falso, è necessario restituire la miniatura memorizzata nella cache.

Se entrambi sono veri, dovrebbe essere restituito uno stato di 304 http. Non sono sicuro che sia necessario, ma restituisco personalmente anche le intestazioni Cache-Control, Expires e Last-Modified insieme al 304.

Per quanto riguarda GZipping, sono stato informato che non è necessario GZip per le immagini, quindi ignora quella parte del mio commento.

Modifica: non ho notato la tua aggiunta al tuo post.

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

Sono anche sicuro che il tuo codice deve verificare l'intestazione HTTP_IF_MODIFIED_SINCE e reagire ad esso. Basta impostare queste intestazioni e il tuo file .htaccess non fornirà il risultato richiesto.

Penso che tu abbia bisogno di qualcosa del genere:

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data

Wow, è difficile spiegare le cose usando quell'immagine .. Ma qui, alcuni tentativi:

• i file 33-36 vengono caricati in ritardo, poiché vengono caricati in modo dinamico all'interno di swf e swf (25) viene caricato prima completamente prima di caricare qualsiasi contenuto aggiuntivo
• i file 20 e 21 sono forse (non lo so, perché non conosco il tuo codice) librerie caricate da all.js (11), ma per l'esecuzione di 11, attende l'intera pagina (e risorse) caricare (dovresti cambiarlo in domready)
• i file 22-32 vengono caricati da queste due librerie, dopo che sono stati caricati completamente

Una semplice ipotesi perché questo tipo di analisi richiede molti test A / B: il tuo dominio .ch sembra essere difficile da raggiungere (lunghe bande verdi prima dell'arrivo del primo byte).

Ciò significherebbe che il sito Web .ch è scarsamente ospitato o che l'ISP non ha una buona strada per raggiungerli.

Dati i diagrammi, questo potrebbe spiegare un grande successo in termini di prestazioni.

Una nota a margine , c'è questo fantastico strumento che può aiutarti a risolvere le cose in base all'ordinamento del caricamento delle risorse.

Prova a eseguire i test Y! Slow e Page Speed ​​sul tuo sito / pagina e segui le linee guida per risolvere i possibili colli di bottiglia nelle prestazioni. Dovresti ottenere enormi miglioramenti delle prestazioni una volta ottenuto un punteggio più alto in Y! Slow o Page Speed.

Questi test ti diranno cosa c'è che non va e cosa cambiare.

Quindi il tuo script PHP sta generando le anteprime ad ogni caricamento della pagina? Prima di tutto, se le immagini che vengono visualizzate in anteprima non cambiano così spesso, potresti impostare una cache in modo tale che non debbano essere analizzate ogni volta che la pagina viene caricata? In secondo luogo, il tuo script PHP sta usando qualcosa di simile imagecopyresampled()per creare le miniature? Questo è un downsample non banale e lo script PHP non restituirà nulla fino a quando non sarà fatto restringere le cose. L'uso imagecopymerged()invece ridurrà la qualità dell'immagine, ma accelererà il processo. E quanta riduzione stai facendo? Queste miniature hanno il 5% delle dimensioni dell'immagine originale o il 50%? Una dimensione maggiore dell'immagine originale probabilmente sta portando a un rallentamento poiché lo script PHP deve salvare l'immagine originale in memoria prima che possa ridurla e produrre una miniatura più piccola.

Ho trovato l'URL del tuo sito Web e controllato un singolo file jpg dalla homepage. Mentre il tempo di caricamento è ragionevole ora (161ms), è in attesa di 126ms, che è troppo.

Le tue ultime intestazioni modificate sono tutte impostate su Sab, 01 gen 2011 12:00:00 GMT, che sembra troppo "rotondo" per essere la vera data della generazione ;-)

Poiché il controllo della cache è "pubblico, età massima = 14515200", le intestazioni arbitrarie dell'ultima modifica potrebbero causare problemi dopo 168 giorni.

Comunque, questa non è la vera ragione dei ritardi.

Devi controllare cosa fa il tuo generatore di miniature quando la miniatura esiste già e cosa potrebbe richiedere così tanto tempo per controllare e consegnare l'immagine.

È possibile installare xdebug per profilare lo script e vedere dove si trovano i colli di bottiglia.

Forse il tutto usa un framework o si connette a qualche database per niente. Ho visto mysql_connect () molto lento su alcuni server, principalmente perché si stavano connettendo usando TCP e non socket, a volte con alcuni problemi DNS.

Capisco che non puoi pubblicare qui il tuo generatore di pagamenti, ma temo che ci siano troppi problemi possibili ...

Se non c'è un motivo davvero valido (di solito non esiste) le tue immagini non dovrebbero invocare l'interprete PHP.

Crea una regola di riscrittura per il tuo server web che server l'immagine direttamente se viene trovata sul file system. In caso contrario, reindirizza allo script PHP per generare l'immagine. Quando si modifica l'immagine, modificare il nome file delle immagini per forzare gli utenti che dispongono di una versione cache a recuperare l'immagine appena modificata.

Se almeno non funziona, ora non ha nulla a che fare con il modo in cui le immagini vengono create e controllate.

Analizza l'utilizzo dei dati della sessione da parte di PHP. Forse (solo forse), lo script PHP che genera immagini è in attesa di ottenere un blocco sui dati della sessione, che è bloccato dalla pagina principale di rendering ancora o da altri script di rendering di immagini. Ciò renderebbe quasi irrilevanti tutte le ottimizzazioni JavaScript / browser, poiché il browser è in attesa del server.

PHP blocca i dati della sessione per ogni script in esecuzione, dal momento in cui inizia la gestione della sessione, al momento in cui termina lo script o quando viene chiamato session_write_close (). Questo serializza efficacemente le cose. Dai un'occhiata alla pagina PHP sulle sessioni, in particolare i commenti, come questo .

Questa è solo un'ipotesi selvaggia poiché non ho esaminato il tuo codice ma sospetto che le sessioni possano svolgere un ruolo qui, quanto segue dalla voce del Manuale PHP su session_write_close():

I dati della sessione vengono in genere archiviati dopo la chiusura dello script senza la necessità di chiamare session_write_close (), ma poiché i dati della sessione sono bloccati per impedire scritture simultanee, solo uno script può operare su una sessione in qualsiasi momento. Quando si utilizzano i set di frame insieme alle sessioni, i frame si caricheranno uno alla volta a causa di questo blocco. È possibile ridurre il tempo necessario per caricare tutti i frame terminando la sessione non appena vengono apportate tutte le modifiche alle variabili di sessione.

Come ho detto, non so cosa stia facendo il tuo codice ma quei grafici sembrano stranamente sospetti. Ho avuto un problema simile quando ho codificato una funzione di servizio di file multipart e ho avuto lo stesso problema. Durante la pubblicazione di un file di grandi dimensioni non sono riuscito a far funzionare la funzionalità multipart né ho potuto aprire un'altra pagina fino al completamento del download. Chiamare session_write_close()risolto entrambi i miei problemi.

Hai provato a sostituire i thumnails generati da php con immagini regolari per vedere se c'è qualche differenza? Il problema potrebbe sorgere - un bug nel tuo codice php che porta a una rigenerazione della miniatura su ogni chiamata del server - un ritardo nel tuo codice (sleep ()?) Associato a un problema di clock - un problema hardrive che causa una pessima condizione di gara poiché tutte le anteprime vengono caricate / generate contemporaneamente.

Penso che invece di usare quello script del generatore di miniature devi provare TinySRC per una generazione di miniature rapida e ospitata sul cloud. Ha un'API molto semplice e facile da usare, puoi usare come: -

http://i.tinysrc.mobi/ [height] / [width] /http://domain.tld/path_to_img.jpg

[larghezza] (opzionale): - Questa è una larghezza in pixel (che sovrascrive il dimensionamento adattivo o familiare). Se il prefisso è '-' o 'x', verrà sottratto o ridotto a una percentuale della dimensione determinata.

[altezza] (opzionale): - Questa è un'altezza in pixel, se è presente anche la larghezza. Sovrascrive anche il dimensionamento adattivo o familiare e può essere preceduto da "-" o "x".

Puoi controllare il riepilogo API qui

FAQ

Quanto mi costa tinySrc?

Niente.

Quando posso iniziare a usare tinySrc?

Adesso.

Quanto è affidabile il servizio?

Non garantiamo il servizio tinySrc. Tuttavia, funziona su un'importante infrastruttura cloud distribuita , quindi offre elevata disponibilità in tutto il mondo. Dovrebbe essere sufficiente per tutte le tue esigenze.

Quanto è veloce?

tinySrc memorizza nella cache le immagini ridimensionate in memoria e nel nostro archivio dati per un massimo di 24 ore e non recupererà ogni volta l'immagine originale. Questo rende i servizi incredibilmente veloci dal punto di vista dell'utente. (E riduce il carico del server come un piacevole effetto collaterale.)

In bocca al lupo. Solo un suggerimento, dal momento che non ci stai mostrando il codice: p

Poiché alcuni browser scaricano solo 2 download paralleli per dominio, non è possibile aggiungere domini aggiuntivi per suddividere le richieste su due o tre nomi host diversi. ad es. 1.imagecdn.com 2.imagecdn.com

Prima di tutto, devi gestire le If-Modified-Sincerichieste e in modo appropriato, come ha detto James. Questo errore indica che: "Quando chiedo al tuo server se quell'immagine è stata modificata dall'ultima volta, invia l'intera immagine invece di un semplice sì / no".

Il tempo tra la connessione e il primo byte è generalmente il tempo impiegato per l'esecuzione dello script PHP. È evidente che qualcosa sta accadendo quando lo script inizia a essere eseguito.

1. Hai pensato di profilarlo? Potrebbe avere alcuni problemi.
2. In combinazione con il problema precedente, lo script potrebbe essere in esecuzione molte più volte del necessario. Idealmente, dovrebbe generare i pollici solo se l'immagine originale viene modificata e inviare i pollici memorizzati nella cache per ogni altra richiesta. Hai verificato che lo script generi inutilmente le immagini (ad es. Per ogni richiesta)?

Generare le intestazioni corrette attraverso l'applicazione è un po 'complicato, inoltre possono essere sovrascritti dal server. E sei esposto ad abusi in quanto chiunque invii alcune intestazioni di richiesta senza cache farà funzionare il tuo generatore di miniature continuamente (e aumenterà i carichi). Quindi, se possibile, prova a salvare i pollici generati, chiama le immagini salvate direttamente dalle tue pagine e gestisci le intestazioni .htaccess. In questo caso, non avresti nemmeno bisogno di nulla nel .htaccesstuo server se il tuo server è configurato correttamente.

Oltre a questi, puoi applicare alcune delle brillanti idee di ottimizzazione dalle parti relative alle prestazioni di questa bella domanda SO generale su come fare i siti Web nel modo giusto , come suddividere le tue risorse in sottodomini senza cucina, ecc. Ma in ogni caso, un'immagine 3k non dovrebbe richiedere un secondo per caricare, questo è evidente rispetto ad altri elementi nei grafici. Dovresti provare a individuare il problema prima di ottimizzare.

Hai provato a configurare diversi sottodomini nel server web NGINX appositamente per servire dati statici come immagini e fogli di stile? Qualcosa di utile potrebbe essere già stato trovato in questo argomento .

Per quanto riguarda le miniature ritardate, prova a mettere una chiamata a flush () immediatamente dopo l'ultima chiamata a header () nello script di generazione delle miniature. Una volta fatto, rigenerare il grafico a cascata e vedere se il ritardo è ora sul corpo anziché sulle intestazioni. In tal caso, è necessario esaminare a lungo la logica che genera e / o genera i dati dell'immagine.

Si spera che lo script che gestisce le anteprime utilizzi una sorta di memorizzazione nella cache in modo che qualsiasi azione intraprenda sulle immagini che servi avverrà solo quando assolutamente necessario. Sembra che si stia svolgendo un'operazione costosa ogni volta che servi le anteprime che ritardano qualsiasi output (comprese le intestazioni) dallo script.

La maggior parte del problema lento è che il tuo TTFB (tempo al primo byte) è troppo alto. È difficile da affrontare senza essere intimi con i file di configurazione del server, il codice e l'hardware sottostante, ma posso vedere che dilaga su ogni richiesta. Hai troppe barre verdi (cattive) e pochissime barre blu (buone). Potresti voler smettere di ottimizzare un po 'il frontend, poiché credo che tu abbia fatto molto in quella zona. Nonostante il detto che "l' 80% -90% del tempo di risposta dell'utente finale viene speso nel frontend ", credo che il tuo si stia verificando nel backend.

TTFB è roba back-end, roba server, pre-elaborazione prima dell'output e handshaking.

Calcola il tempo di esecuzione del codice per trovare elementi lenti come le query lente del database, inserire e uscire da funzioni / metodi per trovare funzioni lente. Se usi php, prova Firephp . A volte si tratta di una o due query lente in esecuzione durante l'avvio o l'inizializzazione come estrarre informazioni sulla sessione o controllare l'autenticazione e cosa no. L'ottimizzazione delle query può portare ad alcuni buoni guadagni perf. A volte il codice viene eseguito utilizzando php prepend o spl autoload in modo che funzionino su tutto. Altre volte può essere configurato in modo errato apache conf e tweaking che salva la giornata.

Cerca loop inefficienti. Cercare chiamate a recupero lento di cache o operazioni di I / O lente causate da unità disco guaste o elevato utilizzo dello spazio su disco. Cerca gli usi della memoria e ciò che viene utilizzato e dove. Esegui un test ripetuto webpagetest di 10 esecuzioni su una singola immagine o file utilizzando solo la prima vista da diverse posizioni nel mondo e non dalla stessa posizione. E leggi i tuoi log degli accessi e degli errori, troppi sviluppatori li ignorano e fanno affidamento solo sugli errori visualizzati sullo schermo. Se il tuo host web ha supporto, chiedi aiuto, se non glielo chiedono educatamente, non farà male.

Puoi provare il prefetching DNS per combattere molti domini e risorse, http://html5boilerplate.com/docs/DNS-Prefetching/

Il tuo server è un server buono / decente? A volte un server migliore può risolvere molti problemi. Sono un fan della mentalità ' hardware è economico, i programmatori sono costosi ', se hai la possibilità e il denaro di aggiornare un server. E / O usa un CDN come maxcdn o cloudflare o simili.

In bocca al lupo!

(ps non lavoro per nessuna di queste aziende. Anche il link cloudflare sopra sosterrà che il TTFB non è così importante, l'ho gettato lì in modo da poter avere un altro introito.)

Mi dispiace dirlo, fornisci pochi dati. E hai già avuto dei buoni suggerimenti.

Come stai servendo quelle immagini? Se trasmetti in streaming tramite PHP stai facendo una cosa molto brutta, anche se sono già generati.

NON STREAM MAI IMMAGINI CON PHP. Rallenterà il tuo server, indipendentemente dal modo in cui lo usi.

Inseriscili in una cartella accessibile, con un URI significativo. Quindi chiamali direttamente con il loro vero URI. Se hai bisogno della generazione al volo dovresti inserire un .htaccess nella directory delle immagini che reindirizza a uno script php del generatore solo se manca l'immagine della richiesta. (questo si chiama strategia cache-on-request).

Ciò risolverà la sessione php, il proxy del browser, la memorizzazione nella cache, ETAGS, qualunque cosa tutto in una volta.

WP-Supercache utilizza questa strategia, se configurato correttamente.

L'ho scritto qualche tempo fa ( http://code.google.com/p/cache-on-request/source/detail?r=8 ), le ultime revisioni sono rotte, ma suppongo che 8 o meno dovrebbero funzionare e tu puoi prendi il .htaccess come esempio solo per testare le cose (anche se ci sono modi migliori per configurare il .htaccess rispetto al modo in cui ero solito).

Ho descritto quella strategia in questo post sul blog ( http://www.stefanoforenza.com/need-for-cache/ ). Probabilmente è scritto male ma può aiutare a chiarire le cose.

Ulteriori letture: http://meta.wikimedia.org/wiki/404_handler_caching