Au programme de ces deux journées :
- Conférences inédites sur les thèmes : réseaux sociaux, stratégies de migration, gestion de médias, Symfony 2…
- Retours d’expériences : Dailymotion, Yahoo!, L’Express…
- Experts : Fabien Potencier, Créateur et Lead developer de Symfony et PDG de Sensio Labs, Dustin Whittle, évangéliste Yahoo!, Jonathan Wage, Lead developer de Doctrine ORM…

Programme complet ici : http://www.symfony-live.com/schedule

A noter, cette manifestation a aussi le soutien de la très sérieuse AFUP. Cette première conférence française entièrement consacrée au framework Symfony est très attendue dans la communauté et personnellement, si mon agenda l’avait permis, j’aurais beaucoup aimé pouvoir y montrer mon nez.
Vous pourrez suivre la conférence en direct sur Twitter (@sflive09fr)

Mini rappel : Procédure, ou fonction ?

Si vous hésitez entre créer une procédure stockée ou une fonction, rappelez vous bien que la seule différence entre les deux est qu’une fonction va chercher un résultat (quitte à passer par des tonnes d’étapes intermédiaires), alors qu’une procédure va faire une action. En gros, si vous voulez avoir une valeur de retour, il vous faut une fonction. Dans le cas contraire, préférez une procédure.

Dans quel cas les utiliser, et comment ?

Vous pouvez vous tourner vers les ProcStock (pour “procédures stockées”, le terme étant souvent utilisé aussi pour les fonctions) partout où vous exécutez des traitements de calculs lourds et/ou sur de gros volumes de données. L’avantage énorme est que vous n’aurez pas à rapatrier des resultsets de grande taille, pour les traiter en PHP (par exemple), puis les insérer en base: tout se fera directement en une seule requête très simple, qui appellera la fonction/procédure.
Les fonctions MySQL que vous allez définir s’utilisent exactement comme les fonctions prédéfinies (bien que celles-ci soient en général écrites en C et compilées avec le serveur… c’est faisable aussi pour un gain maximal en performances MySQL, mais ceci est une autre histoire), comme par exemple AVG (qui calcule une moyenne sur les valeurs d’un champ). Sans AVG (syntaxe: SELECT AVG(champ) FROM table), il faudrait récupérer les résultats concernés, les ajouter, puis les diviser par leur nombre : (1+5+6)/3 = 4. AVG fait ça toute seule et renvoie directement 4. Bien évidemment, il n’est pas bien grave d’avoir à récupérer 3 lignes. Mais avec 20.000 enregistrements, c’est différent, et les performances seront affectées, notamment en raison de l’utilisation de RAM nécessaire à l’exécution du script.
Il peut être aussi très intéressant d’utiliser des procédures et fonctions sur le serveur de bases de données quand plusieurs applications frontend dans des langages différents peuvent avoir à réaliser les mêmes actions: plutôt que d’écrire (et maintenir…) les actions communes en plusieurs langages, autant déporter leur exécution sur le serveur SQL, et demander aux clients de seulement interagir avec les fonctions stockées.

Application concrète

(je déplore mon manque d’imagination, qui m’oblige à chaque post à sortir des exemples totalement improbables…)
Imaginons un site de vente en ligne. Chaque jour est généré un rapport, enregistré en base, qui, en fonction du détail des ventes de la journée, calcule des indicateurs comme le chiffre d’affaires global et le panier moyen.
On aurait donc une table “commandes” avec un champ “montant” et un champ “date” (je simplifie, hein).
En PHP, sans procstock, il faut :

• Envoyer une requête qui prend les ventes de la journée passée
• Récupérer dans un tableau le détail des transactions
• Faire les calculs nécessaires (nombre de lignes, moyenne des montants, total des montants)
• Stocker ces résultats en base

Au bas mot, cela représente une vingtaine de lignes de PHP, avec deux communications depuis/vers la base de données, une boucle qui parse le tableau, des variables temporaires…
Dans cette situation, c’est d’une procédure stockée que nous avons besoin. On ne récupère pas les infos (pas de valeur retournée) mais on les stocke en base. Dans le cas contraire, on aurait créé une fonction.
La procédure stockée en question, que nous appellerons “genere_rapport”, va s’occuper de tout cela pour nous. Voici son code :

