Managing monolithic repositories with composer’s path repository

Composer now have a new repository type in addition to, among others, the well known vcs for instance: the path repository. The goal if this repository is to be able to manage dependencies between applications and packages in a monolithic repository.

A monolithic repository?

The first question can be: why a monolithic repository? There are many blog posts and videos around about why such a code repository can be extremely useful for your project and your team, but we can quickly summarise that in some cases you’ll find at least these advantages:

  • Reduced bootstrap cost as new starters just need this repository
  • Easier to have cross-applications patches (via a single pull-request for instance)
  • You don’t need to download dependencies as they are here 😉

Obviously there are also some potential problems such as the ease of BC breaks between your libraries/applications and also shared responsibility, but that’s more related to the developers than the tooling.

Continue reading Managing monolithic repositories with composer’s path repository

facebooktwittergoogle_plusredditpinterestlinkedinmail

PHPUnit: MySQL “Too many connections” error

Even if it's the best idea to write tests that need a real database connection, sometimes it's something needed. If you're using Symfony2, you can simply follow the "How to test Doctrine Repositories" part of Symfony documentation to do that.

But if you're running a large amount of tests you'll get the following MySQL error:

SQLSTATE[08004] [1040] Too many connections

This means that you reached the maximum number of simultanous connections (max_connections parameter in my.cnf). To fix that behaviour, I had to change the processIsolation parameter of PHPUnit in the phpunit.xml file, like this:

<phpunit
backupGlobals = "false"
backupStaticAttributes = "false"
colors = "true"
convertErrorsToExceptions = "true"
convertNoticesToExceptions = "true"
convertWarningsToExceptions = "true"
processIsolation = "true"
stopOnFailure = "false"
syntaxCheck = "false"
bootstrap = "bootstrap.php.cache" >

facebooktwittergoogle_plusredditpinterestlinkedinmail

php-fpm segfault at f6 avec APC

En voulant modifier la configuration d’APC, pour augmenter la taille d’un segment de 30M à 64M, j’ai uniquement modifié la directive apc.shm_size. L’opération m’as valu une erreur de segmentation lors du démarrage de php-fpm.

Je me suis donc mis à la tâche de mettre à jour PHP ainsi que tous ces modules PECL sous Gentoo. Une fois la mise à jour s’étant bien passé, APC est à la version 3.1.9 mais php-fpm refuse toujours de démarrer… J’ai donc remis la valeur de apc.shm_size à 30M et php-fpm s’est très bien lancé.

On peut donc vérifier la taille maximum de mémoire partagée allouée par le système de le fichier /proc/sys/kernel/shmmax :

Par conséquent, on peut voir qu’APC n’a pas pu réserver 64M de mémoire partagée, puisque le système lui refuse. Je déplore un peu le manque de message d’erreur et l’erreur de segmentation qui peut provenir de “nul-part” si l’on configure son système automatiquement.

À ce stade vous avez deux possibilités:
Continue reading php-fpm segfault at f6 avec APC

facebooktwittergoogle_plusredditpinterestlinkedinmail

Symfony 2 et PostgreSQL: Mots réservés

Symfony 2 propose une abstraction des entities très intéressante grâce à Doctrine. Je poste ce petit article car j’ai eu une erreur tout simple:

En fait, j’ai créé un bundle nommé User, et doctrine souhaite donc créer la table User. Le problème, c’est que user est un mot clé réservé dans PostgreSQL. Par conséquent, il faut donc forcer Doctrine à escaper le nom de la table. Pour se faire, il suffit d’ajouter une annotation Table en préfixant et suffixant le nom de la table par .

Voici par exemple ma classe User avant la correction:

Il suffit donc de d'ajouter l'annotation @ORMTable en spécifiant le nom de la table entouré de . Le nouveau code est:

Ainsi, Doctrine va générer ses requêtes en ajoutant des caractères d’échappement sur le nom de la table. Ainsi, vous n’aurez plus d’erreur! :)

facebooktwittergoogle_plusredditpinterestlinkedinmail

Zend PHP 5.3 Developer Certified

Ça y est, je suis développeur PHP 5.3 certifié par Zend! :-)

Le principe du concours est très simple: vous avez 90 minutes pour répondre à 70 questions aléatoires concernant le fonctionnement de PHP ainsi que les différents domaines qui l’entour, à savoir le SQL, la sécurité en général, etc…

Je vous conseil de le passer, c’est sans aucun doutes un bon élément sur le CV. Si vous avez un quelconque question, n’hésitez pas!

