Archives de catégorie : Symfony2

PHP tour 2014 : ce que j’en retiens

Les 23 et 24 juin 2014 s’est tenu le PHP Tour 2014 organisé par l’AFUP. Cette année, c’est Lyon qui était la ville hôte de l’événement (après Lille et Nantes).

Comme d’habitude, ce genre de rassemblement est l’occasion de profiter des spécialités gastronomiques (aaaaah, cette andouillette… on a été conseillé sur une super adresse de bouchon, si ça intéresse des gens), mais pas seulement ! C’est aussi le moment de prendre le pouls de la communauté PHP-phile, de prendre des idées là où il y en a, et de prendre des nouvelles de vieilles connaissances.

Je n’ai évidemment pas eu l’occasion de participer à l’ensemble des conférences de ces deux jours (ne serait-ce que parce qu’il y en avait 3 en même temps, et que mon option ubiquité n’est toujours pas opérationnelle), mais je retiendrai particulièrement les interventions suivantes.

Continuer la lecture de PHP tour 2014 : ce que j’en retiens

LiipDoctrineCache : Utiliser une ferme multi-serveur Memcache

Quand comme moi vous travaillez dans une société qui a besoin de haute-disponibilité (ce qui correspond à la grosse majorité des entreprises dans le web, non ?), vous ne pouvez pas dire :

Mon cache, je le stocke sur un serveur unique qui peut claquer à tout moment.

Du coup, si vous utilisez Memcache, il vous faut au moins 2 serveurs pour répartir vos clés de cache (avec ou sans redondance).

Vous pourriez très bien me rétorquer :

Hey mec, c’est que du cache ! S’il est down, le site continuera de fonctionner.

Sauf que l’on sait tous ce que peut donner un site sans cache, surtout si ce dernier faillit en pleine période de pointe (ce qui est plus que probable connaissant ce sadique de Murphy).

Et si comme moi vous avez adopté le bundle LiipDoctrineCacheBundle, qui permet d’utiliser les classes de cache de Doctrine (utilisées par l’ORM à l’origine, mais qui fonctionne très bien aussi en autonome).

Mais voilà : dans la configuration offerte par le bundle, seul un couple host/port n’est possible.

Heureusement, il est possible d’utiliser le paramètre « id » qui permet de faire référence à un service du conteneur d’injection. Du coup, vous pouvez placer dans le conteneur un service Memcache configuré avec votre ferme de serveurs, et le passer à la configuration « liip_doctrine_cache »

Exemple :

services:
    my_memcache_farm:
        class: Memcache
        calls:
            - [ addServer, [ "serveur1", 11211 ] ]
            - [ addServer, [ "serveur2", 11211 ] ]

liip_docrine_cache:
    namespaces:
        my_namepace:
            type: memcache
            id: my_memcache_farm

Et le tour est joué : votre configuration multi-serveur memcache peut ainsi être utilisée avec Doctrine cache.

Vous pouvez aussi en profiter pour positionner les timeouts de connexion et de réponse des serveurs.

Point fort supplémentaire : si vous utilisez la même ferme de cache pour plusieurs namespaces, vous n’avez pas à dupliquer autant de fois la configuration.

Maintenant, si vous avez du temps pour tester, l’utilisation de Couchbase permet d’amener en plus la redondance et une meilleure répartition des données sur les noeuds, la suppression de noeud à chaud, etc… J’ai hâte de tester et de vous dire tout ce que j’en pense de bien (ou pas)

Améliorer le warmup du cache de Symfony2

Lorsque vous vous lancez sur un développement sous Symfony2 en venant d’un monde sans framework (oui, je sais, cela peut surprendre mais il existe encore quelques peuplades reculées qui résistent encore et toujours à l’envahisseur), un des challenges à surmonter est la gestion du cache du framework lors du déploiement d’une application. Si en plus cette application est utilisée par des milliers d’internautes en Europe, le moindre à-coup dans les performances peut être difficile à vivre par votre plate-forme.

Cache warmup

Une chose à ne pas oublier quand vous déployez une nouvelle version de votre application est de « préchauffer » (warm-up) le cache du framework.

Eh oui, un peu comme les moteurs diesel des années 80 !

Par contre, si le framework monte déjà beaucoup de choses, il manque une petite chose qui peut vous permettre de ne pas avoir des temps de réponses moisis au moment de la bascule : la chauffe du fichier classes.php

A quoi sert ce classes.php  ?

Afin d’éviter de passer son temps à faire appel à l’autoload pour toutes les classes qui servent souvent, le framework génère un fichier contenant un certain nombre de classes, le charge en une fois au boot du kernel.

Cependant, ce fichier met un certain temps à être généré par les premières requêtes qui arrivent sur votre pauvre application sans défense tout juste sortie de son nid. Et comme les internautes voraces veulent tous en même temps des réponses à leurs requêtes, les premiers arrivés se retrouvent tous à calculer cet unique fichier.

Heureusement il y a les CacheWarmer (warmeeeeeeeer !)

Symfony2, dans son infinie sagesse, offre la possibilité au développeur avisé d’ajouter des bouts  de code permettant de chauffer le cache pour ses besoins spécifiques.

Comment ? En ajoutant à vos bundles une classe implémentant l’interface CacheWarmerInterface, en la déclarant comme service dans l’injection de dépendance et en le tagguant (gentiment  !) comme kernel.cache_warmer.

Et comme je suis gentil, le warmer de classes.php, je vous l’offre ! Le code de ce bundle est sur Github bien sûr et il est disponible sur packagist évidemment.

1. Ajouter le à votre composer.json

{
    "require" : {
        "zibok/class-cache-warmer": "dev-master"
    }
}

2. Ajouter le bundle dans votre AppKernel

new Zibok\Bundle\ClassCacheWarmerBundle\ZibokClassCacheWarmerBundle();

Et le tour est joué : vider votre cache et vérifier que dans le nouveau répertoire vous avez bien le classes.php.

Conclusion

Au delà de l’aspect (un peu) pratique de ce bundle, il est également un exemple très simple de cache warmer que je vous invite à lire si vous êtes novice pour vous rendre compte à quel point il est facile de venir se greffer à la gestion/génération du cache de Symfony2.