MySQL devrait répondre “Query OK, 0 rows affected (0.01 sec)” pour signaler que la procstock a bien été créée.
Première remarque, on change le délimiteur de fin de commande MySQL. La création d’une procédure/fonction doit se faire en une seule instruction MySQL, même si la procstock comporte plusieurs instructions à exécuter. J’avoue que ça surprend au début mais c’est un coup à prendre. Pensez bien à remettre le délimiteur normal (le point-virgule) après la création de votre procstock.
Ensuite, on lance la création de la procédure. On déclare d’abord les variables dont on aura besoin pour stocker les données (même si ici, on aurait pu directement faire le SELECT dans une sous-requête de l’INSERT, mais ce n’est pas le but): la liste des types disponibles est la même que les types des champs. On utilise ensuite SELECT INTO avec le nom de nos variables pour dire à MySQL dans quelle variable stocker quelle valeur, variables qu’on utilise ensuite dans une requête INSERT classique pour stocker le rapport.
Pour appeler la procédure, on fera CALL genere_rapport();. Pour une fonction, ça sera SELECT nom_de_la_fonction();

Conclusion

Penchez-vous sur vos applications PHP, il y a certainement des tas d’actions que vous pourrez déporter vers des procédures stockées. Les gains de performances devraient être rapidement ressentis, pour un effort d’apprentissage minimal.
Dans un prochain post, nous irons plus loin avec les procédures stockées, en utilisant notamment des paramètres, des curseurs, des handlers, et autres joyeusetés. Le plus difficile sera de trouver un exemple intéressant…

Exports CSV avec MySQL : SELECT INTO OUTFILE

Le principe de SELECT INTO OUTFILE est simple: réaliser un export de données en écrivant un resultset (résultats d’exécution d’une requête) directement dans un fichier CSV sur le serveur. Pour cela, l’utilisateur avec lequel vous vous connectez à MySQL doit avoir le priilège “FILE”. Autre remarque, vous ne pourrez en aucun cas écraser un fichier déjà existant sur le serveur (ceci pour la simple et bonne raison qu’il serait assez dommageable d’écraser, par exemple, votre fichier /etc/passwd).

Voici donc la syntaxe, finalement assez simple, de la fonction SELECT INTO OUTFILE :

Dans le fichier exporté, les champs ne sont pas délimités, sauf si vous utilisez FIELDS ENCLOSED BY. Le OPTIONALLY spécifie que seules les chaînes de caractères doivent être encadrées.
Le délimiteur par défaut est l’espace. Pour en utiliser un autre (virgule, point-virgule, tabulation, …) il faut utiliser la directive FIELDS TERMINATED BY. Evidemment, on peut utiliser des caractères spéciaux comme la tabulation ‘t’ ou le retour à la ligne ‘n’ (éventuellement CR+LF sous Windows, donc ‘rn’). Il existe aussi LINES TERMINATED BY pour contrôler le caractère de fin de ligne.

Du coup, en lançant sur la base de mon blog cette requête :

j’ai pu récupérer un fichier plat qui donnait :

Soit, un joli fichier CSV bien propre, directement exploitable (pourquoi pas par Excel).

Imports de CSV dans MySQL : LOAD DATA INFILE

Le LOAD DATA INFILE, qui permet de faire l’exact inverse du INTO OUTFILE, est tout aussi simple à utiliser. Dans les bonnes conditions, c’est vraiment l’un des outils d’import MySQL les plus puissants.
Déjà, bonne nouvelle, la syntaxe des commandes qui permet à LOAD DATA INFILE de repérer les débuts et fin de champs (et de ligne) est la même que pour SELECT INTO OUTFILE. On retrouve donc sans surprise les FIELDS TERMINATED BY et autres joyeusetés.
Une gestion des doublons est aussi possible grâce aux mots-clefs IGNORE et REPLACE, qui parlent d’eux-même. Déclenchés en cas de doublon dans une clé (primaire ou unique), REPLACE effacera l’ancienne ligne pour la remplacer par la nouvelle. Attention donc, vous perdrez donc la pérennité de vos ID puisque ceux-ci changeront lors de l’import de données. IGNORE permettra simplement de conserver l’ancienne ligne, les nouvelles données n’étant pas écrites: vous conservez vos ID mais perdez le bénéfice de l’import sur cette ligne.
Vous pouvez aussi spécifier la liste des champs dans lesquelles les données doivent être stockées avec la syntaxe classique “(champ1, champ2, champ3)” (sans guillemets) en fin de commande.
Pour prendre un exemple, avec un fichier de la forme :