facebooktwittergoogle_plusredditpinterestlinkedinmail

Erreur PHP – require_once(): Unable to allocate memory for pool

Depuis peu, PHP me sort des erreurs assez bizarres, à savoir des “Unable to allocate memory for pool“. Ceci se passe notamment sur les fonctions require_once et include_once. Après quelques temps de recherche, il s’avère que c’est en fait APC qui créé cette erreur lorsqu’il n’a plus assez de place dans sa mémoire.

C’est pourquoi, pour éviter ce bug – voir ici le rapport de bug sur php.net – vous devez augmenter la mémoire allouée à APC avant d’attendre une mise à jour corrigeant ce problème.
Dans le fichier /etc/php.d/apc.ini (sous CentOS) éditez donc la ligne contenant la directive apc.shm_size en y ajoutant plusieurs mégas. Pour information, voici la configuration du serveur hébergeant D-Sites.com:

facebooktwittergoogle_plusredditpinterestlinkedinmail

Installer HipHop sur CentOS 5

HipHop pour PHP est un programme développé par Facebook permettant de compiler des applications PHP en binaire. Cela permet une augmentation très importante des performances de celle-ci. Pour l’installer sur CentOS 5, il vous suffit d’ajouter quelques dépôts et d’utiliser yum.

Note: HipHop n’est pour l’instant supporté que sur les architectures 64 bits.

Installation des nouveaux dépôts

Pour installer les 3 nouveaux dépôts, il vous suffit de lancer ces 3 commandes:

Installation de HipHop

Ensuite, il vous suffit de lancer yum pour installer HipHop via les nouveaux dépôts configurés:

yum se chargera de l’installation de toutes les dépendances nécessaires et trouvées dans les dépôts.

Important: par défaut dans CentOS, la version de gcc est la version 4.1.2 alors que la version minimum pour HipHop est la version 4.4. N’oubliez pas de mettre à jour gcc, ainsi que g++.

Une fois l’installation terminée, le compileur hphp se trouve dans le /usr/bin, ainsi que dans le répertoire de HipHop, à savoir /usr/lib64/hphp/.

facebooktwittergoogle_plusredditpinterestlinkedinmail

HipHop pour PHP, qu’est-ce que c’est ?

Le nouveau projet Open Source pour PHP du moment, c’est bien HipHop, développé pour PHP, qui consiste à transformer le code PHP en C++ puis de le compiler en utilisant g++. Présenté dans l’article précédent Facebook & PHP II: HipHop et HPHPi, voici de nouvelles informations, issues de la conférence de cette nuit.

Facebook qui utilise déjà HipHop sur 90% de ses serveurs a constaté:

  • Sur les serveurs Web: 50% de consommation CPU en moins pour un même trafic, par rapport à PHP 5.2 avec APC
  • Sur les serveurs API: 30% de consommation CPU en moins pour deux fois plus de trafic

HipHop transforme le code en C++ et le compile avec g++ mais l’utilisateur n’a pas besoin de compiler à la main son code PHP avec un outils, tout reste comme avant, avec l’édition de fichiers PHP à la volée.

Néanmoins, les fonctionnalités qui ne seront pas disponibles:

  • La fonction eval
  • La fonction create_function, qui est du même acabit que eval
  • La fonction preg_replace, avec le paramètre e, qui permet l’application de eval sur le résultat
  • De manière plus générale, l’ordre des objets ne peu pas être respecté, du fait d’une exécution non-linéaire du code. Ainsi, la fonction function_exists retourne la valeur vraie dans ce code:

En plus de HipHop, l’équipe de Facebook a développé HPHPi, c’est un interpréteur PHP, il semblerait que ça soit grâce à lui qu’il ne sera pas nécessaire de compiler le code PHP. Il fait aussi des analyses du code pour y détecter des éventuelles erreurs dues à l’utilisation de HipHop et non de PHP.

HipHop embarque son propre serveur Web et n’est pas le moment pas compatible/prêt à fonctionner avec Apache ou un autre serveur. C’est pourquoi HipHop c’est un seul processus, contrairement à PHP mais qui utilise le principe de multi-thread, plus rapide que le multi-processus car créer un processus, c’est assez long par rapport aux threads. Comme HipHop utilise sont propre Web serveur allégé, il est plus rapide et permet de mieux gérer les ressources partagées entre les threads, il permet aussi de ne pas avoir de downtime, c’est-à-dire de temps d’inaccessibilité lors d’un redémarrage de HipHop.

