Comme je l’avais relaté durant un précédent billet, j’avais tenté il y a environ 1 mois d’utiliser CloudFlare… Sans succès. Mes erreurs avait été de mettre le système sur mon blog le « plus critique » (toutes proportions gardées), de me tromper de nom de domaine pour le changement des DNS (FAIL total de ce côté, j’ai honte), et enfin de le faire en journée. Pour le fait que je l’avais fait en journée, ce n’est qu’une demi-erreur, disons que cela aura exarcerbé mon impatience et ma peur de l’échec. L’erreur réellement fondamentale aura été de me tromper de DNS.

Pour autant, j’ai recommencé le processus, d’abord sur un domaine moins important, sans me tromper de DNS, ce qui m’a permis de m’entrainer pour le passage sur le domaine le plus important.

Une fois que j’ai eu bien rôdé le processus sur 3 domaines en tout (et croyez moi, ça prend plus de temps qu’on ne le crois, notamment pour vérifier que tout fonctionne bien, car la mise à jour des DNS n’est pas aussi simple que ce soit sur son lieu de travail ou sur sa box) ; j’ai décidé d’y aller sur mes domaines les plus importants.

Finalement, ça n’aura pas été si compliqué, et je peux dire aussi que à peu près tous mes sites sont sur CloudFlare. C’est pas plus mal.

Mais je reste quelqu’un d’incapable de faire quelque chose de correct la première fois. C’est pas grave en soit, ça permet de mieux me connaitre, et de prendre mes précautions : je sais que si je n’ai pas une simulation on-ne-peux-plus-réelle avant de m’attaquer à la prod, j’ai de grandes chances de me planter. C’est risible, critiquable, mais je ne suis pas sûr que beaucoup de gens soient beaucoup plus performants. Je constate que sur les différents lieux de travail que j’ai cotoyé, c’était souvent la technique adoptée. On avait d’ailleurs au moins un environnement de recette, voire davantage. Et ça ne prémunissait pas toujours (ou… pas souvent, en fait) contre les erreurs monumentales en prod. MAIS on avait l’idée qu’on avait au moins évité pas mal d’erreurs. Et en cela on gagnait du temps.

AbriCoCotier.fr, 2011. | Permalien | 6 commentaires | Plugin Better Feed, par Ozh
Rangé dans : CloudFlare, Serveur

Les gars de Pingdom pensent donc qu’ils pourraient revenir avec un serveur beaucoup moins conventionnel que le Xserve. Chez Apple, prendre tout le monde par surprise est une habitude, donc pourquoi pas pour le marché des serveurs ? Le potentiel est énorme, car c’est un marché où les unités se comptent en millions.

Plus précisément, Apple a mis plus d’un milliard de dollars dans la création d’un tout nouveau Data-Center, donc il n’est pas impossible qu’ils décident de faire profiter à leurs clients de l’expérience qu’ils auront acquis sur leur propre environnement. Qui sait ? Ils seraient capables d’avoir créé un serveur tout petit, puissant et relativement peu consommateur d’électricité, comme ce qu’ils sont parvenus à créer avec le Mac Mini ou le Macbook Air. Et ils pourraient avoir testé le tout sur des volumes relativement conséquents dans leur nouveau datacenter. Il pourrait y avoir là de quoi renouveler correctement une gamme devenue conventionnelle (les serveurs rack), et mise pour l’instant à l’écart de la gamme officielle sous prétexte que Apple veut conserver une gamme aussi simple et cohérente que possible (ce qui ne les empèche pas d’aligner côte-à-côte des Macbooks Air et des Macbooks Pro à des prix voisins alors que les premiers sont nettement plus intéressants que les seconds en matière de rapport qualité/prix). Donc on peut envisager d’ici quelques années un retour tonitruant.

AbriCoCotier.fr, 2010. | Permalien | 3 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Apple, Matériel, Serveur

