PHP

Share and options

Le core et le cache et les caches inutiles

Précedement dans un article parlant d'un cas concret de mauvaise gestion de cache j'ai évoqué le hook_hook_info() ; En continuant ma lecture de code sur le sujet, je me suis aperçu d'une autre erreur de gestion de cache de la part des développeurs du core : les cache inutiles.

Drupal core, les hooks, les groupes, et un cache désastreux

Dans un article précédent je vous ai présenté la gestion des caches d'une manière assez théorique  Je ne pensais pas que ce matin même j'allais tomber sur un très bon exemple d'une mauvaise gestion de cache, et je pensais encore moins la trouver dans le core. Cet article va présenter, d'une façon aussi objective que possible, l'anatomie de ce cache particulier, et pourquoi même si l'idée était bonne théoriquement, elle s'est en réalité avérée catastrophique dans mon cas d'utilisation. Je vais dans les paragraphes suivants qualifier cette gestion de cache de réel bug.

Le site qui vous fera dire Bonjour!

Mise à jour du 12 mars 2011 : Le fameux module est loin d'être efficace à 100%, je reçois régulièrement des SPAM qui arrivent à se faire publier sous la forme de commentaires. Cependant, beaucoup moins que lorsque que j'avais aucun filtre, il y'a encore quelques temps (de plus même avec le module CAPTCHA, il y'a toujours des SPAM manuels qui passent).

Blazé devant la lenteur du module Captcha pour Drupal à être porté sur Drupal 7, j'ai fini par écrire un micro module pour le remplacer. Ce module injecte des champs de manières arbitraire dans tous les formulaires et procède à une série d'altérations — plus ou moins arbitraires—  pour aller dessus. Certains de ces champs doivent être vidés, d'autres non, certains autres ne doivent pas changer. Bref, suffisament de cas d'utilisation, j'espère, pour éviter la majeure partie des SPAM.

Des caches Drupal! (et surtout des caches)

Comme promis dans l'article précédent, je vais vous introduire la gestion du cache dans Drupal 7. Dans cet article, je ne vais pas m'étendre sur les politiques de cache d'un point de vue du développeur, mais plutôt du choix du backend approprié en fonction de l'environnement. Cet article a donc vocation de se placer plutôt côté architecte ou administrateur système.

Je suis moi même développeur, architecte n'est pas mon métier, cependant avoir un point de vue éclairé sur les problématiques que rencontrent ces derniers – sans pour autant être un expert – peut amener à se poser des questions sur le code que l'on produit. L'architecture et le design d'une application web (ou d'un sous-ensemble de cette dernière) poussent à se poser la question d'une politique de gestion de cache efficace. Pour mener à bien la conception d'une politique de cache, il faut comprendre les problèmatiques qui se posent derrière.

Cet article va être tourné plus particulièrement à la gestion du cache dans Drupal 7, qui à été grandement améliorée depuis Drupal 6. L'accent sera mis sur les différents backends.

Note de fin de soirée : Terminant cet article, je me suis rendu compte que ma simple introduction à la problématique elle même s'avère être suffisament consistente pour exister en tant qu'article complet. C'est pourquoi je m'arrête ici ce soir. Je vous souhaite une bonne lecture.

Des caches Drupal! (et un peu APC aussi)

Bonjour à tous, comme convenu dans mon premier article, qui était un étalage de benchmark peu revelant significatifs (je finis toujours par retrouver le mot français, déformation professionnelle vous me direz), voici un article concernant les optimisations basiques obligatoires à effectuer pour des sites Drupal. Ces techniques sont issues de presque 3 ans d'expérience avec le framework, mais surtout du travail conjoint de plusieurs personnes, notamment Régis (notre admin système, PHP warrior qui plus est).

Cet article traitera brièvement des options APC, puis s'étendra sur la mise en place de backend de cache multiples sur Drupal 7, comment faire, lesquels choisir, et comment en mesurer l'impact. Je ne m'attarderais pas sur l'optimization du serveur SQL qui est un métier à part entière. De plus le débat ne m'intéresse pas puisque la communauté Drupal préfère toujours utiliser MySQL alors que PostgreSQL est bien supérieur, à tous les niveaux.

Mise à jour du 11/01/2011 : Merci à gagarine de m'avoir signalé que l'option apc.optimization à été supprimée depuis la version 3.0.13 d'APC.

Comment bien optimizer un Drupal 7

Après de longues heures de benchmarks divers et variés, j'ai enfin réussi à avoir obtenir une configuration optimum pour faire tourner un Drupal 7 correctement. Comme des bons exemples valent mieux que mille mots, voici en image comment faire :

Pour le benchmark, je vais utiliser la commande ab -n 100 -c 4 http://blog-d7.guinevere/

De la bonne utilisation de strtr()

Essayez un jour de taper ceci :

<?php
$lockMessage
= "This container is currently being edited by %account";
$lockMessage = strtr($lockMessage, '%account', 'Anonymous');
?>

Amusons nous avec PHP, aujourd'hui : le JSON et le console

Le petit problème du jour est le suivant : dans une application fortement AJAX, jQuery en client side, PHP en server side, j'ai besoin d'effectuer le debug de requêtes AJAX provenant du client en POST contenant du JSON, et le retour du serveur, contenant, du JSON aussi!

Pour ceci, on pourrait utiliser Firebug, que tout le monde connait bien, mais ne m'occupant pas de la partie JS, mais du code PHP serveur, j'ai pas envie d'inspecter 3000 lignes de JS pour mettre un break point au bon endroit.

Pour ceci, petit feinte, utiliser l'onglet Console de Firebug, et PHP en command line.

Tip of the day, get a views row primary key value

This is often a problem when you pragmatically manipulate views row's : finding the primary key value of the current row being explored.
Let's have an example : A node base table based view.

<?php
 
// Load the view, and stick to default display for sample purpose.
 
$view = views_get_view('my_node_view');
 
$view->set_display(NULL);
 
// Then, execute it.
 
$view->pre_execute();
 
// You will set some other options here, like limit, pager, offset.
 
$view->execute();
?>

What then?

Code snippet: human readable to machine name

This PHP code snippet compute nice machine name (i.e. with only alpha numerical characters, keeping inside hyphens) from a formated human readable name.

Useful for some automatic machine name identifiers computing from human readable arbitrary titles, I use it sometime in Drupal modules.

<?php
/**
* Helper that generates a machine name using a provided human readable name.
*
* @param string $human_name
*   Human readable name.
*
* @return string
*   Machine name cleaned-up of any special chars.
*/
function human_to_machine($human_name) {
  return
strtolower(preg_replace(array(
   
'/[^a-zA-Z0-9]+/',
   
'/-+/',
   
'/^-+/',
   
'/-+$/',
  ), array(
'-', '-', '', ''), $human_name));
}
?>

Pages