it-swarm.it

Esperienza nel mondo reale nel ridimensionamento e ottimizzazione delle prestazioni

Si presume che il sito Web su cui sto lavorando avrà un enorme tasso di hit subito dopo il lancio . Il cliente sta parlando della possibilità di circa 2500 colpi al secondo in circa un giorno.

Ignorando il fatto che questa hit rate è probabilmente l'ottimismo del client selvaggio e oltre a ottenere i server più grandi possibili, qual è il modo migliore che Drupal dovrebbe essere configurato per supportare una hit rate di grandi dimensioni.

Ho letto Ridimensionare drupal.org Infrastruttura , Drupal performance blog , Best practice per ridimensionare Drupal e molte altre pagine, ma cosa Sto cercando è la vera esperienza di fare questo, cosa funziona, cosa non funziona e cosa aspettarsi.

52

La risposta di Markdorison è sostanzialmente il metodo accettato per attaccare questo problema. Lo porterò un po 'oltre.

Quando hai Pressflow per D6 o Drupal per D7, Memcached e Varnish tutto funziona bene insieme, dovrai codificare il tuo - VCL file. Sono disponibili file gratuiti che rendono i punti di partenza ma devi sempre giocare con loro.

Per far funzionare Varnish in modo ottimale, assicurati di avviarlo con -s malloc xG piuttosto che con il predefinito -s file/path/to/file. Inoltre con Varnish puoi avere oggetti statici nella cache di Varnish il più a lungo possibile.

Se hai più di un server web, rimuovi ETag dall'intestazione inviata a Varnish in VCL. Inoltre rimuovo Scadenza e faccio semplicemente affidamento su Età e età massima nelle intestazioni, in modo da riportare i browser sul sito.

La versione 1.5 (al 3 marzo 2011) è ancora la versione più veloce del modulo Memcached da Drupal.org. In genere lo distribuisco utilizzando un unico bin per server per ridurre il traffico TCP per le connessioni a più bin su larga scala)

Configurare la memorizzazione nella cache in "Prestazioni" su esterno e impostare un'età massima che invierà le intestazioni corrette a un proxy di memorizzazione nella cache come Varnish.

Se non riesci a far sì che determinate pagine vengano memorizzate correttamente nella cache in Varnish, consulta i post sul blog sul Web che descrivono in dettaglio come controllare le richieste. Ecco un post di esempio che ho scritto qualche tempo fa: Cosa sta fermando Varnish e Drupal Pressflow dalla memorizzazione nella cache delle visualizzazioni di pagina degli utenti anonimi

Dovresti scegliere InnoDB (o uno dei suoi altri nomi da altri provider come XtraDB) per MySQL e spostare tutte le tabelle in esso. Quindi consulta questo post del blog per consigli di base sulla messa a punto http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

Avere un grande pool di buffer è di fondamentale importanza. Quando si carica il test, il sito attiva il registro delle query lente. Probabilmente all'inizio è necessario acquisire query che richiedono più di 50 msec, quindi ottimizzare le query e ridurre ripetutamente il tempo di acquisizione del log lento fino a quando la maggior parte delle query viene eseguita utilizzando gli indici e l'esecuzione abbastanza rapidamente.

Altre basi includono avere APC in per PHP. Se cerchi CGI veloce piuttosto che mod_php, passa un po 'di tempo a provare a rendere la cache APC condivisa tra le istanze php configurando un buon script wrapper. Assicurati anche che la cache APC sia in un file mappato in memoria per spremere l'ultimo bit da PHP.

45

Vorrei raccomandare di iniziare con Pressflow (se si utilizza Drupal 6), Memcache , Vernice e qualche modulo di Content Distribution Network (CDN) come Akamai. Il risultato finale dovrebbe essere il minor numero possibile di quegli utenti che colpiscono effettivamente il tuo server Origin.