La différence de Varnish est qu’il est un site statique par essence, et donc contrairement à Nginx, il n’est pas capable de passer par WSGI pour servir des pages non-générées. Nginx a également l’avantage de fonctionner avec une pile de connexion, et Varnish est donné comme fonctionnant avec un système de cache interne, mais je n’ai pas réussi à en voir plus dans les trois articles que j’ai lu. Les voici :

Apache, Varnish, nginx and lighttpd

Ce billet montre des comparatifs de performances, qui tendent à montrer dans des conditions assez correctes et objectives que Nginx et Varnish font jeu égal, avec un léger avantage pour Varnish.

Gérer son cache web avec Varnish

Chez HAute-Disponibilité, on peut en apprendre un peu plus sur le système de cache de Varnish, mais je ne m’y suis pas penché davantage.

Booster votre blog WordPress avec Varnish

Sur ce billet de Nicolargo, on peut comprendre comment fonctionne la configuration de Varnish. Ce billet m’a permit de faire le comparatif entre les configurations Nginx et Varnish que je vais présenter ci-dessous.

Comparatif des configurations

Pour bien comprendre la différence entre Nginx et Varnish (tous deux en frontend, sur le port 80, et servant le contenu non statique à Apache sur le port 127.0.0.1:8080), je vais copier-coller les deux configurations l’une à côté de l’autre et les expliquer.

Pour Nginx

Pour Nginx, on va avoir un seul fichier important. Ce sera celui relatif au site servi (donc le fichier de conf sera dans /etc/nginx/sites-available) :

server {
  listen      212.227.159.187:80;
  server_name monsite.fr;
  # On distribue les fichiers statiques directement
  location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|srt|swf)$ {
    gzip_static on;
    root  /var/www/htdocs/abricocotier.fr/;
    access_log  /var/log/nginx/monsite-server-access.log;
    error_log   /var/log/nginx/monsite-server-error.log;
    error_page 404 = /erreur-404;
    expires           30d;
  }

location / {
    proxy_pass    http://127.0.0.1:8080/;
    include /etc/nginx/conf.d/proxy.conf;
    #root   /lerepertoiredemonsite/;
    #index  index.html index.htm;
    }

}

Tout tient dans ce fichier.
On y voir que le premier bloc d’instructions vise à dire à Nginx de traiter tous les fichiers portant les extensions classiques pour des fichiers statiques.
Le deuxième bloc dit à Nginx d’envoyer toutes les requêtes qui restent (non-traitées jusque là) sur localhost:8080.

Pour Varnish

Grâce au billet de Nicolargo, j’ai pu rapidement m’installer une configuration Varnish très simplement en local. C’est pas plus compliqué que pour Nginx.

Dans le fichier /etc/varnish/default.vcl, on met le nom du site qui sera passé au serveur de backend (donc on prend un peu le problème à revers par rapport à Nginx) :

backend www {
.host = "monsite.fr";
.port = "8080";
}

Puis, à la suite, dans le même fichier, les instructions de traitement pour les requètes :

sub vcl_recv {
if (req.http.host ~ "(www\.monsite\.fr|monsite\.fr)") {
set req.backend = www;
} 

# Compatiblity with Apache log
remove req.http.X-Forwarded-For;
set    req.http.X-Forwarded-For = client.ip;
# Normalize Content-Encoding
if (req.http.Accept-Encoding) {
if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|lzma|tbz)(\?.*|)$") {
remove req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
remove req.http.Accept-Encoding;
}
}

# Remove cookies and query string for real static files
if (req.url ~ "^/[^?]+\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.*|)$") {
unset req.http.cookie;
set req.url = regsub(req.url, "\?.*$", "");
}
# Pas de cache pour les requêtes POST
if (req.request == "POST") {
return(pass);
}
# Pas de cache pour l'interface d'administration de WordPress
if( req.url ~ "^/wp-(login|admin)" || req.http.Cookie ~ "wordpress_logged_in_" ){
return(pass);
}
}