HipHop est pour le moment basé sur PHP 5.2, et l’équipe de chez Facebook compte bien avancer encore plus sur ce projet et voici leur Roadmap, ou liste de choses à faire:

  • Apport des fonctionnalités de PHP 5.3
  • Utilisation possible avec Apache
  • …et plus généralement la réduction de l’écart entre HipHop et PHP

Le code source qui était sensé être mis en ligne cette nuit sera maintenant mis en ligne “soon” !

facebooktwittergoogle_plusredditpinterestlinkedinmail

Facebook & PHP II: HipHop et HPHPi

Apprenez en plus dans le nouvel article, HipHop pour PHP, qu’est-ce que c’est ?

Comme prévu et annoncé dans l’article précédent “Facebook + PHP = Hyper-PHP”, l’équipe de développement de Facebook a bien annoncer son projet de faire une sorte de compilateur pour PHP cet après-midi, vous pouvez la retrouver en anglais à cette adresse.

Ce n’est en fait pas sous le nom de Hyper-PHP que les développeurs de Facebook ont décider de sortir leur moteur, mais sous le nom de HipHop, accompagné de HPHPi.

Facebook n’a en réalité pas tout à fait réécrit PHP depuis le début, mais a décidé de créer une extension PHP qui transforme un code PHP en un code C++, puis qui le compile. HipHop, c’est le nom du module/programme/de l’extention PHP qui va transformer votre code PHP en code C++, puis le compiler en utilisant le traditionnel g++. HPHPi, lui, permet de ne pas avoir à mettre en place un système de compilation en plus, et d’avoir simplement a utiliser PHP comme avant, mais en beaucoup plus rapide.

Les chiffres ont néanmoins changer car on ne parle ici que d’une diminution de 50%contre 80% d’après les rumeurs précédentesde la consommation du CPU, sans même avancer de chiffres d’augmentation de performances, même si il est tout de même le sujet de tout l’article de Facebook, c’est donc sans douter que ça a très certainement un gros bénéfice, puisque Facebook.com l’utilise déjà sur près de 90% de ses serveurs!

À noter tout de même que dans l’article, il est précisé que des fonctions sont perdues, comme la fonction eval par exemple (ce n’est pas plus mal pour celle-ci) et que l’équipe de développement a réécrit de nombreuses extensions pour les adapter à leur HipHop PHP, ce qui fera sans aucun doute que cette innovation pour PHP ne sera pas ajoutée à PHP, contrairement aux caches OPCodes qui le seront pour PHP 6, et restera un projet distant externe à PHP pour un petit moment.

C’est donc à tester sans attendre, lorsque que les sources seront disponibles dans la nuit (fin d’après-midi chez nos amis américains) à cette adresse, qui ne marchera que lorsque les sources seront disponibles:

Dès possible je ferais des tests et des benchmarks, que je ne manquerait pas de diffuser ici.

facebooktwittergoogle_plusredditpinterestlinkedinmail

Facebook + PHP = Hyper-PHP

Lisez l’article plus récent: PHP & Facebook II: HipHop et HPHPi »

Voilà quelques temps que les rumeurs circulent, je vais donc faire un petit résumé de ce que l’on appelle Hyper-PHP, ou HPHP. Le site web de l’entreprise Facebook est composé à 90% de PHP, un langage de programmation tourné vers le Web, qui est ré-analysé depuis de début à chaque fois, c’est-à-dire qu’a chaque installation, le runtime PHP doit analyser toute la source pour faire tourner le script PHP, c’est ce qui lui confère une lenteur par rapport aux applications compilées.

Et bien Facebook aurait décidé, il y a 2 ans, de mettre un développeur à part entière sur ce projet, qui aurait pour but de créer une sorte de compilateur pour PHP. C’est en effet ce que ressort d’une interview anonyme recueilli par TheRumpus.net.

He is creating HPHP, Hyper-PHP, which means he’s literally rewriting the entire language. […] So this engineer is converting the site from one that runs on a scripted language to one that runs on a compiled language.

Alors que l’annonce doit avoir lieu aujourd’hui, le 2 février 2010, cette nouvelle mouture de PHP, si l’on peux l’appeler comme ça, va très certainement changer beaucoup de choses car d’après l’ingénieur Facebook chargé de ce projet, Hyper-PHP consommerait 80% de CPU en moins tout en ayant des performances augmentées de 80% ! Il sera de plus partagé en Open Source, comme un grand nombre de projets de Facebook.

A bientôt pour la suite! :-)

facebooktwittergoogle_plusredditpinterestlinkedinmail