Come ridimensionare php5 + MySQL oltre 200 richieste / secondo?

Sto modificando la mia homepage per le prestazioni, attualmente gestisce circa 200 richieste / secondo su 3.14.by che mangia 6 query SQL e 20 req / secondo su 3.14.by/forum che è il forum phpBB.

Stranamente, i numeri sono più o meno gli stessi su alcuni server VPS e Atom 330 dedicati.

Il software server è il seguente: Apache2 + mod_php prefork 4 child (qui provato diversi numeri), php5, APC, nginx, memcached per l'archiviazione delle sessioni PHP.

MySQL è configurato per consumare circa il 30% della RAM disponibile (~ 150 Mb su VPS, 700 Mb su server dedicato)

Sembra che ci sia un collo di bottiglia da qualche parte che non mi permette di andare più in alto, qualche suggerimento? (vale a dire che so che fare meno di 6 SQL lo renderebbe più veloce, ma questo non sembra un fattore limitante, poiché sqld mangia non più di qualche% in cima a causa delle query memorizzate nella cache)

Qualcuno ha testato che calciare precaricato apache2 e lasciare solo nginx + php è molto più veloce?

Alcuni altri parametri di riferimento

Small 40-byte static file: 1484 r/s via nginx+apache2, 2452 if we talk to apache2 directly. 
Small "Hello world" php script: 458 r/s via ngin+apache2.

Aggiornamento: sembra che il collo di bottiglia sia rappresentato dalle prestazioni di MySQL sui dati memorizzati nella cache. La pagina con SQL singolo mostra 354req / sec, con 6 SQL - 180 req / sec. Cosa pensi che posso modificare qui? (Posso sborsare 100-200 Mb per MySQL)

