Ho lavorato per distribuire un'app Rails relativamente grande (Rails 2.3.5) e recentemente facendo alcuni test di carico abbiamo scoperto che il throughput per il sito è molto al di sotto del livello di traffico previsto.L'app Rails ospitata dal passeggero * dolorosamente * lenta, ma il server è una bestia
Eravamo in esecuzione su un server standard a 32 bit, 3 GB di RAM con Centos, e stavamo eseguendo Ruby Enterprise Edition (ultima build), Passenger (Ultima build) e Nginx (Ultima build) - quando c'è solo uno o due gli utenti del sito funzionano bene (come ci si aspetterebbe), tuttavia quando proviamo a incrementare il carico a ~ 50 richieste simultanee, muore completamente. (Rapporto Bench Apache ~ 2.3 req/sec, che è terribile)
Stiamo correndo RPM e cercando di determinare dove il problema del carico è, ma è abbastanza equamente distribuiti in Rails, SQL e Memcached, quindi siamo più o meno passando attraverso e ottimizzando il codice base.
Per pura disperazione abbiamo trasformato un'istanza EC2 di grandi dimensioni (Ubuntu 9.10, RAM da 7,5 GB, 2 unità/core computati) e abbiamo configurato la stessa configurazione del server originale, e mentre ci sono più risorse che continuavamo a vedere patetiche risultati.
Quindi, dopo aver passato troppo tempo a cercare di ottimizzare, giocando con la configurazione della cache ecc. Ho deciso di testare il rendimento di alcuni bastardi, e ta-da, stanno andando molto meglio di Passeggero.
Attualmente la configurazione è 15x Mongrels essere proxy tramite Nginx, e ci sembra di essere soddisfare le nostre esigenze di carico solo ma non è abbastanza per rendere confortevole con l'andare dal vivo ... Quello che mi chiedevo è se qualcuno sa di alcune possibili cause per questo ...?
La mia configurazione per passeggero/nginx è stato:
- Nginx lavoratori: hanno cercato tra 1 e 10, di solito tre però.
- Dimensioni piscina massima per i passeggeri: 10 - 30 (sì, questi numeri sono piuttosto alti)
- Accodamento globale dei passeggeri: provato sia acceso che spento.
- nginx GZip on: sì
potrebbe pagare notare che avevamo aumentato la dimensione massima nginx corpo del cliente a 200 m per consentire il caricamento di file di grandi dimensioni.
suggerimenti In ogni caso sarebbe davvero apprezzato, mentre i meticci stanno lavorando bene cambia come facciamo le cose molto e mi sarebbe davvero preferisce utilizzare passeggeri - oltre, non è vero dovrebbe rendere questo più facile e prestazioni migliori ?
Solo qui ecco la spiegazione: la differenza è che i mongreli generano istanze separate della tua app in modo che ogni app abbia il proprio pool SQL mentre il passeggero preleva nuove istanze da un singolo spawner pre-inizializzato (che è molto più veloce), quindi condivide il tuo pool sql. – hurikhan77
Grazie per la spiegazione - una volta testate le modifiche alle piscine (beh, una volta letto il suggerimento) è diventato molto chiaro per me - come hanno spesso detto le persone sagge, a volte basta un altro paio di occhi;) –
Tu potrebbe voler modificare il tuo titolo in quanto risolto come non correlato a nginx. Accadrà su ogni distribuzione di passeggeri se si imposta la dimensione del pool SQL troppo piccola. – hurikhan77