6
votes

Symfony2 Application très lente dans VirtualBox

i Exécution d'une copie virtuelle de Debian sur VirtualBox pour développer une application PHP de plus grande taille sur une pile NGUX / PHP5-FPM / MYSQL. Le développement se produit dans l'OS hôte (Windows 7 X64), le code est monté en tant que dossier partagé dans le système d'exploitation invité.

performance est très mauvais. Les sorties WebGlind suivantes pour le système de fichiers de Vbox natif et une monture Samba avec CIFS:

profilage de la Vboxfs profilage SMBFS

Dans les deux cas filemtime , file_existes et is_readable prenez plusieurs secondes à exécuter. La charge de la CPU est très élevée, l'utilisation de la mémoire semble normale.

n'est-ce pas la sortie des trois de ces fonctions mis en cache dans le cache Stat? Pourquoi prennent-ils si longtemps?

J'apprécierais vraiment toute aide que je peux obtenir!

EDIT: Pour clarifier, la performance de la production va bien. Sur notre serveur de stadification (approprié, non virtuel), le code PHP exécute dans ~ 60MS Max dans les paramètres de production et quelque part entre 100-200 ms en mode DEV.

J'ai besoin d'aide pour savoir pourquoi VirtualBox est 100X plus lente en mode Dev & Prod.

Je viens de vérifier, les paramètres de production produisent ~ 5sec exécution. Toujours inutilisable, plus il est gênant de développer avec.


0 commentaires

5 Réponses :


5
votes

J'ai récemment répondu à une question similaire. Vous pouvez trouver ma réponse précédente ici .

Je vais faire un petit résumé de celui-ci. Vous ne devez pas mesurer la performance de votre application basée uniquement sur le contrôleur avant app_dev.php code>. Ce contrôleur a été créé pour être utilisé uniquement pour le développement. En développement, vous apportez beaucoup de modifications aux fichiers de configuration, aux modèles de brindle, aux actifs, etc. Symfony vérifiera des centaines de fichiers pour des modifications et rechargera beaucoup de choses déjà mises en cache si nécessaire d'où le nombre élevé d'appels vers filemtime Code>, File_exists code> et is_readable code>. Tous ces appels sont contournés en mode de production car symfony s'attendent à ce que tout dans le cache soit à jour. Donc, presque tout possible est mis en cache en mode de production et utilisé à l'avance sans contrôle de symfony si le fichier a été modifié ou non. Cela donne une énorme performance Boost, car le rechargement d'un seul fichier de développement peut prendre beaucoup de fois pour analyser, vérifier les dépendances à ce sujet, se refaire tout en fonction de ces fichiers, etc. p>

Si vous préparez une benchmarking Votre application, de référence comme si elle était en mode de production. Au moins, si vous ne pouvez pas avoir toute la configuration matérielle que vous l'attendez en production, procédez comme suit. Effacez votre cache pour le mode de production et utilisez app.php code> au lieu de app_dev.php code>. Vérifiez également la section sur performance que vous trouverez sur symfony.com La documentation. Ici, la console appelle à effacer et à réchauffer votre cache dans l'environnement de production. Je pense que cache: Effacer code> réchauffe également le cache, mais comme je ne suis pas sûr à 100%, je préfère faire les deux appels: P>

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


2 commentaires

Merci, Matt! Vous aviez raison de la différence entre le mode Prod et Dev, les trois fonctions PHP que j'ai mentionnées disparaissaient complètement du profileur. Cependant, je me demande toujours pourquoi la VirtualBox prend si longtemps pour exécuter mon code. J'ai précisé que dans ma question ci-dessus. Cheers, Philipp


Je ne peux pas dire avec sûr pourquoi la boîte virtuelle est si lente. Peut-être que ce VM n'est pas particulièrement bon avec l'interaction des systèmes de fichiers. Vous pouvez essayer d'autres ordinateurs virtuels à vérifier comment ils fonctionnent. Peut-être que le @Petemitchell a répondu pourrait aider. À ce stade, je concentrerais mon effort de recherche sur VirtualBox. Bonne chance avec votre problème. Cordialement, Matt



1
votes

En plus de ce que MATT a dit que je vous recommande de compiler une extension de TWIG et utilisez-le comme module PHP. Il générera des modèles plus rapidement. Mais toujours le plus important est de faire des points de repère exécutant votre application dans l'environnement Prod, mais pas dans Dev ou Test. Assurez-vous de ne pas charger le module XDEBUG en production, car il ralentira également vos repères.

Je ne connais pas vos paramètres exacts, mais très probablement, vous aurez de meilleurs résultats si vous installez un proxy inverse approprié (AKA vernis) au lieu de AppCache pour faire autant de demandes de l'application elles-mêmes possible.


2 commentaires

Je vais vérifier l'extension C, merci Anton. Je n'ai aucune plainte concernant la performance des paramètres de production sur une installation similaire, mais physique de Debian. J'ai développé ma question ci-dessus, désolé si c'était ambigu.


Je viens de constater que l'un de mes collègues utilise Virtualbox et il avait des problèmes similaires avant de ne plus avoir de mémoire. Essayez-le si vous le pouvez.



5
votes

Utilisez le partage de fichiers NFS. Samba et le partage de fichiers Vbox peuvent être très lents.

Votre profilage indique que les opérations du système de fichiers sont le goulot d'étranglement.

Lire ce blog post http://clock.co. UK / Tech-Blogs / VirtualBox-404-Dossier partagé-Mise à jour pour plus de persight


1 commentaires

Merci Pete, je vais regarder ça.



4
votes

juste pour attacher cela:

En fin de compte, j'ai configuré une part de samba sur le système d'exploitation invité, loué-la sur un deuxième adaptateur réseau ( hôte uniquement, comme dans ce guide ) et monté que comme un lecteur réseau dans l'hôte OS.

Un petit hacky, mais les temps d'exécution sont jusqu'à 100-500 ms de 5-13sec en mode DEV avec profilage.


1 commentaires

Penser à la même chose, comme j'ai exactement le même problème de performance. Essayé Vboxsf Mont, NFS ... Ses fois plus lent plus lentement que celui de Direct File Lecture / Ecrire. Malheureusement, je fais de nombreuses recherches sur le référentiel à travers mon éclipse, tout en recherchant quelque chose ... et il semble être plus lent.



1
votes

avait le même problème, corrigé-le en configurant un Cron RSYNC qui conserve le code sur la machine virtuelle et l'hôte en synchronisation.

Apparemment, les dossiers partagés VirtualBox sont assez lents lorsqu'il s'agit de la lecture / écriture de fichier: /

blogué sur ma solution en détail si vous êtes intéressé


0 commentaires