Applicazione Symfony2 molto lenta in VirtualBox

Question

Eseguo una copia virtuale di Debian su VirtualBox per sviluppare un'applicazione PHP di dimensioni maggiori su uno stack nginx/php5-fpm/MySQL. Lo sviluppo avviene nel sistema operativo host (Windows 7 x64), il codice viene montato come una cartella condivisa nel sistema operativo guest.

Le prestazioni sono pessime. Di seguito sono uscite webgrind per i file system vbox nativa e montare una samba con cifs:

In entrambi i casi filemtime, file_exists e is_readable richiedere alcuni secondi per l'esecuzione. Il carico della CPU è molto alto, l'utilizzo della memoria sembra normale.

L'output di tutte e tre queste funzioni non è memorizzato nella cache delle statistiche? Perché ci mettono così tanto tempo?

Apprezzo davvero qualsiasi aiuto che posso ottenere!

Modifica: Per chiarire, le prestazioni di produzione vanno bene. Sul nostro server di gestione (appropriato, non virtuale) il codice PHP viene eseguito in ~ 60ms max nelle impostazioni di produzione e da qualche parte tra 100-200ms in modalità dev.

Ho bisogno di aiuto per capire perché VirtualBox è 100x più lento nella modalità prod & dev.

Ho appena controllato, le impostazioni di produzione producono un'esecuzione di ~ 5 secondi. Ancora inutilizzabile, inoltre è complicato svilupparsi con.

Answer 1

Utilizzare la condivisione di file nfs. Samba e la condivisione del file vbox possono essere molto lenti.

Il profilo indica che le operazioni del file system sono il collo di bottiglia.

Leggi questo post del blog http://clock.co.uk/tech-blogs/virtualbox-404-shared-folder-update per un quadro più chiaro

Answer 2

Recentemente ho risposto a una domanda simile. Puoi trovare la mia risposta precedente here.

Farò un piccolo riassunto. Non è necessario misurare le prestazioni dell'applicazione in base esclusivamente al controller anteriore app_dev.php. Questo controller è stato creato per essere utilizzato solo per lo sviluppo. In fase di sviluppo, si apportano molte modifiche ai file di configurazione, ai modelli di ramoscello, alle risorse, ecc. Symfony controllerà centinaia di file per le modifiche e ricaricherà molte cose memorizzate nella cache, se necessario, quindi l'elevato numero di chiamate a filemtime, file_exists e is_readable. Tutte queste chiamate sono bypassate in modalità produzione perché Symfony si aspetta che tutto nella cache sia aggiornato. Quindi, quasi tutto il possibile è memorizzato nella cache in modalità di produzione e utilizzato in precedenza senza che Symfony verifichi se il file è stato modificato o meno. Questo dà un enorme incremento di prestazioni perché ricaricare un singolo file in fase di sviluppo può richiedere un sacco di tempo per analizzarlo, controllare le dipendenze su di esso, ricollocare tutto a seconda di questi file e così via.

Se si esegue il benchmarking della propria applicazione, confrontarlo come se fosse in modalità di produzione. Almeno, se non è possibile avere tutta l'installazione dell'hardware come previsto in produzione, attenersi alla seguente procedura. Svuota la cache per la modalità di produzione e utilizza app.php anziché app_dev.php. Inoltre, controlla la sezione su performance che può essere trovata su symfony.com nella documentazione. Qui la console chiama per cancellare e riscaldare la cache nell'ambiente di produzione. Credo che cache:clear sarà anche la cache di riscaldamento, ma dal momento che non sono sicuro al 100%, io preferisco fare entrambe le chiamate:

php app/console cache:clear --env=prod --no-debug 
php app/console cache:warmup --env=prod --no-debug 

Spero che questo aiuti.

saluti, Matt

Answer 3

In aggiunta a quanto detto Matt vi consiglio di compilare estensione ramoscello e usarlo come modulo PHP. Genera i modelli più velocemente. Ma la cosa più importante è fare qualsiasi benchmark che esegua la tua app in ambiente prod, ma non in dev o test. Assicurati di non caricare il modulo xdebug in produzione, perché rallenterà anche i tuoi benchmark.

Non conosco le tue impostazioni esatte, ma molto probabilmente avrai risultati migliori se installi il reverse proxy corretto (aka Varnish) invece di AppCache per fare il minor numero possibile di richieste all'app stessa.

Answer 4

Proprio per legare questo in su:

Alla fine ho creato una condivisione Samba sul sistema operativo guest, legato a una seconda scheda di rete (host-only, like in this guide) e montato come unità di rete nel sistema operativo host.

Un po 'hacky, ma i tempi di esecuzione sono ridotti a 100-500 ms da 5-13 secondi in modalità sviluppo con profilo.

Answer 5

Aveva lo stesso problema, risolto impostando un cron di rsync che mantiene il codice sulla VM e l'host in sincronizzazione.

Apparentemente Virtualbox cartelle condivise sono piuttosto lento quando si tratta di file di lettura/scrittura:/

Blogged about my solution in detail if you are interested