web-dev-qa-db-fra.com

Temps d'initialisation lent de Symfony2

J'ai Symfony2 exécuté sur un serveur Ubuntu 12.04 (64 bits) VM (VirtualBox). L'hôte est un MacBook pro. Pour une raison quelconque, j'obtiens de très longs délais de demande en mode développement (app_dev .php). Je sais que c'est plus lent en mode dev, mais je parle 5-7 secondes par requête (parfois même plus lentement). Sur mon Mac, je reçois des temps de requête de 200 ms environ en mode développement.

Après avoir regardé ma chronologie dans le profileur Symfony2, j'ai remarqué que ~ 95% du temps de demande est du "temps d'initialisation". Qu'est-ce que c'est? Pour quelles raisons cela pourrait-il être si lent?

Ce problème ne s'applique qu'à Symfony2 en mode dev, pas aux autres sites que j'exécute sur la machine virtuelle, et même pas à Symfony2 en mode production.

J'ai vu cela (http://stackoverflow.com/questions/11162429/whats-included-in-the-initialization-time-in-the-symfony2-web-profiler), mais cela ne semble pas répondre à mes questions.

performanceubuntusymfonyvirtualbox
53
orourkedd

J'ai trouvé la cause du problème (et ce n'est pas Symfony2). Pour une raison quelconque sur la machine virtuelle ubuntu, les heures de modification sur certains fichiers sont incorrectes (c'est-à-dire à l'avenir, etc.). Lorsque symfony2 vérifie ces heures en utilisant filemtime () par rapport à son registre, il détermine que le cache n'est plus frais et reconstruit le tout. Je n'ai pas encore pu comprendre pourquoi il le fait.

15
orourkedd

J'ai eu 5-30 secondes de réponses de Symfony2 par défaut. Maintenant, c'est ~ 500 ms dans un environnement de développement.

J'ai ensuite modifié les éléments suivants dans php.ini:

  • set realpath_cache_size = 4M (ou plus)
  • désactivé XDebug complètement (test avec phpinfo)
  • realpath_cache_ttl = 7200
  • activé et définissez OPcache (ou APC) correctement
  • redémarré Apache pour recharger php.ini

Et voilá, les réponses sont passées en moins de 2 secondes en mode dev! J'espère que ça aide.

Avant: 6779 ms enter image description here

Après: 1587 ms

enter image description here

Symfony2 lit les classes à partir de milliers de fichiers et c'est un processus lent. Lorsque vous utilisez un petit PHP cache realpath, les chemins de fichiers doivent être résolus un par un chaque fois qu'une nouvelle requête est faite dans l'environnement de développement s'ils ne sont pas dans le cache realpath de PHP. Le cache realpath est trop petit par défaut pour Symfony2. En prod ce n'est bien sûr pas un problème.

Métadonnées du cache:

La mise en cache des métadonnées (par exemple, les mappages) est également très importante pour améliorer davantage les performances:

doctrine:
    orm:
        entity_managers:
            default:
                metadata_cache_driver: apc
                query_cache_driver: apc
                result_cache_driver: apc

Vous devez activer APCu pour cela. C'est APC sans cache de bytecode, comme OPCache fait déjà la mise en cache d'opcode. OPCache est intégré depuis PHP 5.5.

---- Après: 467 ms ----

(dans un environnement de production, la même réponse est d'environ 80 ms)

enter image description here

Veuillez noter que ce projet utilise plus de 30 bundles et possède des dizaines de milliers de lignes de code, près de cent propres services, donc 0,5s est assez bon dans un environnement Windows local en utilisant seulement quelques optimisations simples.

123
Denes Papp

Nous avons le meme probleme. Ici, nous avons 10 secondes et plus pour chaque demande. Je vois si je supprime les lignes suivantes dans bootstrap.php.cache toutes les fois retournent à l'état normal (298 ms).

foreach ($meta as $resource) { 
if (!$resource->isFresh($time)) {
return false;
}
}

Il est possible que nous ayons de mauvais temps de modification, mais nous ne savons pas comment y remédier. Quelqu'un connaît une solution?

4
cleaversdev

J'ai également dû désactiver xdebug (v2.2.21) pour déboguer le chargement du délai d'attente maximal d'Apache2 sur mon macbook. Il a été installé en utilisant macports:

Sudo port install php54-xdebug.

Avec xdebug activé, chaque page manque de temps de chargement maximum, avec une erreur fatale dépassant le message de dépassement de délai maximum envoyée. Lorsqu'il est désactivé, tout se charge correctement dans un délai raisonnable. J'y suis arrivé en utilisant MAMP, aucun xdebug activé par défaut, et Apache2 fonctionne juste rapidement comme d'habitude. Je peux changer pour un autre débogueur, c'est dommage, car xdebug fonctionnait bien avant.

Config:

  • MacOSX 10.6.8
  • macports 2.1.3
  • Apache 2.2.24
  • php 5.4
4
Joseph Tran

Comme indiqué sur https://stackoverflow.com/a/12967229/610884 la raison d'un tel comportement peut être Ubuntu VM. Vous devez synchroniser la date et l'heure entre l'hôte et l'OS invité, comme expliqué sur https://superuser.com/questions/463106/virtualbox-how-to-sync-Host-and-guest-time .

La date de modification du fichier change à la valeur de l'hôte lorsque vous téléchargez le fichier vers VM via FTP. C'est pourquoi filemtime () renvoie une valeur incorrecte.

2
kna

Vous pouvez déplacer APP/var/cache à /dev/shm/YourAppName/var/cache. Mais il est bon d'avoir également construit un conteneur dans des fichiers locaux pour IDE saisie semi-automatique et validation de code. Dans app/AppKernel.php:

public function getCacheDir()
{
    return $this->getVarOrShmDir('cache/' . $this->getEnvironment());
}

public function getLogDir()
{
    return $this->getVarOrShmDir('logs');
}

private function getVarOrShmDir($dir)
{
    $result = dirname(__DIR__) . '/var/' . $dir;

    if (
        in_array($this->environment, ['dev', 'test'], true) &&
        empty($_GET['warmup']) && // to force using real directory add ?warmup=1 to URL
        is_dir($result) && // first time create real directory, later use shm
        file_exists('/bin/mount') && Shell_exec('mount | grep vboxsf') // only for VirtualBox
    ) {
        $result = '/dev/shm/' . 'YourAppName' . '/' . $dir . '/' . $this->getEnvironment();
    }

    return $result;
}
2
luchaninov

J'ai désactivé xdebug et cela a entraîné une diminution du temps de chargement de 17 s (oui ..) à 0,5 s.

1
Dhofca

J'ai également eu des problèmes avec le lent chargement des pages en développement, ce qui peut être extrêmement frustrant lorsque vous modifiez CSS ou quelque chose de similaire.

Après un peu de fouille, j'ai trouvé que pour moi, le problème était dû à Assetic qui recompilait tous les actifs à chaque chargement de page:

http://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files-in-the-dev-environment

En désactivant l'utilisation du contrôleur Assetic, j'ai pu augmenter considérablement la charge de ma page. Cependant, comme le lien ci-dessus l'indique, cela a un coût de régénération de vos actifs chaque fois que vous les modifiez (ou que vous les surveillez).

1
Luke