Comparaison des performances PHP5, Windows et Linux
j'ai une question sur la performance de Symfony2.
je développe avec Symfony2 sous Ubuntu 11.04 depuis quelques semaines maintenant, Apache 2.2.17, PHP 5.3.5, APC 3.1.9, no xDebug""
sur l'environnement dev, le temps donné sur la barre D'outils Symfony2 n'a jamais dépassé 70 ms.
Aujourd'hui, j'ai essayé d'installer mon application sur un environnement Windows 7 : Wampserver 2.2, PHP 5.3.8, Apache 2.2.21, APC 3.1.7, no xDebug
l'ordinateur dans L'environnement windows est beaucoup mieux que celui sur ubuntu (SSD, processeur Quad core, etc).
et quand j'exécute l'application sur l'environnement dev, la barre d'outils indique toujours un minimum de 300 ms.
Alors, savez-vous comment c'est possible ?
Merci !
Modifier: a trouvé un lien sur le sujet: http://fossplanet.com/f6/%5Bsymfony-users%5D-symfony2-slow-windows-xp-116465 /
j'ai remarqué le problème avec la fonction file_exists aussi (en utilisant webgrind).
Alors, des idées ?
peut-être que le sujet a déjà été discuté, mais j'ai été surpris de ne rien trouver en rapport.
4 réponses
TL;DR; Ensemble realpath_cache_size une valeur > 1000
Edit 2: Problème résolu dans ce PR: essayez de définir PHP.realpath_cache_size de ini à une valeur > 1000 Une exigence symfony a récemment été ajoutée pour régler cette question: https://github.com/sensiolabs/SensioDistributionBundle/commit/cf0179711b24d84d4a29d71a4010540f4c990bd8
Edit: j'ai juste vu cette réponse: https://stackoverflow.com/a/17914570/980547 Et il a réduit le temps de génération de page de 4 sur windows quand j'ai défini realpath_cache_size=4096k dans mon php.ini (!)
ancienne réponse:
donc, j'ai fait une comparaison entre les deux avec webgrind:
sous windows (fast computer), appelé app_dev.php:
So vous pouvez voir que la barre d'outils Web montre une génération de temps 764ms (augmentée à cause de Xdebug et profiling, mais toujours pertinente). Webgrind montre:
- 651 appels à file_exists() pour un temps de 232ms (ce qui est beaucoup!)
- 603 appels à filemtime () (211ms)
- 230 appels à UniversalClassLoader - > loadClass () (119ms)
- 230 appels vers UniversalClassLoader- > findFile () (38ms)
Sur linux (ordinateur lent), app_dev.php:
298ms de la durée totale de génération (qui est plus de deux fois moins que sur windows).
- 237 appels vers UniversalClassLoader->findFile () (36ms => 4 fois moins)
- 237 appels vers UniversalClassLoader - > loadClass () (20ms => 2 fois moins)
- 623 appels vers file_exists () (4ms seulement !!!)
- 605 callsd à filemtime () (4MS seulement !!!)
le problème semble être file_exists() et filemtime(), qui sont beaucoup plus lents sous windows que sous Linux. Sur windows, PHP est à la recherche de fichiers avec file_exists, filemtime, loadClass ou findFile pour 60% du temps. C'est qu'un problème connu ?
Edit : ainsi le problème est seulement pour l'environnement dev, en production aucun file_exists ne sont faits puisque tout est mis en cache.
je viens juste de commencer à développer avec Symfony2 sous Windows et c'était une douleur totale dans le cul - j'ai testé xcache, apc et eaccelerator qui soit fait presque aucune différence ou juste s'est écrasé lorsqu'il est utilisé avec xdebug.
maintenant j'ai découvert WinCache par Microsoft - qui a fait Symfony2 sous Windows incroyable rapide...
Mes demandes ont pris quelque chose entre 1,5 s à 3s - Avec WinCache son down à 200ms . Et ça ne dérange même pas xdebug - le profilage et le débogage fonctionne toujours comme un charme.
Edit:tout est dans l'environnement dev.
le seul inconvénient est qu'il ne fonctionne que sur PHP nts et je pense que les modules apache nécessite ts - si vous l'exécutez avec fcgid bien que vous n'aurez aucun problème.
Je ne peux pas croire que j'ai travaillé autant d'années sans ce monstre...
liens:
WinCache sur php.net
site officiel de WinCache
binaires
intéressant trouvé!
je dirais que ce n'est pas une symfony2 problème, il doit être fixé dans PHP..
mais qui utilise son serveur web sous windows? : D
faites un essai avec ApcUniversalClassLoader http://symfony.com/doc/2.0/book/performance.html