Symfony2 et de Rameaux de rendu des problèmes de performances

Comme dans cette rubrique, j'ai un problème de performances en dev mode lors de l'ajout d'une brindille "rendu" de la balise dans mon application (la documentation connexe: Intégrez des contrôleurs).

Sans ce rendre tag, mes pages sont générées en moins de 70 ms.
Avec le rendu de la balise, c'est au moins 170 ms.
Et chaque rendu ajouté le tag dans l'application augmente la génération de la page par 100 ms (ce qui est BEAUCOUP : pourquoi une page normale exécuter en 60 ms et un rendu de la balise en 100 ms?).
J'ai peut-être besoin de 4 ou 5 d'entre eux sur chaque page de mon application, de sorte que signifierait au moins 500 ms pour chaque page en dev mode.

Je comprends tout à fait qu'il n'y a pas de problème en mode prod, mais c'est clairement pas à l'aise dans le développement.
Donc, est-ce que qqn connais aucun moyen de se débarrasser de l'inutile appels, des journaux ou code lors de l'utilisation de "rendre" tag en dev mode?

OriginalL'auteur Nanocom | 2012-03-25

  1. 8

    J'ai expliqué juste 10 heures. Longue histoire courte: migrer vers Twig extensions.

    Eh bien dans ce cas la création d'un service de contrôleur de logique est mieux à mon humble avis. Si la logique du contrôleur a db opération alors je pense qu'il est préférable de ne pas déplacer la logique de twig fonction. La création d'un service distinct assure également res d'utilisation, si le contrôleur embarqué a la route fixé et peut être appelée de façon indépendante.
    Rien ne vous empêche d'appeler les services d'une extension Twig. En fait, c'est ce que je fais. Ce n'est pas un ce-VS-problème. Mon Twig extensions viens d'appeler les actions des contrôleurs définis comme des services. Ces actions sont réutilisables sans extensions Twig.
    Eh bien, le service peut également être exposé à rameau par l'ajout de twig variable globale dans app/config.yml. Juste façon différente de faire les choses. Rien à dire sur le fait :).
    Donc, nous devrions tout simplement d'éviter l'incorporation de contrôleurs dans Symfony2? Il est assez décevant, pour autant que ce mécanisme a été très utile et facile à utiliser...
    Comment voulez-vous remplacer le Rendu avec twig extensions ?

    OriginalL'auteur Elnur Abdurrakhimov

  2. 9

    Une de mes fonctionnalités préférées dans symfony est le rendu de la balise, l'intégration du contrôleur d'appels. Le profileur ajoute beaucoup de frais généraux pour chaque contrôleur des appels, non seulement la vitesse, mais utilise beaucoup de mémoire. Vous avez un peu d'options pour l'accélérer.

    Le profiler écrit toutes les données dans une base de données sqlite par défaut. IIRC sqlite ne permet pas de parallèle inserts, de sorte que chaque demande d'avoir à attendre leur tour pour accéder à la db pour vider les collecteurs de données. Vous pouvez utiliser votre développement db (mysql ou ce que vous utilisez) pour conserver profileur de données. Il y a un an j'ai beaucoup appris avec ce en termes de vitesse.

    Vous pouvez également désactiver le générateur de profil pour les sous-requêtes, ou uniquement utiliser le profiler lorsqu'une exception se produit. Voir le cadre de config de référence pour les détails complets.

    # config_dev.yaml
framework:
    profiler:
        only_exceptions:      false
        only_master_requests: false
        dsn:                  sqlite:%kernel.cache_dir%/profiler.db
    J'ai eu le prbl à l'aide de render_esi(); dans ce cas @m2mdas solution n'est pas réalisable.
    C'est intéressant astuce pour vous 🙂
    Quelle est la chaîne de caractères que vous utiliseriez pour utiliser la base de données MySQL à la place dans le fichier yml?

    OriginalL'auteur Bártfai Tamás

  3. 6

    Vous pouvez déplacer votre contrôleur logique à un service de référence et comme twig variable globale et inclure le modèle rendu par le contrôleur.

    Voir https://stackoverflow.com/a/13245994/982075 pour les instructions.

    OriginalL'auteur Mun Mun Das

  4. 3

    Le choix dépend de votre application. Je crois que les façons les plus pratiques sont les suivantes:

    1) Utiliser le render tag lourds rendu modèles et les utiliser hinclude bibliothèque pour les charger de manière asynchrone. Ceci est très utile lorsque chaque modèle de rendu est "lent" par lui-même (par exemple, de nombreux db connexions, les grands textes, etc.).

    2) Faire comme proposé par m2mdas. C'est très une solution rapide pour la plupart des cas.

    OriginalL'auteur JeanValjean

  5. 0

    Je voudrais aussi suivre E. proposition du rameau extensions. Une alternative serait d'utiliser Sonate Bloc Bundle: http://sonata-project.org/bundles/block/master/doc/index.html . La surcharge d'une sous-requête avec la Sonate de Bloc est sur le 7ms afair.

    OriginalL'auteur hacfi