Bien sûr, veillez à mettre ce fichier à la racine de votre blog : www.monsite.fr/robots.txt

User-agent: *
# On empêche l'indexation des dossiers sensibles
Disallow: /cgi-bin
Disallow: /wp-admin
Disallow: /wp-includes
Disallow: /wp-content/plugins
Disallow: /wp-content/cache
Disallow: /wp-content/themes
Disallow: /trackback
Disallow: /feed
Disallow: /comments
Disallow: /category/*/*
Disallow: */trackback
Disallow: */feed
Disallow: */comments
Disallow: /*?*
Disallow: /*?
# On autorise l'indexation des images
Allow: /wp-content/uploads
User-agent: Googlebot
# On empêche l'indexation des fichiers sensibles
Disallow: /*.php$
Disallow: /*.js$
Disallow: /*.inc$
Disallow: /*.css$
Disallow: /*.gz$
Disallow: /*.swf$
Disallow: /*.wmv$
Disallow: /*.cgi$
Disallow: /*.xhtml$
# Autoriser Google Image
User-agent: Googlebot-Image
Disallow:
Allow: /*
# Autoriser Google AdSense
User-agent: Mediapartners-Google*
Disallow:
Allow: /*
# On indique au spider le lien vers notre sitemap
Sitemap: http://www.geekpress.fr/sitemap.xml

Source

AbriCoCotier.fr, 2012. | Permalien | Ajoutez un commentaire ! | Plugin Better Feed, par Ozh
Rangé dans : Wordpress

Or il y a environ 2 mois, Youssef m’a envoyé quelques chiffres sur l’avancement de sa boite, en me demandant ce que j’en pensais. Le problème, c’est qu’en regardant le concept, j’arrivais à y voir un beau site, bien fait bien construit, mais je ne parvenais pas à croire en l’aventure. Pas à cause de lui, donc, mais à cause du secteur dans lequel il s’est lancé. Je lui ai expliqué ça par mail, ce à quoi il m’a répondu en me montrant que la situation n’était pas aussi noire que je la voyais (j’ai tendance à être assez défaitiste, sachez-le ; au passage c’est plutôt encourageant quand je me montre enthousiasmé par un projet !), et que l’aventure commençait à démarrer.

Dans le but de l’aider, et dans l’idée de faire connaitre les chiffres qu’il m’a fournit, je lui ai proposé de publier tels quels les mails que nous nous sommes échangés. Il a accepté, les voici :

Premier mail de Youssef à moi :

Nous avons :

1. levée de 300k€
2. redesign du site
3. redesign du magazine web (HTML5, partageable sur réseaux sociaux…)
4. lancement de la version anglaise avec ventes dans tous les pays
5. et, surtout, nous avons lancé une marketplace de maquettes de magazines.

Le principe est simple. Nos utilisateurs peuvent désormais acheter sur Madmagz des maquettes réalisées par des graphistes tiers. Ces graphistes sont rémunérés sur les ventes. Grâce à cela, nous passons d’application Web à plate-forme Web avec un écosystème (cf. mon article de blog sur les enjeux).

Sinon, deux autres nouveautés majeures à lancer d’ici la fin d’année :

• Novembre : possibilité pour nos éditeurs de vendre leur magazine depuis la version online : on gère tout (paiement, fulfilment…), ils n’ont qu’à encaisser
• possibilité pour tous de créer un magazine pour l’iPad.

A ce mail, donc je ne répondais pas (ne sachant pas quoi répondre d’autre que ma vision complètement défaitiste), et Youssef m’a donc relancé. Bien lui en a pris. Voilà son deuxième mail :

Bonjour Louis,

Je ne crois pas avoir reçu ta réponse. En tous cas, grande nouveauté : il est désormais possible de vendre son magazine en ligne. Les lecteurs, depuis la version Web, pourront commander le PDF ou le papier. Nous gérons tout : encaissement, impression, envoi. L’éditeur n’a qu’à fixer ses marges et il est rémunéré pour chaque vente ! Voici un exemple réel du magazine d’un sommelier renommé.

Sinon, ce qui arrive sur Madmagz :

• en décembre, iPad
• en février au plus tard : la possibilité de rendre payante la version Web en ne montrant par exemple que les premières pages
• en mars au plus tard : des partenariats de diffusion avec des kiosques en ligne.

Pour ceux qui se demanderaient à quoi ressemble le magazine du sommelier renommé, j’ai été voir, et il faut reconnaitre que c’est très propre.

Le contenant est là, en quelque sorte, ne reste plus qu’à avoir du contenu.

Ce a quoi j’avais répondu (toujours aussi noir de ma part) :

Bonjour Youssef,

J’avais bien reçu ton mail, il était toujours dans ma boite de reception, en attente que je te fasse une réponse construite.

Je n’ai actuellement que mon iPhone mais je vais essayer d’être clair pour autant.

Je me pose actuellement pas mal de questions sur la façon de rentabiliser la création decontenu (pour mon blog, notamment). Ma conclusion pour le moment est qu’aujourd’hui, la création de contenu est gratuite, et en fait n’est qu’un résultat d’interactions sociales. En gros, j’écris un article pour obtenir de la considération, de la confiance de la part du public visé.

Du coup, se lancer sur le business de la creation de contenu n’est a mon avis pas une bonne chose.

Pour Madmagz, on peut dire que vous vendez un moyen de publication de contenus. Après tout, d’autres le font, comme WordPress.com. Et ils gagnent bien leur vie. Mais ça nécessite une énorme base de users car la marge est extrêmement faible. C’est à mon avis le plus gros problème de Magmagz. La base de users.

Ensuite, si on prend le problème à l’envers, avec la consommation de contenus, je vois de moins en moins de gens aller directement et regulièrement sur les blogs. Le nouveau business semble se faire du côté des magazines automatiques tels que Flipboard et surtout Zite. Mais même eux, je ne sais pas comment ils vont finir par gagner de l’argent.

Bref, pas de critique/conseil réel à te donner (d’où ma non réponse jusqu’alors), mais beaucoup d’interrogation sur l’avenir de ce business.

Bon courage,

Louis

Pas découragé pour autant, Youssef m’avait corrigé :

Bonjour Louis,

Merci de ton avis !

Il y a en effet ceux qui produisent du contenu (blogueurs… : disons éditeurs) et ceux qui permettent d’en produire (WordPress, nous, etc. : disons CMS). Aujourd’hui, il est très difficile de vivre de son blog, même avec plusieurs centaines de milliers de lecteurs. Adsense rapporte des clous et les CMS ne proposent pas de solutions.

C’est là où je pense que l’on est innovant : on apporte le CMS mais aussi (depuis jeudi !) la solution de monétisation. Les éditeurs peuvent adosser à leur webzine un kiosque qui permet aux lecteurs d’acheter en ligne la version PDF ou papier. Dans les prochains mois, l’éditeur pourra même rendre payant la lecture de son webzine en n’en découvrant que les premières pages. Voici :

• comment ça marche
• deux magazines qui le font, le dernier ayant déjà vendu (!) :
  • Au service du vin
  • Breizh riding.

D’après mes estimations, c’est au moins deux fois plus rémunérateur qu’Adsense.

Enfin, sur la question du volume, tu as raison. Mais note que ce n’est pas propre au business du contenu mais au business du Web : Paypal, eBay, Google, Facebook, etc. ne valent rien sans volume car le revenu par internaute (ARPU) est faible.

Si tu veux en savoir plus sur la solution du kiosque (ça peut t’intéresser en tant que blogueur pour des dossiers ou recycler des articles de fond), à ta disposition !

Puis j’ai demandé à Youssef s’il acceptait que je publie notre conversation. Il m’a demandé si je pouvais adjoindre à celle-ci le communiqué ou la prez qu’il a fait de son site. Cela me semble la moindre des choses, donc la voici.

Et comme je suis une buse et que je n’arrive pas à trouver le code embed de cette prez GoogleDocs, je vous mets une vidéo d’un interview de Youssef, où il explique le principe de Madmagz.

Edit : voilà l’embed de la prez :

AbriCoCotier.fr, 2011. | Permalien | Ajoutez un commentaire ! | Plugin Better Feed, par Ozh
Rangé dans : Madmagz, Wordpress

Il parait que « Un effort a été fait pour rendre WordPress plus rapide et plus léger ». Pour l’instant, ce n’est pas flagrant, mais je ne constate pas de ralentissement. Donc ça n’empire pas, ce qui est déjà bien.

Pour l’instant, en terme de bug, j’ai l’impression de ne plus avoir le plugin SimpleTags (en tout cas il ne semble plus fonctionner), mais sinon tout fonctionne comme avant pour moi. Au passage, je vous recommande mon billet sur la mise à jour de WordPress en ligne de commande.

La vidéo de présentation est ci-dessous :

AbriCoCotier.fr, 2011. | Permalien | 3 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Wordpress

J’ai commencé par copier les photos d’un domaine à un autre :

cp -R ancien-ndd/dossier/* blog/wp-content/uploads/ancien-ndd

Puis je suis allé dans mon MySQL, et j’ai remplacé les occurences de ancien-ndd/dossier/ par blog/wp-content/uploads/ancien-ndd. En fait, ces occurrences se trouvaient exclusivement dans des URL d’images ou de documents, donc pour le lecteur, ce changement d’url devrait, s’il est bien fait, être totalement transparent (Edit : maintenant ça doit bien faire deux semaines qu’il est fait, et personne ne s’est plaint, c’est donc que tout doit être correct)

UPDATE `wp_posts` SET `post_content` = Replace(`post_content`,’ancien-ndd/dossier’,'blog/wp-content/uploads/ancien-ndd’ ) WHERE `post_content` LIKE ‘%ancien-ndd/dossier%’

Bien sûr, le mieux c’est de faire un backup de la BDD avant de faire ce genre de manipulation, mais pour ma part, j’ai un backup qui est fait toutes les nuits, donc pas de problème à ce niveau.

Ensuite, j’ai besoin que toutes les photos non gérées directement par WordPress, aient une version « timbre », ce afin de bien gérer les photos dans les billets similaires affichés en bas de chaque billet.
Donc pour cela, il me faut un petit script, qui créé une copie des image et les convertisse directement en 150×150, avec une opération de renommage du style mon_image.jpg qui devienne mon_image-150×150.jpg (vous allez comprendre pourquoi dans la suite). Autant vous le dire tout de suite, pour l’instant je n’ai pas trouvé ce script. Par contre, j’ai trouvé TimThumb, qui redimmensionne (en PHP) a la volée les images. Et ça fonctionne plutôt pas mal. Je vous le recommande.

Remplacement de LinkWithin par SimilarPost

Comme je vous le disais plus haut, l’idée est de remplacer LinkWithin qui ne fonctionnait pas chez moi par un simili-LinkWithin. J’ai donc fait un tout petit peu de rétro-ingénierie (j’ai copié leur code HTML/CSS), et j’ai pu, en l’associant aux quelques fonctionnalités du plugin SimilarPost, créer un petit carrousel de billets similaires, avec chacun leur image (cf en bas de chaque billet de ce blog).

Il suffisait d’utiliser pour cela le pseudo-code que fournit le plugin SimilarPost, avec notamment les annotations comme {url} (qui donne l’url d’un billet jugé comme similaire au billet lu par le visiteur) ou {imageurl} :

Voilà le code. Dans les Output Settings du plugin SimilarPost, j’avais mis :

Case Output Template :

<a href="{url}" class="similarpostlinkblock" onmouseover="this.style.backgroundColor='#dde'" onmouseout="this.style.backgroundColor=''">
<div style="width: 156px; height: 215px; margin: 0; border: 0; padding: 0">
<div style="margin: 0; border: 1px solid #ddd;padding: 2px;width: auto;height: auto; ">
<div style="background: url({imagesrc:0:post:?t}) no-repeat; width: 150px; height: 150px; margin: 0; border: 0; padding: 0"></div>
</div>
<div class="similarpostlink">
{title:59:trim}
</div>
</div>
</a>

Text and codes before the list:

<h3>Vous serez peut-être intéressé :</h3><div style="margin: 0; border: 0; padding: 0px 0px 160px 70px;">

Text and codes after the list:

</div>

Le problème de cette solution, c’est qu’elle appelait à chaque fois les images 150×150 générées par WordPress lorsque vous uploadez une image au moment de créer un billet ou une page (via le {imagesrc:0:post:?t}). MAIS : moi j’avais plein d’anciennes images (celles provenant de mon CDN, ainsi qu’une grosse partie encore hébergée sur Flickr), et du coup celles-ci n’avaient pas de version 150×150 (et je n’avais pas trouvé de script pour les générer, comme je l’ai expliqué plus haut). D’où l’utilité du script les recréant en 150×150 (ce dont j’ai parlé plus haut).

La solution meilleure : TimThumb

Du coup, pour créer les images en 150×150, j’ai fini par trouver une script PHP qui les créée à la volée (ce qui n’est pas bien, car cela augmente le temps de chargement de la page). J’aurais préféré un script me les créant toutes d’un coup, et rajoutant -150×150 a la fin du nom du fichier, mais je ne crois pas que c’était trop possible… (ImageMagick saurait-il faire ça ? Si vous savez le faire, je suis preneur de la technique)

Donc revenons à TimThumb. Vous uploadez ce script sur votre serveur, vous créez un dossier de cache (ce qui est TRÈS bien : vous générez une fois l’image, et les fois suivantes, celle-ci est déjà créée !). Par contre, cela nécéssite d’apporter un petit changement au code d’appel de SimilarPost.

Ainsi, il faut remplacer

{imagesrc:0:post:?t}

par

wp-content/dossier_de_mon_script/timthumb.php?src={imagesrc:0:post:}&h=150&w=150&zc=1

Et ça fonctionne ! Je ne dis pas que je n’ai pas eu d’erreur PHP à cause de droits non accordé au script PHP (ça sent très fort la faille de sécurité d’ailleurs, mais osef )

AbriCoCotier.fr, 2011. | Permalien | 2 commentaires | Plugin Better Feed, par Ozh
Rangé dans : PHP, Tutoriels, Wordpress

Je rappelle avant toute chose qu’il est nécessaire de faire des backups (fichiers + BDD) AVANT ce genre d’opération, même si je n’ai de leçon à donner à personne sur ce genre de chose, n’étant pas moi-même parfait sur ce point.

Au passage, je rappelle également que la version « tout via l’interface web » est nettement plus rapide, et certainement plus sécurisée (dans le sens où on peut moins faire d’idiotie), mais cela nécéssite d’avoir un accès FTP d’ouvert sur sa machine, ce que je n’ai pas.

Pour le backup des fichiers (ci-dessous, une version gzippée) :

tar -zcvf chemin_sauvegarde/mon_blog.tar.gz chemin_vers_mon_blog/

Pour le backup de la BDD :

mysqldump -u UTILISATEUR -p MOTDEPASSE -d BASEDEDONNEES > fichier_de_backup.sql

Ensuite. Récupérez la dernière version de WordPress comme suit, décompressez-là, puis « nettoyez-la » :

mkdir tmp_wp

cd tmp_wp/

wget http://wordpress.org/latest.tar.gz ./

tar -xvf latest.tar.gz wordpress/

rm latest.tar.gz

cd wordpress/

rm -R wp-content/ 

rm wp-config-sample.php

cd chemin_vers_votre_site_sous_wordpress/

rm -R wp-admin/ wp-includes/

cp -R chemin_vers_votre_wordpress_tout_neuf/* chemin_vers_votre_site_sous_wordpress/

Puis rendez-vous à la page : monsiteweb.fr/update.php

Enfin, faites :

cd chemin_vers_votre_site_sous_wordpress/wp-admin/

rm wp-install.php

rm wp-update.php

Et voilà !

Notez que l’idéal serait de faire une tâche Cron qui chaque nuit récupère la dernière version de WordPress, et met à jour WP. Comme ça vous serez toujours à jour (à 24 heures près, grand maximum).

AbriCoCotier.fr, 2011. | Permalien | 3 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Tutoriels, Wordpress

Comparons Tumblr et WordPress :

Que représente Tumblr vis-àà-vis de WordPress ? Le fondateur de WordPress, Matt Mullenweg, déclarait la semaine dernière à TechCrunch que sa plateforme faisait environ 300 millions de visiteurs uniques par mois. Le service d’analyse du trafic de Quantcast laisse penser que ce chiffre est encore en deçà de la réalité puisqu’il estime que le nombre de visiteurs uniques par mois est de 500 millions.

Par ailleurs Quantcast estime que Tumblr génére 48,5 millions de visiteurs uniques par mois. Ceci fait que WordPress génère donc de 6 à 10 fois plus de visiteurs uniques que Tumblr. Dans le même ordre d’idée on peut comparer le nombre de blogs hébergés chez WordPress et Tumblr. Le premier dit en avoir 30 millions alors que Tumblr n’en déclare que 11 millions.

Mais qu’en est-il du nombre de pages vue ?

Quantcast estime que WordPress affiche quelques 1,4 milliard de page vues par mois. Tumblr lui en affiche près de 3 milliards ! En d’autres termes, si WordPress compte plus de visiteurs uniques et plus de bloggers, les visiteurs uniques de Tumblr visitent bien plus de pages que ceux de WordPress (presque deux fois plus). D’un autre côté, les analystes de Postrank notent que WordPress et Blogger.com sont les deux plateformes dont l’engagement dans les réseaux sociaux sont les plus poussés.

Tumblr vient de lever au total 40 millions de dolars, soit 10 de plus que WordPress lors de sa dernière levée, il y a 3 ans. au niveau des revenus de chacun de ces services, les estimations les donnent à peu près au même niveau, même si Tumblr reste encore plus petit.

Bien sûr, Tumblr connaît la concurrence (SquareSpace, Acquia et SixApart) mais aucun d’entre eux n’est aussi facile à utiliser que Tumblr.

Via RWW

AbriCoCotier.fr, 2010. | Permalien | 1 commentaire | Plugin Better Feed, par Ozh
Rangé dans : Tumblr, Wordpress

Du coup, quand la page sera demandée, seuls Nginx et Apache seront sollicités : PHP et MySQL resteront au repos.

JE ne suis pas du tout un DevConnect Member, mais j’aimais bien cette image

J’ai trouvé sur le web deux pages intéressantes que je souhaite partager ici à propos de la configuration MySQL :

• Une page très intéressante donnant notamment deux configuration recommandées pour un MySQL, en fonction de la quantité de RAM disponible.
• Sur le site de MySQL, cette page rentre davantage dans les détails de l’utilisation du cache des tables en fonction de l’utilisation qui est faite.

L’intérêt de Memcache

De surcroît, il m’a semblé voir -je ne sais plus où- que les SGBD mettaient en cache les tables utilisées. Par exemple, si vous faites un SELECT de la table 1, le SGBD la mettra en cache, puis vous en retournera le résultat. Ainsi, une fois qu’elle est en cache, je doute qu’un SELECT soit trop long à sortir, car à mon avis l’opération la plus longue sera la mise en cache du contenu de la table.

Et du coup, je ne vois pas trop l’intérêt de MEMCACHE. J’ai regardé sur Wikipédia, et il me semble que l’exemple de code qu’ils proposent rejoint tout à fait l’utilisation que l’on peut faire de Memcache sur AppEngine. Or, sur AppEngine, Memcache n’est autre qu’une copie en RAM d’une partie de la BDD, ou plus couramment un résultat d’une interrogation de celle-ci. Ainsi, il me semble que MEMCACHE a pour effet de mettre en cache le résultat d’une commande (et pas seulement la table), ce qui donc évidemment se révèle encore plus rapide (car en cache), mais je serais intéressé par voir un comparatif de gain de performances entre une configuration sans MEMCACHE, et une configuration avec. Je pense que l’intérêt de MEMCACHE dépend évidemment des opérations faites sur les tables (dans la mesure où sauvegarder un résultat est d’autant plus intéressant lorsque l’opération prend du temps, avec des grosses tables et des jointures nombreuses), mais je ne sais pas si l’intérêt est grand lorsque les tables sont toutes déjà en RAM, et donc que les jointures et tri sur ces tables doivent aller assez vite. Encore une fois, cela dépend aussi de la taille des tables : quand elles font 5Go, et que l’index est inexistant/pas à jour, je me doute bien que les opérations vont être plus longues que pour des tables de simplement quelques Mo. Ce que je dis peut sembler idiot, mais je me souviens que sur AppEngine, le panel d’administration m’affichait de gros panneaux rouges lorsque j’utilisais directement la mémoire pour afficher le contenu de tables faiblement remplies, ce notamment pour m’inciter à utiliser Memcache à la place. Or, si la table est faiblement remplie, je reste dubitatif sur l’intérêt de la chose…

AbriCoCotier.fr, 2010. | Permalien | Ajoutez un commentaire ! | Plugin Better Feed, par Ozh
Rangé dans : Wordpress

Il se trouve simplement que j’étais arrivé à la limite haute de la capacité de mémoire sur la partition où est stocké mon blog sur le serveur où il est, partition qui contient également les logs Nginx/Apache du serveur. Oui, je sais, c’est pas bien. Mais c’est le genre de détail qui est peu important avant qu’on ne se prenne le mur, d’autant que j’aurais parié que les logs ne prendraient pas plus de place que de raison, grâce à logrotate que je croyais fonctionnel (logrotate s’assure que le total des logs d’un dossier reste à un certain niveau de place en mémoire).

Donc j’étais arrivé à la limite de mon disque, soit… 4,7 Go (sur cette partition, hein, en fait j’en avais une à côté qui était vide et qui faisait… 80Go). En fait je ne savais pas du tout que les dossiers accessibles à la racine étaient chacun dans une partition compartimentée, donc je croyais bénéficier d’une taille de stockage totale/cumulée de 100Go, comme le prévoyais l’offre de serveur à laquelle j’ai souscrite.

Au passage, pour connaitre la répartition du stockage et sa charge, voilà la commande :

df -h

Ce qui donne chez moi (après avoir réglé le problème) :

$ df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/hda1             950M  343M  559M  38% /

varrun               1000M   72K 1000M   1% /var/run

varlock              1000M     0 1000M   0% /var/lock

udev                 1000M   36K 1000M   1% /dev

devshm               1000M     0 1000M   0% /dev/shm

/dev/hda5             4.7G  1.5G  3.2G  32% /mondossier3

/dev/hda6             4.7G  1.4G  3.4G  29% /mondossier2

/dev/hda7              81G  661M   81G   1% /mondossier1

none                 1000M     0 1000M   0% /tmp

Donc, pour revenir à nos moutons, le matin, pas de possibilité d’uploader correctement mes images.

Et à midi, le site qui ne répond plus.

En confiance après le redémarrage correct de la veille, je demande un redémarrage du serveur sur l’admin de 1and1, ce qui se passe correctement, mais de ce que je constatais à ce moment là, Nginx/Apache fonctionnaient, mais sur abricocotier.Fr, il n’y avait plus de connexion MySQL. A l’inverse, il semblait que microblog.abricocotier.fr ait une connexion MySQL… Donc j’ai d’abord pensé à un hack du site (des petits malins qui auraient été s’amuser avec le install.php de WordPress), ou auraient réussi à virer le config.php…

Le soir, en ayant ENFIN accès à un PuTTy, j’ai pu constater qu’il n’en était rien, et que le site avait l’air d’être intact, en tout cas en ce qui concernait les fichiers. Par contre, MySQL m’affichait l’erreur suivante :

Warning: session_write_close() [function.session-write-close]: write failed: No space left on device (28) in /usr/share/phpmyadmin/libraries/common.lib.php on line 648

Warning: session_write_close() [function.session-write-close]: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in /usr/share/phpmyadmin/libraries/common.lib.php on line 648

#0  PMA_sendHeaderLocation(http://localhost/phpmyadmin/index.php?lang=fr-utf-8&convcharset=iso-8859-1&collation_connection=utf8_unicode_ci&token=ec462f0246b8932e5b46ee9417dd491f) called at [/usr/share/phpmyadmin/libraries/auth/cookie.auth.lib.php:543]
#1  PMA_auth_set_user() called at [/usr/share/phpmyadmin/libraries/common.inc.php:758]
#2  require_once(/usr/share/phpmyadmin/libraries/common.inc.php) called at [/usr/share/phpmyadmin/index.php:34]

Fatal error: PMA_sendHeaderLocation called when headers are already sent! in /usr/share/phpmyadmin/libraries/common.lib.php on line 655

Après une recherche sur le forum Ubuntu-fr, j’ai pu constater qu’il pourrait s’agir d’un problème de taille disponible sur le disque… Ce qui m’a amené à supprimer mes logs Nginx, « pour voir »… Et quand j’ai vu que je supprimais 3Go de logs, j’ai compris qu’il y avait peut-être là quelque chose de louche.

Après avoir exécuté les commandes suivantes :

cd /mondossierdelog/nginx

rm *.gz

rm *.1

(rien qu’avec ces trois commandes, j’ai gagné 3Go)

MySQL ne voulait toujours pas fonctionner… Je me suis donc dis que c’était peut-être à cause du mauvais démarrage de celui-ci, et donc j’ai demandé (pour la troisième fois) un redémarrage du serveur.

Et là… c’état la quille ! Tout à refonctionné instantanément.

Bilan :

• Mettre les dossiers de ses sites sur la plus grosse des partition
• Mettre ses logs sur la plus grosse des partition et/ou s’assurer que logrotate fonctionne correctement !

AbriCoCotier.fr, 2010. | Permalien | Ajoutez un commentaire ! | Plugin Better Feed, par Ozh
Rangé dans : Programmation, Serveur, Wordpress

De la même façon, on peut apprendre sur Facebook que « Wikipédia et Drupal.org est actuellement en train de tester des versions de leurs sites sous HipHop ». On peut faire confiance à Facebook pour médiatiser le premier gros passage d’un site sous HipHop

Rappelons que HipHop est une technologie dont le but est de compiler le code PHP en bytecode via un portage C++. Et donc, par conséquent, d’accéléré de façon conséquente la génération des pages. D’après l’article toujours, le nombre d’abonné au fil d’informations/développements autour de HipHop a constamment augmenté, et des développements annexes autour de la technologie (c’est à dire ceux produits par des développeurs a priori bénévoles) ont commencés à sortir, avec par exemple un portage de HipHop pour 32 bit et un autre pour FreeBSD.

HipHop en remplacement de Apache

La chose qui me vient à l’esprit à la lecture de cet article est que Facebook pousse très férocement à l’adoption de ce nouveau serveur. Celui qui se verrait attaqué dans ses parts de marché serait Apache, qui est actuellement celui qui (dans sa configuration LAMP) fait sans doute tourner le plus de sites internet (en quantité). Donc au final, HipHop serait candidat pour remplacer le A de LAMP par un H.

Chose qui par contre m’étonne : il me semblait que WordPress.com fonctionnait sur Nginx (en tout cas c’est ce qu’on pouvait lire chez Pingdom), donc je ne suis pas sûr que WordPress.com observerait un réel gain s’ils passaient de Nginx à HipHop (car je pense qu’ils ont déjà beaucoup gagné en abandonnant Apache). Pour WordPress.com, le choix serait donc déjà fait : Apache a déjà été remplacé par Nginx (ce qui me fait penser que HipHop n’est pas seul en lice et avec de gros arguments pour remplacer Apache : Nginx est déjà là).

Pour aller plus loin (et pour tester par vous-même), je vous renvoie vers ce billet fournissant du code perméttant de réaliser quelques benchmark de HipHop sur son propre serveur : HipHop PHP Benchmark.

AbriCoCotier.fr, 2010. | Permalien | 4 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Apache, Facebook, PHP, Wordpress

Explication du fonctionnement :

Très rapidement, voilà comment fonctionne le script que j’ai écris : a chaque URL demandée par le client (quand celle-ci est après le path /viamemcached ou /viadatastore), le script va chercher le contenu HTML de la page directement mémoire. Dans MemCached si l’URL demandée commence par /viamemcached ou dans la mémoire (pour AppEngine, il s’agit du dataStore) quand l’URL commence par /viadatastore).

Le principe est donc, quand l’URL demandée commence par /viadatastore, de simuler une recréation de page, à cause de la requête à la base de donnée. Et de tenter de reproduire le fonctionnement d’un cache en passant par MemCached.

Code :

Fichier main.py :

Le fichier ci-dessous répartit les requètes en 3 : la page d’admin (création de contenu), derrière /upload, la catégorie des pages nécessitant la génération de contenu via appel au datastore (via l’url /viadatatore), et enfin la catégorie des pages nécessitant juste la requête à Memcached.

import cgi
import firstPage
import userpage
import wsgiref
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app

ROUTES = [
    ('/',firstPage.Home),
    ('/upload',userpage.Upload),
    ('/viadatastore/?([\w]*)/?', userpage.ContentUsage),
    ('/viamemcached/?([\w]*)/?', userpage.ContentCached),
 # other handlers here...
]

def main():
  application = webapp.WSGIApplication(ROUTES)
  wsgiref.handlers.CGIHandler().run(application)

if __name__ == "__main__":
  main()

Fichier firstpage.py :

Le fichier firstpage.py est « juste » le fichier de Home, répartissant entre les trois sections (au cas où vous voudriez reproduire l’application chez vous).

from google.appengine.ext import webapp

class Home(webapp.RequestHandler):
    def get(self):
        self.response.out.write("""<html>
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Test</title>
            </head>
            <body>
     <center>
        <h1>TEST</h1>
    </center>
    <br><br>
            <center><div style="text-align:left;margin:0% 30% 0% 30%;">
             <ul>
                <li>
                    <a href="/upload">Upload</a>
                </li>
                <li>
                    <a href="/viadatastore">viadatastore</a>
                </li>
                <li>
                    <a href="/viamemcached">viamemcached</a>
                </li>
             </ul>
             </div>
         </center>
     </body>
 </html>""")              

Fichier userpage.py :

Et enfin, le fichier userpage.py comprend les trois sections. Dans la classe Upload, on voit le formulaire d’envoi et le script d’enregistrement du contenu HTML dans le datastore. Dans la classe ContentUsage, on a la génération du contenu via DataStore, et dans ContentCached, celle via Memcached.

import cgi
import logging
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
from google.appengine.ext import db
from google.appengine.api import memcache

class pageUrlContent(db.Model):
    url = db.StringProperty(multiline=False)
    content = db.TextProperty()
    date = db.DateTimeProperty(auto_now_add=True)

def add_content_in_base(url,content):
    pageUrlContent = pageUrlContent()
    pageUrlContent.url = cgi.escape(url)
    pageUrlContent.content = db.Text(content)
    pageUrlContent.put()  

def render_list_previous_queries(url):
    listurls = pageUrlContent.all().filter("url =", url)
    return listurls

def fetch_content_in_base(url):
    final_content = ""
    contents = render_list_previous_queries(url)
    if contents:
        for cont in contents:
            final_content = cont.content
    return final_content

def fetch_content_in_cache(url):
    thiscontent = memcache.get(url)
    if thiscontent:
        return thiscontent
    else:
        content = fetch_content_in_base(url)
        if not memcache.set(url, content):
            logging.error("Memcache *set* failed in fetch_content_in_cache(url)>else>ifnot.")
        return content  

class Upload(webapp.RequestHandler):
    def get(self):
        self.response.out.write("""
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Content Upload</title>
</head>
<body>
<center>
<form action="/upload" enctype="multipart/form-data" method="post">
  <div><input type="text" name="url"></div>
  <div><textarea COLS=30 ROWS=30 name="content"></textarea></div>
  <div><input type="submit" value="Send IT"></div>
</form>
</center>
</body>
</html>
    """)
    def post(self):
        url = self.request.get("url")
        content = self.request.get("content")
        add_content_in_base(url,content)
        self.response.out.write("""<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Content Upload</title>
</head>
<body>
<center>
OK
</center>
</body>
</html>
    """)  

class ContentUsage(webapp.RequestHandler):
    # part of ImageHandler class
    def get(self,id):
        content = fetch_content_in_base(id)
        self.response.out.write(content)    

class ContentCached(webapp.RequestHandler):
    # part of ImageHandler class
    def get(self,id):
        content = fetch_content_in_cache(id)
        self.response.out.write(content)

Performances :

Les logs de AppEngine sont de ce type :

08-09 06:46AM 39.408 /viamemcached/loremipsum 200 22ms 19cpu_ms 7kb Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.22 Safari/534.3,gzip(gfe)
149.6.164.150 – - [09/Aug/2010:06:46:39 -0700] « GET /viamemcached/loremipsum HTTP/1.1″ 200 7725 – « Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.22 Safari/534.3,gzip(gfe) » « abricocotierfrtests.appspot.com » ms=23 cpu_ms=19 api_cpu_ms=0 cpm_usd=0.001455

D’après ce que j’ai compris, on peut extraire 4 valeurs : ms=23 cpu_ms=19 api_cpu_ms=0 cpm_usd=0.001455. Je n’ai pas bien compris à quoi correspondaient tous ces temps, mais ce dont je suis sûr, c’est que le api_cpu_ms correspond au temps de l’API du DataStore.

En effet, j’ai fait une vingtaine de tests (enfin 20 reload par catégorie), et je mes ai mis dans un tableau, puis j’en ai fait des graphiques :

Le tableau de données :

Millisecondes :

CPU Millisecondes :

API CPU Millisecondes :

CPU USD :

Conclusion

De ce que l’on peut constater, effectivement l’API_CPU_MS est à zéro après le premier appel sur Memcached, ce qui correspond bien à la premier mise en cache (lors du premier appel), puis c’est le cache qui prend le relais, et le datastore n’est plus appelé (et on remarque que les appels au datastore font tous 22ms). Pour le reste, c’est plus compliqué. Il semble que, sur le global, MemCached soit plus rapide (légèrement), mais ce n’est pas une règle absolue, et on voit que selon les appels, les temps varient, si bien que certains appels via DataStore se révèlent plus rapides que certains via MemCached.

D’une manière générale, Google imposant de respecter les quotas (ce que je trouve louable), cela impose à coder relativement « économiquement », c’est à dire avec l’idée qu’il faut utiliser Memcached aussi souvent que possible. Je rajoute que pour mon test, l’appel au DataStore était relativement simple, pas de SELECT *, ce qui peut expliquer la proximité des résultats avec MemCached. Cependant, je pense que dans un cas plus proche de la réalité, où la génération d’une page nécessite plusieurs appels au DataStore, la différence devient plus évidente.

Je n’ai pas non plus testé via l’utilisation de templates Django, mais je doute que celà accélère grand chose au traitement de la page, et donc encore une fois, cela devrait augmenter la différence entre une page donc l’intégralité du code se trouve en MemCached, et une autre pour laquelle il faut réaliser une certaine quantité d’opération de génération.

AbriCoCotier.fr, 2010. | Permalien | 1 commentaire | Plugin Better Feed, par Ozh
Rangé dans : AppEngine, Python (et Django), Wordpress