Comme on le vois, ce n’est pas beaucoup plus compliqué, c’est juste que le problème est pris dans l’ordre inverse. Je pense que c’est dû au fait que Varnish est fait pour faire du reverse proxy, contrairement à Nginx, qui n’a peut-être pas été conçu juste pour ça. Mais Nginx a l’énorme avantage de fonctionner avec une pile de requête, donc je me dis qu’il présente une sécurité pour qui n’a pas un gros serveur sous la main mais peu voir affluer à certaines heures de grosses quantités de connexions (et n’ayant pas envie de voir son serveur tomber toutes les 5 minutes).

Je rajoute que le mode de configuration de Nginx est sans doute plus simple pour ceux qui ont un peu regardé la configuration sous Apache (je pense notamment à l’arborescence sites-available/ et sites-enabled/ avec lien symbolique entre les deux pour « activer » un site), et c’est donc un facteur de plus grande facilité d’utilisation.

Enfin, et en terme de performances (c’est ça qui nous intéresse), je n’ai pas réussi à trouver de comparatif clair entre les performances des configurations Nginx+Apache et Varnish+Apache. Je constate que de très gros sites utilisent Nginx+Apache (par exemple, WordPress.com et toute sa plateforme de blogs), mais j’ai l’impression que Varnish n’anonce pas clairement qu’il existe comme le fait Nginx (c’est à dire que quand on a Varnish+Apache, le header de la réponse ne comporte que Apache, donc le client ne peut pas savoir que Varnish est dans la boucle).

D’après un collègue techniquement fort (ce qui m’inciterait à le croire), Apache serait mis souvent en frontend quand on a besoin d’un serveur d’application Java en backend (Tomcat, Weblogic, Websphere, etc), car Apache sans plugin est un serveur statique. J’ai du mal à trouver de quoi étayer cette thèse sur le web, Wikipédia ne mentionnant jamais dans la fiche Apache que celui-ci est un serveur statique quand il n’a pas de plugins (même si en soit, c’est vrai : Apache sans plugin ne peut pas faire beaucoup d’autre chose que de servir des fichiers statiques). La fiche anglophone dit seulement que Apache est fait pour pouvoir servir du contenu static et dynamique. Bref : je continue à penser qu’Apache est une formidable machine à tout faire, mais qu’il y a mieux quand on prend un besoin spécifique (cela dit, Google a plusieurs fois dit qu’il utilisait une version d’Apache modifiée pour ses serveurs, donc il semble difficile de dire qu’Apache n’est pas un serveur rapide).

Bref : si un jour j’ai deux serveurs sous la mains et n’étant pas en productions, je tenterais de faire un ApacheBenchmark des deux configurations, avec un site WordPress en backend, celui-ci ayant une base de donnée correcte, afin que cela simule des conditions réelles.

AbriCoCotier.fr, 2010. | Permalien | 12 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Apache, Nginx, Serveur

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

J’avais reçu hier soir un premier mail de Monitis, me signalant l’arrêt d’AbriCoCotier, mais j’avoue que je n’y ai pas prété attention, croyant que c’était un n-ième mail de publicité de Monitis. Fail de ma part. En voulant me connecter sur AbriCoCotier dans la soirée, j’ai finit par me rendre compte que le blog était down, et plus exactement le serveur tout entier.

Je me suis donc connecté sur l’interface 1and1 pour demander un allumage du serveur (l’interface 1and1 me signalant que le serveur était éteint, mais ça n’avait pas l’air de les gêner…), allumage du serveur qui me faisait assez peur, dans la mesure où je n’avais pas accès au SSH sur la connexion où j’étais au moment du rallumage (en gros j’étais sur le Wifi de Microsoft, et le SSH n’avait pas l’air de passer…). Pour autant, environ une minute après la demande de rallumage, le blog était de retour comme si de rien n’était.