[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
default-character-set=cp1251
collation-server=cp1251_general_cs

skip-character-set-client-handshake

user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
skip-external-locking

bind-address        = 127.0.0.1

key_buffer      = 16M
max_allowed_packet  = 8M
thread_stack        = 64K
thread_cache_size   = 16
sort_buffer_size    = 8M
read_buffer_size    = 1M

myisam-recover      = BACKUP
max_connections        = 650
table_cache            = 256
thread_concurrency     = 10

query_cache_limit       = 1M
query_cache_size        = 16M

expire_logs_days    = 10
max_binlog_size         = 100M

[mysqldump]
quick
quote-names
max_allowed_packet  = 8M

[mysql]
[isamchk]
key_buffer      = 8M

!includedir /etc/mysql/conf.d/

Ovviamente, ci sono molte cose che puoi provare. La tua scommessa migliore è inseguire i tuoi log per query che non usano indici (abilita i log per quelli) e altre query non ottimizzate. Nel corso degli anni ho compilato un vasto elenco di opzioni relative alle prestazioni, quindi ho incluso un piccolo sottoinsieme qui per vostra informazione - si spera che aiuti. Ecco alcune note generali per le cose che puoi provare (se non l'hai già fatto):

MySQL

• query_cache_type = 1 - le query SQL della cache sono attive. Se impostato su 2, le query vengono memorizzate nella cache solo se viene passato il suggerimento SQL_CACHE. Analogamente al tipo 1, è possibile disabilitare la cache per una determinata query con il suggerimento SQL_NO_CACHE
• key_buffer_size = 128M (predefinito: 8M) - buffer di memoria per gli indici delle tabelle MyISAM. Su server dedicati, punta a impostare key_buffer_size su almeno un quarto, ma non più della metà, della quantità totale di memoria sul server
• query_cache_size = 64M (impostazione predefinita: 0) - dimensione della cache della query
• back_log = 100 (impostazione predefinita: 50, max: 65535) - La coda delle richieste di connessione in sospeso. Importa solo quando ci sono molte connessioni in breve tempo
• join_buffer_size = 1M (impostazione predefinita: 131072) - un buffer utilizzato quando si hanno scansioni di tabelle complete (senza indici)
• table_cache = 2048 (impostazione predefinita: 256): devono essere max_user_connections moltiplicati per il numero massimo di JOIN contenuti nella query SQL più pesante. Utilizzare la variabile "open_tables" nelle ore di punta come guida. Guarda anche la variabile "open_tables" - dovrebbe essere vicino a "open_tables"
• query_prealloc_size = 32K (impostazione predefinita: 8K) - memoria persistente per l'analisi e l'esecuzione delle istruzioni. Aumenta se hai domande complesse
• sort_buffer_size = 16M (impostazione predefinita: 2M) - aiuta con l'ordinamento (operazioni ORDER BY e GROUP BY)
• read_buffer_size = 2M (predefinito: 128K) - Aiuta con scansioni sequenziali. Aumentare se ci sono molte scansioni sequenziali.
• read_rnd_buffer_size = 4M - aiuta la tabella MyISAM ad accelerare la lettura dopo l'ordinamento
• max_length_for_sort_data: dimensione della riga da archiviare anziché puntatore di riga nel file di ordinamento. Può evitare letture casuali della tabella
• key_cache_age_threshold = 3000 (impostazione predefinita: 300) - tempo per mantenere la cache delle chiavi nella hot zone (prima che venga retrocessa in warm)
• key_cache_division_limit = 50 (impostazione predefinita: 100) - abilita un meccanismo di sgombero della cache più sofisticato (due livelli). Indica la percentuale da mantenere per il livello inferiore. delay_key_write = ALL: il buffer delle chiavi non viene scaricato per la tabella ad ogni aggiornamento dell'indice, ma solo quando la tabella viene chiusa. Questo accelera molto le scritture sui tasti, ma se si utilizza questa funzione, è necessario aggiungere il controllo automatico di tutte le tabelle MyISAM avviando il server con l'opzione --myisam-recover = BACKUP, FORCE
• memlock = 1 - processo di blocco in memoria (per ridurre lo scambio in / out)

Apache

• cambia il metodo di spawn (ad esempio in mpm)
• disabilitare i registri, se possibile
• AllowOverride None - quando possibile disabilita .htaccess. Arresta apache per la ricerca di file .htaccess se non vengono utilizzati, quindi salva una richiesta di ricerca di file
• SendBufferSize: impostato sul sistema operativo predefinito. Su reti congestionate, è necessario impostare questo parametro vicino alla dimensione del file più grande normalmente scaricato
• KeepAlive Off (impostazione predefinita attivata) - e installa lingerd per chiudere correttamente le connessioni di rete ed è più veloce
• DirectoryIndex index.php: mantiene l'elenco dei file il più breve e assoluto possibile.
• Opzioni FollowSymLinks - per semplificare il processo di accesso ai file in Apache
• Evita di usare mod_rewrite o almeno regex complessi
• ServerToken = prod

PHP

• variabili_ordine = "GPCS" (Se non hai bisogno di variabili d'ambiente)
• register_globals = Off - oltre ad essere un rischio per la sicurezza, ha anche un impatto sulle prestazioni
• Mantieni include_path il più minimamente possibile (evita ricerche extra sul filesystem)
• display_errors = Off - Disabilita la visualizzazione degli errori. Consigliato vivamente per tutti i server di produzione (non visualizza brutti messaggi di errore in caso di problemi).
• magic_quotes_gpc = Off
• magic_quotes _ * = Off
• output_buffering = On
• Disabilitare la registrazione, se possibile
• expose_php = Off
• register_argc_argv = Off
• always_populate_raw_post_data = Off
• posiziona il file php.ini dove php lo cercherebbe per primo.
• session.gc_divisor = 1000 o 10000
• session.save_path = "N; / path" - Per i siti di grandi dimensioni prendere in considerazione l'utilizzo. Suddivide i file di sessione in sottodirectory

Modifiche al sistema operativo

• Montare i dischi rigidi usati con l'opzione -o noatime (nessun tempo di accesso). Aggiungi anche questa opzione al file / etc / fstab.
• Modifica / proc / sys / vm / swappiness (da 0 a 100) per vedere quali sono i risultati migliori
• Usa dischi RAM - mount --bind -ttmpfs / tmp / tmp

Se il collo di bottiglia non è CPU, allora il suo IO - rete o disco. Quindi .. devi vedere quanto IO sta succedendo. Non avrei pensato che fosse la rete (a meno che tu non abbia un collegamento half duplex a 10 Mbps, ma vale la pena controllare lo switch nel caso in cui il rilevamento automatico non funzioni correttamente).

Ciò lascia l'IO del disco, che può essere un fattore importante soprattutto per i VPS. Usa sar o iostat per dare un'occhiata ai dischi, quindi google su come trovare maggiori dettagli se il tuo disco viene utilizzato pesantemente.

Vorrei esaminare la cache con Nginx ( memcached ) o Varnish .

Per lo meno dovresti server di file statici con Nginx come ha detto SaveTheRbtz.

Poiché il server non sembra essere un problema, forse lo è il generatore di carico. Prova a eseguirlo su più macchine.

Mi sembra che tu stia colpendo la massima quantità di connessioni consentite da Apache. Dai un'occhiata alla tua configurazione di Apache. L'aumento del limite del server e dei client massimi dovrebbe aiutare se non si è già vincolati da altri limiti come I / O o memoria. Guarda i valori presenti per mpm_prefork_module o mpm_worker_module e modifica di conseguenza per soddisfare le tue esigenze.

ServerLimit 512
MaxClients 512

Questo carico è generato da uno strumento o carichi del mondo reale?

Potresti voler controllare memcached. Ho riscontrato problemi ad alte velocità di connessione che causavano latenza nell'applicazione.

Se si utilizza un generatore di carico, cosa si ottiene quando si colpisce una piccola pagina statica?

Durante i carichi, potresti voler controllare lo stack di rete per le condizioni TIME_WAIT. Forse stai riempiendo la coda di connessione.

Ci sono circa un centinaio di ragioni e oggetti che puoi guardare ma senza ulteriori informazioni, sto solo gettando ipotesi a questo punto.

Il 99% delle volte problemi come questo risalgono al database. Assicurati prima di tutto gli indici di colpire. Se non funziona, inizia a memorizzare nella cache tutto ciò che puoi.

Ti consiglio di usare (se possibile) un pool di connessioni per mantenere il database connesso alle tue applicazioni web (non è necessario riconnettersi ad ogni richiesta). Ciò può fare un'enorme differenza di velocità.

Inoltre, prova ad analizzare tutte le tue query con EXPLAIN (e perché non creare un profilo delle tue query con SHOW PROFILE?).