En imaginant qu’on ne veut garder que l’id (champ 1) et le texte (champ 3), et les insérer dans les champs correspondants de la table SQL “data”, on peut utiliser le paramètre @dummy pour demander au serveur d’ignorer l’un des champs du CSV. Cela nous donne une requête de la forme :

Et si par malheur votre fichier commence par 2 lignes d’entête, pas de souci, vous pouvez présicer IGNORE 2 LINES dans la requête pour que soient ignorées les 2 premières lignes.

Et voila. Deux commandes, finalement pas bien complexes une fois qu’on les a prises en main, qui permettent de gérer efficacement les imports/exports de fichiers CSV sous MySQL. Pour faire suite à cet article, nous verrons bientôt comment optimiser la vitesse de vos INSERT dans MySQL.

1. Eclipse PDT

Vu ses parents, Zend et IBM, le projet Eclipse PDT est un “(Php) Development Tools framework” complet. Il étend les capacités natives de la plate-forme Eclipse pour permettre de développer calmement des applications solides en PHP. Pas vraiment besoin de le présenter, si ?
Eclipse PDT est téléchargeable en tant que plug-in ou en version “bundle” (PDT all-in-one), c’est à dire avec Eclipse et tous les composants de base. Ceci est très utile dans le cas d’une nouvelle installation.
Télécharger Eclipse PDT

Il existe d’autres plugins permettant d’ajouter à Eclipse le support du PHP, comme PHPEclipse ou Eclipse PHP IDE, développé par Zend.

2. RegEx Util

Editeur d’expressions régulières, toujours pratique de part le fait qu’il surligne les expressions qui matchent quand on sélectionne une partie du pattern. Il permet aussi de rationaliser ses expressions, notamment en utilisant les classes prédéfinies -comme [alphanum]

Site officiel : http://myregexp.com/eclipsePlugin.html
Update Site : http://regex-util.sourceforge.net/update/

RegexUtil pour Eclipse

3. SubClipse

SVN pour Eclipse avec Subclipse

Ajoute le support de SVN (SubVersion) à Eclipse. SVN est un système de gestion de versionning comme CVS intégrant quelques améliorations, comme la possibilité de déplacer et supprimer des fichiers, sans perdre leur historique.

Site officiel : http://subclipse.tigris.org/
Update Site (pour la branche 1.6) : http://subclipse.tigris.org/update_1.6.x

4. Remote System Explorer (RSE)

Permet notamment d’éditer ses fichiers directement via une connexion SSH. Je m’en sers pour les petites retouches de code PHP rapides qui ne peuvent “pas attendre”.

Site officiel : http://www.eclipse.org/dsdp/tm/tutorial/
Update Site : http://download.eclipse.org/dsdp/tm/updates

5. Azzuri Clay

Azzurri Clay: bases de données sous Eclipse

Un peu difficile à prendre en mains, Azzuri Clay est un plugin commercial pour Eclipse qui permet d’ajouter un vrai support des bases de donnéees. Le système de licence adopté est un peu étrange: la version Pro ne peut être achetée qu’au Japon. Il n’en reste pas moins que l’édition classique, gratuite, est toujours intéressante.
La liste des SGBDR supportés est assez impressionnante vu qu’elle comprend, notamment, les classiques MySQL, PostGres, Oracle, MS SQL Server, DB2, Informix, mais aussi, beaucoup plus rare, SAP.

Pour se servir du Database Modeler d’Azzuri Clay, il faut créer un projet (ou utiliser un projet déjà existant) et faire File -> New -> Other -> Database Modeling -> Azzurri Clay Database Design Diagram.

Une fois cela fait, on peut créer ses premières tables, exporter les scripts SQL de création (selon le SGBDR choisi), et même faire du retro engineering sur des bases de données déjà crées.

Site officiel : http://www.azzurri.jp/en/clay/index.html
Update Site : http://www.azzurri.co.jp/eclipse/plugins

Références pour Eclipse