Ce que je ne comprend pas, c’est comment le blog a pu passer d’un état « éteint » à un état « tout fonctionnel » alors que 1and1 n’a pas accès au serveur en lui-même (la dernière fois qu’ils ont voulu faire une intervention dessus, ils n’ont pas pu à cause du changement de port pour le SSH et du rootlogin à Off). Je dis ça parce que mon serveur fonctionne avec un Nginx et un Apache en même temps, et donc je ne sais pas comment le serveur a été rallumé, mais en tout cas tout s’est remis en place comme s’il ne s’était rien passé. Je me demande donc d’où a bien pu venir l’arrêt du serveur (je me dis que l’arrêt est venu potentiellement de 1and1 qui l’aurait « mis en veille »), dans la mesure où, s’il était tombé sous un gros bug, une faille ou un DDoS, je pense qu’il ne serait pas revenu dans son état initial tout seul.

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

Au passage, cela me permet de rajouter que sur ce créneau, Facebook (si la news se confirme), aura procédé de façon assez différente de Google, dont on dit qu’ils construiraient eux-même leur serveurs, mais à partir de matériel standard (ce afin de diminuer les coûts de matériel). Facebook aura donc été plus loin, en allant chercher une solution plutôt neuve dans le domaine (certains diront « risquée »), et pas forcément des moins chères : les serveurs sur ARM n’étant pas actuellement devenus des standards, je doute que les coûts d’échelle aient déjà pu être réduits dans des proportions significatives…

Un autre point auquel je n’avais pas pensé également, mais qui pourrait être amené à avoir son importance : celui du « green aspect » des services web. On a vu déjà que Google avait investit dans des entreprises vertes (fournissant des éoliennes), ou menait des recherches pour obtenir des datacenter refroidis à l’eau de mer. Facebook pourrait donc élargir la course menée contre Google sur le domaine du « service le plus vert », ce qui ne serait pas plus mal (quoi que, ne nous leuront pas : toute baisse de consommation d’énergie se répercute sur une baisse de la facture pour le fournisseur : l’écologie est donc d’abord une réalité économique). On peut aussi étendre cette idée à l’hebergement de services : Facebook, avec ses applications, deviendrait une infrastructure plus verte que Google AppEngine (je m’aventure à faire une comparaison entre ces deux infrastructures d’hébergement d’applications, mais je n’ai jamais développé sur Facebook, n’hésitez donc pas à me corriger si vous voyez une ânerie dans mes propos).

Dernière chose à laquelle cela me fait penser : je me doute que Intel et AMD ne vont pas se laisser faire aussi rapidement. Je vois deux options : soient ils sortent un concurrent de ARM très rapidement (peut-être les Atoms d’Intel ? Mais quid du coté de AMD ?) et font pression sur les constructeurs/gros clients pour qu’ils « restent dans le giron » (mais ça n’a pas du fonctionner avec Facebook), soient ils se mettent à l’architecture ARM au plus vite. Mais je n’ai pas ouï de news de ce côté là…

La vidéo dont est tirée la photo ci-dessus, qui contient pas mal d’infos croustillantes sur les datacenters de Facebook :

AbriCoCotier.fr, 2010. | Permalien | 3 commentaires | Plugin Better Feed, par Ozh
Rangé dans : ARM, Facebook, Intel, Serveur

Le rapport entre le billet et l’image ? Y’en a pas (à part l’idée de vitesse et de lumière). Cela dit, j’aimais bien ce fond d’écran, il est téléchargeable là.

Je me suis donc repenché sur le sujet après être tombé sur un billet traitant du sujet, et voilà quelques améliorations que j’ai vues possibles sur ce blog. J’ai découpé mes tests en trois, étalant la taille des fichiers (d’une centaine d’octets à plusieurs dizaines de Ko), afin de voir à partir de quelle limite de taille l’utilisation de Base64 n’est plus justifiée.

Premier test

Mon image de fond, disponible a cette adresse, me coûte 138 octets en PNG.

En la passant en Base64 (avec ce site), j’obtiens la chaine de caractère suivante :

