Archives de catégorie : PHP

Event Driven Architecture : Apache Kafka sur le rivage

Après vous avoir tous convaincus, j’en suis sûr, dans le précédent épisode de cette série, de l’intérêt d’une gestion événementielle de vos processus, je m’en vais vous parler plus en détails du bus que nous utilisons chez mon employeur actuel préféré.

Apache Kafka est un produit à l’origine développé par LinkedIn. Ecrit en Scala, cette plate-forme est capable d’ingurgiter un nombre impressionnant de messages par seconde (potentiellement par millions selon ce benchmark de LinkedIn).

Son architecture est sur le principe assez simple finalement (même si son implémentation n’est évidemment pas aussi triviale).

Continuer la lecture de Event Driven Architecture : Apache Kafka sur le rivage

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

Hack : Facebook montre à PHP son retard

hackCoup de tonnerre dans le Landerneau de PHP : Facebook, après avoir sorti HipHop pour exécuter PHP en mode compilé, après avoir sorti HHVM et son compilateur à la volée, passe la seconde et propose son fork de PHP avec de nombreuses évolutions par rapport au langage original.

Comme je l’avais déjà indiqué dans un billet précédent, il y avait plus urgent à ajouter dans PHP qu’une API pour les passwords ou les générateurs. Et là, j’avoue avoir l’eau à la bouche.

Hack (car c’est son petit nom si affectueux) nous propose :

  • Un grand coup de balai dans les vieilleries et autres mauvaises pratiques du langage (genre les globals !)
  • Du typage un peu plus fort (pas du luxe)
  • Un peu d’asynchronisme
  • Des génériques (enfin pouvoir avoir des Array<Machin>)
  • Des collections
  • etc.

Bref, sur le papier ça donne vraiment envie, et on peut compter sur Facebook pour fédérer une communauté. Voilà ce que devrait être PHP 6.

En tout cas, j’ai hâte de voir ce qu’on peut en faire. Alors voilà, c’est pas que je m’ennuie avec vous, mais je vais de ce pas monter un HHVM et faire joujou avec.

Des news bientôt !

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)

Ce qu’il me manque vraiment dans PHP

DISCLAIMER : je suis en mode grosse mauvaise foi ce soir, mais si ça peut donner des idées…

PHP est un langage que j’aime beaucoup. Je l’utilise depuis plus de 10 ans maintenant, et dans ce laps de temps, il a énormément évolué.

J’ai connu un langage de script facile à utiliser, mêlant  à l’époque le code et le HTML (je sais, on ne fait plus ça maintenant, mais j’étais jeune et innocent…).

La version 5 a amené un modèle objet qui tenait enfin la route. Ne serait-ce que les accesseurs et la différentiation entre méthodes statiques et d’instance ont donné un énorme confort d’utilisation et une limitation des erreurs d’utilisation des librairies par des clients.

Malheureusement, depuis 2 versions, j’ai la nette impression que les ajouts faits au langage sont plus du cosmétique.

  • PHP 5.4 : principalement de la syntaxe avec la notation courte des tableaux, la possibilité d’appeler des méthodes sur une instance anonyme créée, ou la dispo de <?= même si les short_open_tags sont désactivés. (Bon OK, il y a les traits aussi, mais je n’aime pas trop ce type de structure qui nuit à la lecture du code à mon avis)
  • PHP 5.5 : une nouvelle API pour gérer les mots de passe (euh… je faisais très bien sans en fait), le mot clé finally (OK, celui-ci est plutôt utile), et opcache (plutôt une extension et les générateurs (pratiques, mais pas révolutionnaires non plus)
  • PHP 5.6 va sans doute proposer une possibilité de gérer des fonctions variadics (avec un nombre variable d’arguments) par exemple.

Je sais, je suis de mauvaise foi, car chaque version apporte une évolution en terme de performance, et, de plus, il y est fait un gros nettoyage d’un certain nombre de mauvaises idées (comme le safe-mode) ou fonctionnalités obsolètes (comme les fonctions ereg*).

Mais est-ce vraiment ce qui nous bloque le plus ? J’aurais tendance à dire que non (mais je suis peut-être le seul à le penser bien sûr).

Ce qui me manque le plus, c’est un vrai contexte d’application, et pas seulement une capacité de persister un contexte réutilisable facilement (comme dans un memcache par exemple). Une zone dans laquelle on pourrait gérer un vrai pool de connexion aux bases de données (à la manière des datasources de Java), et ceci faciliterait aussi la gestion des connexions persistentes aux bases de données (en cas d’indisponibilité temporaire, ou en cas de bascule automatique sur une standby par exemple).

Pour avoir ce genre de système de manière efficace, il faut en général se tourner vers Java, mais quand de grandes sociétés ont basé leur stratégie de développement sur un langage, il est toujours difficile d’ajouter un nouveau larron dans le SI (même si une architecture basée sur les principes de la SOA peut faciliter cette transition bien sûr). De plus, la JVM apporte une complexité d’exploitation pour les ops et la nécessité de maîtriser les arcanes du garbage collector.

J’avoue ne pas avoir le début du commencement d’une idée sur la manière de gérer ce point de manière efficace… sans doute en utilisant un nouveau type de SAPI, ou faire évoluer APC… mais avouer que ce serait top, non ?

Allez ! Je me le note sur ma liste au père noël pour l’an prochain… et pourquoi pas essayer de le faire si j’arrive à me dégager un peu de temps.