Installation minimale d’Eclipse, par Thierry Bothorel

Principe de fonctionnement

Admettons que sur votre nouveau site social-2.0-multimedia (etc), vous avez une fiche utilisateur. Chaque fiche comportera, peu ou prou, les mêmes informations, notamment le login de l’utilisateur. Voici comment procéder. Créez d’abord un fichier user.tpl (Note sur les fichiers .tpl : l’extension est libre, mais l’usage du .tpl est une convention; la plupart des IDE possédent des plug-ins pour permettre l’analyse et la coloration syntaxique de ce language de balises. Pour les puristes -je ne parle pas pour moi-, on peut justifier l’emploi du “tpl” au lieu d’un “html” plus classique par le fait que les templates contiendront certes du HTML, mais aussi des instructions destinées au moteur de template… mais bref!) . Ce fichier contiendra :

Le fichier php qui l’utilisera contiendra, lui :

On instancie un objet de la classe Smarty (ligne 1) on déclare une variable de template appelée ‘login’ qui contiendra la valeur de la variable php $user_login (ligne 2). On demande ensuite à Smarty d’ “exécuter” et d’afficher le fichier user.tpl (ligne 3).
Vous l’aurez compris, le login de l’utilisateur apparaîtra en lieu et place du {$login} dans le fichier template. Les {} indiquent à Smarty que ce code doit être exécuté, et non directement reproduit en sortie (ce qui est le cas du HTML). Ces signes encadreront toutes les balises Smarty. Vous remarquerez que la variable se déclare en php sans le signe $, mais qu’il faut utiliser celui-ci lorsqu’on veut accéder à la valeur de la variable dans le fichier de template.

Gestion des tableaux sous Smarty

Si, en PHP, on assigne une tableau à une variable Smarty, on peut y accéder grâce au point, avec la syntaxe $tableau.index.

Fonctions prédéfinies

(lien vers la doc officielle)

Le tag {literal}

S’il vous arrive de devoir utiliser des accolades {} dans le code–source de votre template (par exemple pour y intégrer des fonctions JavaScript), il faut les entourer du tag Smarty {literal}{/literal}, afin d’indiquer au moteur de template de ne pas parser le contenu, ce qui provoquerait une erreur.

Gestion des dates avec Smarty

Smarty gère l’affichage des dates très efficacement grâce à un modificateur de variable (un filtre) nommé date_format. La syntaxe de date_format sous Smarty est la suivante :

Qui affiche :

Pour passer la date que Smarty va afficher en français, il suffit d’utiliser setlocale() en php, comme ceci:

(n’hésitez pas à me dire si vous voulez un post plus complet sur l’installation – au moins sous Debian – et l’utilisation des locales en php). La date affichée devient alors :

Voici les options que vous pouvez passer à la fonction date_format de smarty :