data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAA+gAAAABAgMAAAAwbmygAAAAB
GdBTUEAALGPC/xhBQAAAAlwSFlzAAASdAAAEnQB3mYfeAAAAAxQ
TFRFAAAA1tjD3N3K////dy6oVgAAABRJREFUCB1j+D8ogWgouSBoFbE
AAAa9w/mxw3JEAAAAAElFTkSuQmCC

Or, cette chaîne de caractère, une fois mise dans la feuille CSS, ne prend que 207 octets, soit donc un peu mois de deux fois plus. L’avantage du CSS, c’est qu’on peut le gzipper. Et une fois gzippée, cette chaîne de caractère prend… 201 octets, ce qui n’est pas fantastique, bien sûr, mais je suis prêt à parier que le temps de téléchargement supplémentaire des 201-138=63 octets est négligeable par rapport à celui de l’établissement d’une nouvelle connexion. En effet, sur des fichiers envoyés par Nginx, je remarque souvent un temps d’attente+connexion de 30 ms ( ce qui est déjà pas mal, et je pense que vous aurez du mal à trouver un temps inférieur sur le net). Or, à un taux de téléchargement de 50ko/s (taux finalement assez faible par rapport aux connexions moyennes que j’ai), le téléchargement de 63 octets représente : 1,2ms de téléchargement supplémentaire (règle de 3 : (63*1000)/(50*1024) = 1,2). Une broutille, comparé aux 30ms de temps de connexion occasionné par un requète supplémentaire !

En conclusion : pour ce fichier, le Base64 multiplie par un facteur de 30 (au minimum) le chargement de cette ressource.

Deuxième test

Avec une image un peu plus importante, celle d’un icone pointant vers le compte Twitter d’AbriCoCotier.

• En JPG, elle fait 9216 octets.
• En Base64 non-gzippée : 12311 octets.
• En Base64 gzippée : 9340 octets (soit donc 9340-9216=124 octets de plus). Or, à un taux de téléchargement de 50ko/s, le téléchargement de 124 octets représente : 2,4ms de téléchargement supplémentaire (règle de 3 : (124*1000)/(50*1024) = 2,4).

Donc là aussi, le pourcentage d’octets en plus après encodage Base64+ gzip reste bien inférieur (là avec un facteur de 15) à ce qu’aurait occasionné le téléchargement d’une autre ressource.

Troisième test

Avec le header de la page, qui est sans aucun doute l’image la plus lourde de la page.

• En JPG, elle fait 34241 octets (je ne donne que les comptes en octets, dans la mesure où Linux me fournit des Kio et non des Ko, donc je préfère éviter toute confusion).
• En base64 non gzippée, 45682 octets.
• En Base64 gzippée, 34242 octets.

Pour ce fichier, en Base64 gzippée, on arrive à une taille inférieure à celle du JPG (ou quasi égale, à un octet près), tout en économisant en plus le temps de connexion supplémentaire ! Donc c’est directement le temps de téléchargement final de la page qui est amélioré. Surtout, je crois que le plus important est de noter que la taille de l’image étant assez importante, le gzip semble (progressivement) plus efficace pour encoder le contenu de l’image que l’encodage JPG lui-même ! C’est donc de très bonne augure pour les reste des grosses images à charger.

Bilan

J’ai l’impression que quelque soit la taille des fichiers, on est gagnant avec Base64 :

• soit les fichiers sont petits, auquel cas la taille Base64+gzip est légèrement supérieure à celle d’origine, mais cette taille supérieure permet d’économiser quand même beaucoup plus de temps de téléchargement qu’on en aurait perdu en allant chercher une ressource supplémentaire ;
• soit les fichiers sont très gros, auquel cas la taille Base64+gzip parvient à être encore plus faible que la taille d’origine !