Se hai parti della pagina che non sei in grado di memorizzare nella cache per utenti non anonimi (cose specifiche per quell'utente, "Benvenuto utenteX" ecc.), Puoi esplorare le opzioni per popolare queste parti della pagina come asincrone callbacks o Edge side include.

Se hai un gruppo più piccolo di utenti interni (come un gruppo di editor) che devono essere in grado di visualizzare una versione non memorizzata del sito, ti consiglio di esporre una versione non memorizzata del tuo sito a un URL diverso (protetto dietro una VPN o equivalente se possibile).

22
markdorison

2500 hit al secondo in un giorno - se per "hit" intendi "pagina consegnata", allora sono 216 milioni di pagine al giorno. Lascia che ti dica questo: non hai 216 milioni di pagine al giorno. Adoro questi clienti ...

Detto questo, un dato di traffico non elaborato non dice nulla. Mentre i consigli in questo thread sono validi su Varnish/CDN se tutto ciò che hai è traffico anonimo ma se hai effettuato l'accesso, stai affrontando una sfida. Ma prima di spendere una quantità ingenua di tempo e sforzi per risolvere un problema, assicurati di avere un problema. 2500 colpi al secondo, Bing ne ottiene di meno, lo capisci, vero?

15
user49
  • Lato server

    • Installa Varnish per la memorizzazione nella cache delle pagine per utenti anonimi.
    • Installa un sistema di cache persistente (Memcached, APC, Memcache).
    • Utilizzare un CDN come Akamai per servire file statici (JavaScript, CSS, immagini).
  • Lato codice

    • Usa Pressflow, consente a Varnish di servire pagine cache per utenti anonimi.
    • Pulisci il tavolo da guardia di Drupal. Ogni volta che viene registrato un errore del watchdog, si consumano risorse della CPU sul server Web e sul server database. Inoltre aumenta significativamente il tempo di caricamento.
    • Implementare strategie cache statica e persistente fino a quando il registro delle query lente non risulta pulito.
    • Evitare PHP errori che si verificano all'interno dei cicli foreach nidificati a tutti i costi.
    • Disinstallare i moduli non utilizzati.
    • Attiva la memorizzazione nella cache per Drupal blocchi e visualizzazioni principali.
  • Database

    • Assicurarsi che le tabelle siano correttamente indicizzate per una ricerca più rapida.
    • Non memorizzare record non necessari, si accederà sempre a un database di 100 nodi più velocemente di un database di 3 milioni di nodi.
6
amateur barista

Vorrei anche ascoltare questo podcast di Lullabot sul modo in cui hanno creato il sito Web Grammys.com per un'esplosione di traffico nel corso di una settimana. Era una spiegazione piuttosto educativa.

http://www.lullabot.com/podcasts/podcast-92-grammycom

5
Randy Burgess

Per i siti Web ad alto traffico è necessario utilizzare più server e bilanciamento del carico o utilizzare semplicemente la CDN. Inoltre è molto importante memorizzare nella cache il più possibile per ridurre al minimo il carico sui server Web.

L'uso di Content Delivery Network ( CDN ) aiuta a distribuire le risorse su più domini (suddivisione del dominio), riducendo il carico sul server web.

L'uso della CDN aiuta con la cache distribuita e l'accelerazione remota, aiuta anche a mitigare attacchi DDoS , a causa di più end-point. Aiuta con sicurezza, perché il contenuto memorizzato nella cache è più difficile da sfruttare.

Provider di esempio: Fastly , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

Ecco alcuni altri suggerimenti:

  • Con CDN, utilizzare domini senza cookie per i componenti statici da memorizzare nella cache (come sstatic.net ). Poiché alcuni proxy potrebbero rifiutare di memorizzare nella cache i componenti richiesti con i cookie.
  • Riscalda le cache dopo averle cancellate (usando wget, Cache Warmer , Drush ECL ).
  • Usa il monitoraggio delle prestazioni (ad es. New Relic o Yottaa che hanno l'integrazione per Drupal).
  • Utilizza lo strumento di monitoraggio per il tuo sito Web (ad esempio Nagios).
  • Installa Varnish e Varnish HTTP Accelerator Integration module , quindi configuralo .
  • Varnish + Authcache: selezionare questo Esempio VCL per Authcache File di configurazione della vernice.
  • Considera Pound o NGINX davanti a Varnish. Vedi: Perché Pound è fantastico di fronte a Varnish .
  • NGINX può funzionare come proxy inverso e bilanciamento del carico, quindi può sostituire Pound e Varnish.
  • Prendi in considerazione una versione commerciale di Varnish o NGINX per utilizzare funzionalità non disponibili nella versione open source "community".
  • Prendi in considerazione il bilanciamento del carico hardware/la memorizzazione nella cache per sostituire Varnish e Pound (ad es. BIG-IP F5 ).
  • Usa strumenti come ab, JMeter per TTFB , test di carico e stress sulla tua applicazione web.

Quindi la tua architettura web dal punto di vista dell'utente può apparire come:

  1. Utente (memorizzazione nella cache del browser locale).
  2. NGINX o Pound + Varnish (bilanciamento del carico, proxy inverso come acceleratore HTTP).
  3. Apache (web server).
  4. PHP-FPM (PHP FastCGI Process Manager).
  5. MariaDB (database).

Per Drupal suggerimento di ottimizzazione, controllare: Come si migliora Drupal prestazioni?

3
kenorb

Mentre è molto difficile prevedere i modelli, se si ha una buona idea dei livelli di traffico. Carica prova la tua soluzione. Esistono numerose opzioni diverse e non sarà possibile prevedere molto fino a quando non si avrà traffico in tempo reale, ma se si carica il test il più possibile almeno si avrà un discreto grado di sicurezza che la propria configurazione può gestire il traffico.

Tutta l'accordatura nel mondo non sarà d'aiuto se non la provi prima.

Questa è stata una presentazione a DC SF su come l'economista ha fatto. http://sf2010.drupal.org/conference/sessions/performance-testing-economist-online- using-smerigliatrice

3
Jeremy French

È inoltre possibile esaminare la ridistribuzione del carico su più server con l'aiuto di una soluzione basata su DNS o di bilanciamento del carico software/hardware. Ciò comporterebbe anche una tolleranza agli errori.

0
James Stallings

Abilita due estensioni:

  • Zend OPcache
  • wincache

La tua performance funzionerà meglio.

Se stai cercando twig Zend OPcache e Wincache in Microsoft Azure, crea prima un nome di cartella 'ini' sotto 'D:\home\site\'. Inoltre, crea 2 file, '.user.ini' e 'settings.ini'

Aggiungi la seguente configurazione in ciascun file:

user.ini.

[PHP]
post_max_size = 32M
memory_limit = 512M
zend.enable_gc = On
upload_max_filesize = 32M
opcache.enable=1

setting.ini

wincache.ocenabled = 1
wincache.ocachesize = 255

Inoltre, aggiungi un'impostazione dell'app alla tua app Web con il tasto PHP_INI_SCAN_DIR E d:\home\site\ini

Dopo aver modificato PHP_INI_SYSTEM riavvia la tua app web. Se vuoi saperne di più sulla configurazione di twigging, controlla documentazione Microsoft .

Dopo l'impostazione sopra, il mio sito Drupal (Drupal 8.3) viene caricato entro 3 secondi.

0
npcoder