• %a – Abréviation du jour de la semaine, selon les paramètres locaux.
• %A – Nom du jour de la semaine, selon les paramètres locaux.
• %b – Abréviation du nom du jour, selon les paramètres locaux.
• %B – Nom complet du mois, selon les paramètres locaux.%c – Préférences d’affichage selon les paramètres locaux.
• %C – Siècle, (L’année divisée par 100 et tronquée comme un entier, de 00 à 99)
• %d – Jour du mois, en tant que nombre décimal (de 01 à 31)
• %D – même chose que %m/%d/%y
• %e – Jour du mois en tant que nombre décimal. Un chiffre unique est précédé par un espace (de 1 à 31)
• %g – Position de la semaine dans le siècle [00,99]
• %G – Position de la semaine, incluant le siècle [0000,9999]
• %h – identique à %b
• %H – L’heure en tant que décimale, en utilisant une horloge sur 24 (de 00 à 23)
• %I – L’heure en tant que décimale en utilisant une horloge sur 12 (de 01 to 12)
• %j – jour de l’année (de 001 à 366)
• %k – Heure (horloge sur 24). Les numéros à un chiffre sont précédés d’un espace. (de 0 à 23)
• %l – Heure (horloge sur 12). Les numéros à un chiffre sont précédés d’un espace. (de 1 à 12)
• %m – Mois en tant que nombre décimal (de 01 à 12)
• %M – Minute en tant que nombre décimal
• %n – Retour chariot (nouvelle ligne).
• %p – soit am soit pm selon l’heure donnée, ou alors leurs correspondances locales.
• %r – heure en notation a.m. et p.m.
• %R – Heure au format 24 heures
• %S – Secondes en tant que nombre décimal.
• %t – Caractère tabulation.
• %T – Heure courante, équivalent à %H:%M:%S
• %u – Jour de la semaine en tant que nombre décimal [1,7], ou 1 représente le lundi.
• %U – Le numéro de la semaine en nombre décimal, utilisant le premier dimanche en tant que premier jour de la première semaine.
• %V – Le numéro de la semaine de l’année courante selon la norme ISO 8601:1988, de 01 à 53, ou la semaine 1 est la première semaine qui dispose au minimum de 4 jours dans l’année courante et ou Lundi est le premier jour de cette semaine.
• %w – Jour de la semaine en tant que nombre décimal, dimanche étant 0
• %W – Le numéro de la semaine de l’année courante en tant que nombre décimal, ou Lundi est le premier jour de la première semaine.
• %x – Représentation préférée de la date selon les paramètres locaux.
• %X – Représentation préférée de l’heure selon les paramètres locaux, sans la date.
• %y – L’année en tant que nombre décimal, sans le siècle. (de 00 à 99)
• %Y – L’année en tant que nombre décimal, avec le siècle.
• %Z – Zone horraire, nom ou abréviation
• %% – Un caractère litéral `%’

Lectures intéressantes sur Smarty:

• Documentation officielle de Smarty (en français)
• Initiation à Smarty par Eric Pommereau

Pour aider à la rédaction de ma série d’articles, n’hésitez pas à laisser un commentaire sur un sujet que vous voudriez voir abordé, ou à me signaler des docs intéressantes sur Smarty, je me ferais un plaisir de les rajouter dans les lectures intéressantes

Le principe de Screen

Screen est un utilitaire en ligne de commande qui permet de créer plusieurs shells virtuels qui tournent en parallèle. En l’utilisant, vous aurez donc accès à plusieurs “sessions”, comme si vous aviez lancé plusieurs clients SSH.

Enorme avantage, screen ne s’arrête pas quand votre connexion au serveur est coupée. En rouvrant votre session Unix normale, vous pourrez faire screen -r (Recover) pour retrouver toutes vos fenêtres exactement dans l’état où vous les avez laissées (les actions en cours ont continué, les scripts ne sont pas interrompus, etc).

Après une rapide installation (le package apt se nomme “screen”), l’utilitaire est directement utilisable. Tapez “screen”, rien ne se passe. Et pourtant tout est ok, on y est. Bienvenue dans le monde de screen. Faites ce que vous avez à faire, éditez par exemple le fichier /etc/hosts de votre machine. Tapez ensuite control+A, puis C (pour Create). Une nouvelle fenêtre virtuelle est créée. Vous vous retrouvez devant une invite de commande, sur un shell vierge. Et c’est là que les réjouissances commencent. Faites un ls, par exemple. Ensuite, un Control+A puis N (Next) vous permet de passer à la fenêtre suivante gérée par Screen.
Toutes les commandes Screen sont composées de la combinaison Control+A puis une lettre (ou un chiffre).

Voici le menu :

• Ctrl-a c Créer une nouvelle fenêtre (Create)
• Ctrl-a k Fermer la fenêtre en cours (Kill)
• Ctrl-a w Liste les fenêtres disponibles (Windows) – La fenêtre courante est repérée par une étoile.
• Ctrl-a 0-9 Aller à la fenêtre N (Les chiffres sont dans la liste des fenêtres obtenue en faisant W)
• Ctrl-a n Aller à la fenêtre suivante (Next)
• Ctrl-a Ctrl-a Switche en mode “2 fenêtres” (ramène à la fenêtre précédemment affichée)
• Ctrl-a [ Copier
• Ctrl-a ] Coller
• Ctrl-a ? Liste des commandes (Aide/Help)
• Ctrl-a Ctrl-\ Quitter “screen”
• Ctrl-a d Détacher le process, en laissant la fenêtre ouverte

Le mode Copie de Screen

Screen peut aussi vous permettre de copier/coller efficacement du texte entre deux fenêtres. Pour cela, ouvrez le mode copie en faisant Ctrl-A [ .
Une fois dans le mode copie, vous pouvez déplacer le curseur à l'aide des touches H,J,K et L. La barre d'espace commence/arrête la sélection du texte. Ctrl-A ] servira alors à coller le texte copié dans le “presse-papiers”.

L’opcode ?

Oui, l’opcode. C’est le code généré par votre serveur Web (qui a dit Apache ?) à partir de vos scripts PHP, après leur interprétation et leur compilation. Ce code est exécutable, et sa génération prend un certain temps. A chaque exécution d’un script, le serveur régénère cet opcode, perdant ainsi un temps précieux: quand votre script n’a pas été modifié, cette étape est totalement inutile. On peut l’éviter en mémorisant l’opcode grâce à un cache d’opcode…
Attention, il ne faut pas confondre les caches d’opcode et les caches HTML: un cache HTML servira à envoyer directement la sortie d’un script au client, sans traitement. Le cache d’opcode, lui, laisse place à l’exécution proprement dite du script dans des conditions normales: les données provenant d’une base de données MySQL, par exemple, seront rapatriées comme à l’accoutumée. On ne perd donc aucune réactivité au niveau de l’application, tout en améliorant ses temps de réponse.

APC ? (Alternative Php Cache)

Oui, APC. APC est un projet libre, implémenté comme une extension Zend. Cela permet de le compiler dans PHP ou de l’intégrer plus tard, comme un module classique. Le principal avantage d’APC (et des autres caches d’opcode) est qu’il n’y a aucun besoin en terme de modification des scripts: il suffit d’installer et d’activer le module pour que celui-ci accélère vos scripts PHP. De ce côté là, donc, rien de spécial à ajouter.
APC permet, par un script d’administration, de suivre quels opcodes sont mis en cache, le nombre de hits économisés, ainsi que les données utilisateur. Très pratique, la colonne “miss” vous indique combien de scripts ont été appelés sans profiter de l’accélération d’APC (Cela peut arriver car vous pouvez mettre des filtres en place pour ne stocker que certains répertoires, ou limiter la taille en mémoire occupée par l’ensemble des scripts “compilés”, par exemple…)

Le cache de données utilisateur

Mais là où réside, selon moi, la vraie puissance d’APC, est dans son cache de données utilisateur. En effet, imaginons le cas où nous avons une requête SQL assez lourde, suivie d’un traitement assez conséquent: sur la page d’accueil d’un forum (lien-copinage), on souhaite afficher les derniers connectés et le nombre de messages qu’ils ont posté. En théorie, à chaque affichage de la page, on va réexécuter la requête, et donc assassiner bêtement le serveur SQL.
On pourrait stocker les données dans une Session PHP ? Oui, mais d’une, les sessions ne sont pas faites pour ça, et de deux, on exécuterait quand même la requête SQL et le traitement associé pour chaque nouveau connecté.
La meilleure solution reste alors d’utiliser le cache de données d’APC. On va pour cela se servir de la fonction apc_store, qui prend 3 paramètres :
bool apc_store ( string $key , mixed $var [, int $ttl ] )

• $key est le nom que l’on souhaite donner à la variable dans le “magasin” (store) d’APC. Je vous conseille de la préfixer du nom du site concerné si vous hébergez plusieurs sites sur le même serveur ; les variables sont accessibles à tous les scripts (attention donc à ce que vous faites dans le cas d’un hébergement partagé… ne stockez de préférence aucune donnée “sensible” à moins de savoir précisément ce que vous faites).
• $var est la valeur à stocker, qui peut être un nombre, une chaîne, un tableau, ou même un objet complet (Attention, dans ce dernier cas, à bien inclure la déclaration de classe de l’objet avant d’essayer de le récupérer…).
• $ttl est le “Time To Live” de la variable, c’est à dire le temps en secondes avant qu’APC ne l’efface de son store.

Par exemple, dans le cadre de notre forum, on aurait quelque chose comme :

Ce qui signifie qu’on stocke, tel quel, le tableau (array) $dernierConnectes, sous le nom forum_derniers_connectes, pour une durée de 60 secondes.

Pour accéder à la variable, on dispose de la fonction apc_fetch, qui prend le $key de la variable en paramètre, et renvoie soit la valeur stockée, soit FALSE en cas d’échec. On peut donc faire :

C’est tout ! Si APC trouve la variable, il renseigne $derniersConnectes. Dans le cas contraire, on rapatrie les infos et on les stocke pour 60 secondes. La requête-de-la-mort ne sera plus exécutée qu’une fois par minute.

Bénéfices

Le bénéfice est donc double: on économise à la fois sur le temps d’exécution des scripts en ne les compilant qu’au besoin grâce au cache d’opcode (d’environ 50% selon les auteurs, sachant que cela dépendra de la complexité du script… on gagnera beaucoup plus sur des algorithmes récursifs, notamment), mais aussi sur le temps de processing de certaines ressources grâce au cache de données, qui est utilisé ici pour des requêtes SQL mais qui pourrait aussi bien l’être pour la lecture du fichier de configuration de votre application, par exemple (en stockant, au choix, un tableau associatif ou un objet $config), ou de n’importe quelle variable qui n’a pas vraiment besoin d’être mise à jour en temps réel.

Liens utiles

Manuel APC sur php.net (en français)

Utiliser XMLReader et SimpleXML de concert

Voici comment on procède:

Ligne 1, on instancie classiquement un objet XMLReader. Le constructeur ne prend pas de paramètres. Ligne 2, on assigne le fichier que l’on souhaite parser.
C’est ensuite que les joyeusetés commencent : $xml->read() permet de passer au node suivant. Tant que XMLReader trouvera des nodes, on continuera à lire le fichier séquentiellement. L’intérieur de la boucle contiendra le traitement que je souhaite effectuer sur chaque node. Ici, si le nodeType est “ELEMENT” si le localName (le libellé du tag) est “product”, nous sommes en présence de l’un des produits que je souhaite traiter.
Dans ce cas, $xml->expand() permet de copier le node courant afin de le manipuler plus aisément. L’astuce ligne 6 (j’imagine bien qu’il doit y avoir un moyen de faire ça beaucoup plus proprement) consiste à recréer le node à partir de son localName et de la chaîne de caractères au format XML qu’il contient, récupérée grâce à $xml->readInnerXML(). Etant habitué à l’utilisation courante de SimpleXML, et pour des raisons de confort personnel, je passe la chaîne de caractères obtenue en paramètre au constructeur de SimpleXMLElement afin de récupérer un élement XML classique, que j’utilise ensuite simplement en accédant aux données qu’il contient.

Vérifier le bon déroulement des opérations

Pour les imports de gros fichiers (1.2 giga-octets dans mon cas), mieux vaut savoir exactement ce qu’il se passe. J’ai donc déclaré avant mon while une variable $i=0, que j’incrémente à la fin de ma boucle, après avoir traité un produit. Ligne 2, je vérifie que $i (le nombre de produits traités) est un multiple de 500. Si oui, j’affiche le nombre courant et le flush() permet d’envoyer immédiatement le contenu du buffer à la sortie du script. Ici, le but était de faire tourner le script en ligne de commandes (CLI), mais cela aurait aussi bien marché avec un navigateur. (Il aurait fallu remplacer les \r\n par un <br /> classique.

Si cet article vous a intéressé, j’apprécierais un peu de promotion :

Pas clair ? Ok, un exemple :

Pas plus compliqué… Le * va capturer le sous-domaine et le passer au VirtualDocumentRoot. Donc pour test.domain.tld, on tombera dans /var/www/domain.tld/test/.

Dans le <VirtualHost>, après un VirtualDocumentRoot, on peut utiliser des directives comme d’habitude. (Je n’ai pas essayé d’y reprendre le %1, pour modifier les options de configuration de l’ensemble des dossiers “virtuels”… quelqu’un sait si ça marche ?)

(Note en réaction au commentaire de Laurentj :
Ce billet s’adresse à des développeurs web hébergés sur des serveurs en ayant un accès SSH, et ayant conscience des problématiques de gestion d’un serveur.
L’administration système, à fortiori sur une machine connectée 24/7, est un métier à part entière, qui requiert évidemment des compétences poussées ; ne pas savoir ce que l’on fait peut être lourd de conséquences.
Les commandes présentées ici sont très simples et ce post est plus destiné à servir de “pense-bête” que de véritable tutoriel.)
Il va falloir copier les scripts et les bases de données. En supposant que vous utilisez MySQL, voici la procédure à suivre.

Pour copier les scripts, on va compresser le DocumentRoot de chaque site dans une archive tarball (.tar.gz ou .tgz). On prendra le soin d’inclure à l’archive le dump de la base de données utilisée par le site. On n’aura ainsi qu’un seul fichier à envoyer et “installer” sur le serveur B. Ainsi, on est sûrs de ne rien oublier, et la compression diminue évidemment le temps qui sera nécessaire pour le transfert.

Vu qu’on ne travaille JAMAIS sur un site qui est -pour quelques minutes encore- en production (merci de noter ça en rouge dans vos petits cahiers), on commence par créer une copie de ce dossier dans ~/backup. Le ~ signifie “répertoire /home de l’utilisateur courant”. Pour ce faire :

Où -R signifie récursif: copier aussi les sous-répertoires.

Passons ensuite dans le répertoire de backup :

On réalise un dump (sauvegarde) de la base de données (attention, je parle bien ici d’une seule base, et pas du contenu complet du serveur…)

où :

• [utilisateur] est le nom d’un user SQL qui a les privilèges en lecture sur la base
• [nom_de_la_base] est la base qu’on souhaite copier
• [nom_du_fichier] est le nom du fichier dans lequel sera stocké le dump (choisir un fichier qui n’existe pas…)

Il vous sera demandé (grâce à l’option -p) d’entrer le mot de passe associé à ce compte-utilisateur.

Et c’est parti pour la création du tarball :

[nom_de_l_archive] étant le nom du fichier que vous voulez créer.
.. signifie “un répertoire plus haut dans l’arborescence”, donc dans le /home de l’user courant.

On peut vérifier que l’archive est bien formée et comprend bien les fichiers escomptés. Ca ne mange pas de pain et peut éviter de grosses crises d’hystérie quand on s’est raté quelque part. Listons donc le contenu de l’archive (pensez à remonter d’un cran dans l’arbo):

On peut ensuite copier par SCP l’archive sur le nouveau serveur (machine B):

• [nom_du_fichier] étant le nom du dump généré juste au-dessus
• [user] étant un utilisateur existant sur la machine B
• [hostname] étant un nom de domaine qui pointe vers B, ou son adresse IP

Le ~ (tilde) veut toujours dire “dans le répertoire /home” de l’utilisateur (mais sur le nouveau serveur, cette fois). Vous pouvez indiquer n’importe quel path pour lequel l’user spécifié à le droit d’écrire (pensez à bien inclure le premier slash)

On aurait pu faire le dump directement depuis le nouveau serveur, à condition qu’on puisse se connecter au serveur MySQL de l’ancien depuis le réseau (bind-adress *) mais le dump prendrait plus de temps. Donc autant le réaliser directement depuis la machine A et l’envoyer avec le reste du site.

On passe ensuite en SSH sur la machine B. La connexion à la machine A ne servira plus ; on la coupe (une larme d’émotion est permise pour les nostalgiques).
On décompresse notre archive magique :

On se connecte au serveur MySQL et on crée la base de données qui va recevoir le dump :

create database [nom_de_la_base]
On monte la base de données dans le serveur MySQL.

Où [dump] est le nom du dump qu’on a transféré et décompressé.

La base est prête ! (Pensez, si besoin, à recréer les utilisateurs MySQL qui auront les accès nécessaires sur cette base)
On crée alors le DocumentRoot du site, et on s’y rend pour y déplacer les fichiers décompressés :

C’est fait. Vous pouvez vérifier que tout fonctionne en modifiant votre fichier hosts sous Windows : Editez le avec Notepad et ajoutez la ligne “[nouvelle_ip] [www.domain.tld]“. Si vous utilisez Internet Explorer, fermez et rouvrez votre navigateur (pour que les modifications soient prises en compte) et allez voir votre site. Tout marche ? Il ne vous reste plus qu’à changer vos DNS… Migration de site accomplie !

Bien sur, en faisant comme cela, vous “perdrez” les données entre le moment où vous faites le dump et celui où les DNS basculent effectivement. Vous pouvez, une fois les DNS basculés, faire une extraction des données de la base “à la mano” (un différentiel qu’on appelle souvent un Delta…) mais c’est une autre histoire…