Malgré tout, je ne recommande pas forcément l’utilisation de cette technique. Son gros point faible reste de ne pas être interprétée par IE6 et IE7, qui peuvent, selon les sites, représenter une part importante du trafic. Pour AbriCoCotier.fr, le trafic venant des Internet Explorer toute version confondue est de 30,90%, dont 67,98% d’IE8 (qui interprète correctement le Base64). Je considère que les autres versions ne supportent pas le Base64. Sur le total des visiteurs, j’en ai donc 0,3090*(1-0,6798)=0,0989 soit donc en gros 10% qui ne pourront pas voir ces images. Je considère que c’est trop élevé, mais je suis sûr que d’autres sites ont des statistiques à ce niveau qui sont bien plus flatteuses, et donc qui leur permettent de faire ce pas en avant.

Edit : J’ai fait un outil en ligne pour encoder vos images en Base64, ce qui vous permettra de comparer directement si l’original est plus lourd que le Base64 gzippé.

AbriCoCotier.fr, 2010. | Permalien | 10 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Serveur, Wordpress

Ces poids lourds, qui sont-ils ?

• Il y a d’abord Google, avec AppEngine,
• mais également Microsoft avec Azure,
• et enfin (peut-être le plus connu) Amazon avec les Amazon Web Services.

Notons de surcroît que les hébergeurs plus « classiques » commencent à se lancer sur le secteurs, avec notamment :

• 1and1 qui propose ses serveurs « Cloud Dynamique »,
• GoDaddy avec ses Cloud Servers powered by MacOS X (je ne sais pas du tout ce que ça vaut),
• OVH avec son miniCloud, ou
• Gandi avec son système de parts.

Tout ça pour dire que la tendance aux serveurs « dynamiques » semble être une tendance de fond et pas simplement une mode. Elle permet notamment une flexibilité dans les ressources, tout en allant progressivement vers des performances aussi bonnes que celles d’un serveur physique.  Certains, comme Google avec AppEngine, cachent complètement le souci des ressources ou de leur quantité, et ne fait payer qu’à la quantité de calculs pour le processeur, à la quantité de bande passante consommée, à la quantité de mémoire, etc. On ne paye que ce que l’on consomme. Dans un sens, c’est sympathique : on ne se préoccupe pas de la qualité du processeur et on se concentre sur la qualité de l’application ; par contre, point de mot à dire sur le type de serveur utilisé et les temps de réponses moyens. Je lisais d’ailleurs un billet récemment sur Google AppEngine (et bien sûr, je ne parviens pas à le retrouver) d’une personne déçue par le service, car elle s’était rendue compte que Google lui mettait son application en sommeil dès que celle-ci n’était plus visitée pendant une certaine durée, et que l’utilisateur suivant avait un temps de réponse un peu supérieur (le temps de « réveiller » l’application). Cette virtualisation des ressources a donc ses avantages et ses inconvénients.

Pour autant, j’ai tendance à penser qu’elle finira par prendre le pas sur les architectures physiques telles les dédibox v3 ou les Kimsufi 250G. En effet : les offres Cloud sont déjà parmi celles qui sont louées aux prix les plus bas, donc les serveurs dédiés ne pourront pas longtemps rester en compétition avec eux. Ensuite, le Cloud offre l’avantage pour l’hébergeur de pouvoir rassembler plusieurs offres qu’il avait avant : les serveurs privés virtuels sont en fait à peu de chose près des offres Cloud, les hébergement mutualisés en sont aussi, et les serveurs dédiés dont le stockage est délocalisés peuvent également être considérés comme tels. Finalement, seuls les besoins « professionnels » et très spécifiques vont encore avoir besoin de serveurs « nominatifs » (par exemple pour les entreprises ayant besoin de réaliser un audit de sécurité sur l’accès physique au serveur), et donc il est possible que ce type d’offre devienne progressivement marginal.

Au passage, les hébergeurs classiques risquent d’avoir très mal le jour où Google supportera le PHP et MySQL (s’il les supportent un jour), car son mode de paiement à la consommation risque de séduire une partie importante des sites web hébergés…

