Version imprimable
Bonjour,
J'aimerais savoir s'il existe un tuto pour optimiser les performances Symfony :
- optimiser la gestion du cache (pages publiques ou privates, ou en partie publiques, cache statique avec le .htaccess...)
- optimiser le modèle de données (éviter les jointures si possible en dénormalisant, gestion des index et clés...)
- gestion des logs (conservation des logs, taille max, rotation, ...)
- autres...
Merci pour tout conseil !
Salut vinsse,
Je ne pourrais peut-être pas répondre à tout, mais voici une petite liste :
- Utiliser APC pour le ClassLoader : http://symfony.com/doc/current/compo...der.html#usage
- Générer les routes dans le .htaccess pour les sites en production (pour apache) : http://symfony.com/doc/current/cookb...he_router.html
- Tu peux gérer tes logs avec Graylog2, il existe un bundle mais je ne sais pas ce qu'il vaut. Quand j'aurais le temps j’écrirai un petit article à ce sujet...
- Il est possible aussi de cacher des requêtes et résultats Doctrine, il existe plusieurs articles, en voila un: http://inchoo.net/tools-frameworks/c...2-orm-results/
Apres je peux encore t'en sortir mais tu cherches quoi exactement ? :)
Salut Soullivaneuh, merci pour les liens, je vais regarder ça.
Disons que j'ai un besoin assez urgent et d'autres qui sont moins pressés :
1) Le plus urgent est pour moi de trouver une solution de remplacement pour éviter un appel SQL systématique (et toujours identique) sur la page d'accueil (ainsi que sur d'autres pages). Il récupère une liste des catégories (7 lignes dans la table Categorie) et je pensais à remplacer ça par la définition des 7 catégories dans un fichier de paramètre, qui serait toujours dispo en mémoire.
(j'ai codé initialement en m'appuyant sur les entity Symfony mais finalement, ça alourdit fortement la base et les appels de pages, d'où ma question sur les optimisations)
2) J'ai constaté d'autres problèmes, qui seraient à améliorer petit à petit :
- le fichier de log grossit sans avoir de paramétrage de base (alors qu'en java, un bon vieux log4j vous propose des logs tournants, avec taille limité, etc.). Et si on ne surveille pas, le log grossit et ralentit de plus en plus l'appli.
- par défaut les pages ne sont pas mises en cache. D'où un temps d'affichage de 2 à 3s. Alors qu'avec la mise en cache (page déclarée 'publique') on réduit à 40 ms. Mais il y a des effets de bord, car une page 'publique' avec un formulaire pré-rempli juste avec le nom de l'utilisateur va apparaître à tous les utilisateurs...
- en base de données, en plus du souci 1), j'aimerais savoir comment optimiser les index, faut-il un index sur chaque colonne qui sert pour une recherche ? Est-ce qu'il y a des bonnes pratiques ? Ca se fait depuis Symfony ou à la main dans MySQL ?
Vincent
1) J'ai jamais tester mais tu peux mettre en cache les requetes doctrine, ca devrait repondre a ta problematique, par contre il faut faire attention lors de la modification de ces categories.
2)
- Oui le log est un probleme, je ne me suis pas encore penche dessus et ca m'interesse si tu trouves des outils interessant ! :)
- Tu veux dire quoi exactement par mise en cache ? Car si je ne dis pas de betises les templates twig sont caches...
- Je ne suis pas expert en bonne pratique pour les index MySQL, je sais par contre que tu peux preciser les index sur ton entite doctrine: http://docs.doctrine-project.org/en/...l#annref-index
En cherchant un peu, j'ai trouve un article sur la gestion des indexs: http://www.dbnewz.com/2008/06/27/les...ts-efficacite/
Je n'ai pas le temps de le lire pour le moment, donne moi des nouvelles ! ;)
Je serai peut être un peu hors sujet, mais à tout hasard...
Dans le cadre d'un appli riche, j'ai constaté un gain de performances très important en utilisant Assetic pour rassembler mes assets et les compresser.
La mise en oeuvre en est de plus très aisée.
Je surveille en tout cas cette discussion, je pressent qu'elle me sera utile rapidement...
Salut,
Niveau architecture t'es sur quoi ?
nginx, php-fpm et varnish fait bien l'affaire apparemment, la gestion des ESI est aussi importante.