Je rajoute que, malgré les récentes offres proposées par les hébergeurs (les « offres à 15 euros pour des serveurs mini »), je ne vois pas de possibilité de vérifier si le serveur est effectivement virtualisé ou non, dans la mesure où tous les niveaux réseaux et processeurs peuvent être gérés/virtualisés…

Edit : Merci à Thomas pour la relecture.

AbriCoCotier.fr, 2010. | Permalien | 5 commentaires | Plugin Better Feed, par Ozh
Rangé dans : 1and1, Amazon, AppEngine, ARM, Google, Intel, OVH, Serveur

Après quelques vérifications, j’ai vu qu’effectivement, même si la configuration de mon Nginx indiquait qu’il fallait fournir le contenu en gzip, cette étape ne fonctionnait pas. J’ai fait d’autres recherches, qui m’ont permit de conclure que j’avais oublié d’inclure l’option gzip lors de la compilation de Nginx (oui parce que je l’ai compilé moi-même : la version proposée par mon OS étant à mon goût trop vieille – car désormais non supportée par Nginx…). Bref : a la compilation, j’ai oublié l’étape permettant à Nginx de prendre les fichiers, et de les convertir en gzip.

Cela dit, une bonne chose est que la version que j’ai installé permet, si on met dans la configuration d’un site la ligne :

gzip_static on;

…de vérifier à chaque envoi s’il existe une version gzippée du fichier, et si oui, de l’envoyer à la place du fichier demandé.

Sauf que : il me fallait désormais prendre les différents fichiers textes non gzippés. J’ai un instant crû qu’un tar -czvf suffirait, mais je me suis retrouvé avec des headers pas bons. En utilisant la commande gzip, j’ai obtenu des résultats bien meilleurs. Du coup, j’ai pris quelques minutes pour créer un script convertissant en gzip tous les fichiers CSS et JavaScript d’un dossier et de ses sous-dossiers :

#!/bin/bash

#User Variables

DIR1=/var/www/monsite1/;
DIR2=/var/www/monsite2/;

FIND=find;
GZIP=/bin/gzip;

for d in "$DIR1 $DIR2"
do
    for i in `$FIND $d -name "*.css" -o -name "*.js"`;
    do
                $GZIP -c $i > $i.gz;
    done;
done;

Notez plusieurs choses dans ce script :

On trouve l’intégralité des fichiers avec extension css ou js via la commande find :

find path/ -name "*.css" -o -name "*.js"

On les convertit en laissant l’original via la commande gzip customisée :

gzip -c style.css > style.css.gz

Voilà ! Normalement, cette technique permettra d’économiser encore un peu de bande passante. Après, mettez ce script dans une tâche CRON pour qu’elle s’exécute assez régulièrement (au cas où vous mettriez à jour des fichiers CSS). Et enfin, en ce qui concerne la compatibilité avec les différents navigateurs, j’ai testé sous Chrome 4, Firefox 4, Opera 10.50 et IE7 (out ça sur Windows XP), et ça fonctionnait sans problème. J’ai bien conscience que peut-être, il y a encore des personnes sous IE5 ou IE6, mais elles commencent sérieusement à m’énerver. Donc je ne vérifie pas pour ces configurations. POINT.

Edit : Pour ceux qui viendraient me dire qu’il y a toujours le mod_deflate de Apache, je leur répondrais que je suis au courant, mais que chez moi Apache ne traite pas les CSS et les JS, donc cette solution n’était pas envisageable ici.

AbriCoCotier.fr, 2010. | Permalien | 1 commentaire | Plugin Better Feed, par Ozh
Rangé dans : Nginx, Programmation, Serveur

Or, comme chacun sait, au fur et à mesure de l’utilisation de tel ou tel CMS (ex : WordPress, Dotclear, Joomla, etc), CRM (VtigerCRM) ou autre logiciel installé sur un serveur, on finit par rajouter des personnalisations ici et là, et bien sûr on ne se souvient jamais de l’intégralité de ce que l’on a fait.

Pour ma part, j’ai donc choisi de sauvegarder l’intégralité du dossier /var/www, même si c’est assez lourd en terme d’espace disque. A cela, j’ai ajouté les fichiers de configuration de chaque serveur fonctionnant sur le serveur (pour moi, Apache et Nginx).

Le script shell suivant fait en fait d’abord une copie des dossiers/fichiers à sauvegarder dans un répertoire temporaire (qu’il aura créé juste avant), puis les mets dans une archive gzipée. J’attire votre attention sur le fait que chez moi, avec un dossier /var/www de 740Mo (c’est pas tant que ça), le script a fait tourner le CPU à 100% pendant environ 8 minutes. Pendant ce temps là, les pages ont très bien été servies (j’ai fait le test), et d’après ce que je voyais sur htop, il y avait une gestion des processus permettant à Apache et Nginx de fonctionner correctement, laissant au script le reste du CPU disponible. Toutefois, les quelques observations que je note ici sont à prendre avec des pincettes, elles ne sont le fruit d’aucune étude sérieuse, c’est pourquoi je recommande de n’exécuter le script qu’au milieu de la nuit (entre 3h00 et 6h00), pour avoir un impact éventuel sur les performances aussi limité que possible. De même, il faut bien voir que la quantité de fichiers associés peut être assez importante, et la taille de l’archive également, donc si vous n’avez pas beaucoup d’espace disque sur votre serveur, évitez de multiplier les backups (pour ma part, je pense qu’une à deux fois par semaine me suffiront amplement).

Voilà le script shell :

#!/bin/bash

#User Variables
DATE=/bin/date;
NOW=`$DATE '+%Y-%m'-%d_04_30`;
NBBACKUP=4;
BACKUPDIR=/home/the_user/filesbackup;
BACKUPTEMPDIR=/home/the_user/filesbackup/tmp;

APACHECONFDIR=/etc/apache2;
NGINXCONFDIR=/etc/nginx;
WWWDIR=/var/www;

#Command Variables
RM=/bin/rm;
CP=/bin/cp;
MKDIR=/bin/mkdir;
MV=/bin/mv;
TAR=/bin/tar;
SCP=/bin/scp

$MKDIR $BACKUPTEMPDIR;
$CP -R $APACHECONFDIR $BACKUPTEMPDIR;
$CP -R $NGINXCONFDIR $BACKUPTEMPDIR;
$CP -R $WWWDIR $BACKUPTEMPDIR;
$TAR -czf $BACKUPDIR/files_backup.$NOW.0.tgz $BACKUPTEMPDIR/;
$RM -R $BACKUPTEMPDIR/

#$SCP -P 50000 $BACKUPDIR/*0.tgz user@ndd.com:/chemin

i=$(($NBBACKUP-1))
j=$NBBACKUP
$RM -f $BACKUPDIR/*$NBBACKUP.tgz
while [ $i -ge 0 ];
do
     for f in $BACKUPDIR/*.$i.tgz;
     do
         $MV $f ${f/.$i.tgz/.$j.tgz};
     done
     j=$(($j-1))
     i=$(($i-1))
done

Veuillez noter que celui-ci n’est pas optimisé pour le listing des opérations à réaliser. J’ai tenté le for i in chemin_1 chemin_2, mais l’interpréteur shell n’a pas voulu dans la mesure où il considérait les chemin comme des dossiers, et ne voulait apparemment pas boucler dessus.

Vers la fin, vous pourrez voir une ligne commentée, celle pour la commande scp, qui nécessite que vous ayez un serveur supplémentaire sous la main (ou un hébergement web) qui accepte les connexions scp.

Pour ce qui est de la sauvegarde d’un nombre défini de backups, je remercie Tym, c’est lui qui a donné la solution.

AbriCoCotier.fr, 2010. | Permalien | 6 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Nginx, Programmation, Serveur, Wordpress