- Publié le 17 Janvier 2010 à 23:42
Après les déboires récents de mon premier serveur Dedibox, j'ai reçu courant décembre un mail m'annonçant la fin du support de ma Dedibox V1 fin janvier 2010 et l'obligation de migrer vers une autre machine. J'envisageais depuis un bon moment de changer de serveur, cela n'a fait que précipiter les choses. Et j'ai finalement choisi un serveur Kimsufi 750G qui semble mieux fourni que les Dedibox XL pour le même prix (aux frais d'installation près si on paie pas à l'année).
La migration à l'identique est quasiment terminée mais je compte bien exploiter au mieux les 4Go de RAM (quel changement en comparaison du Go que j'avais avant). Je vais m'intéresser de plus près à la configuration de MySQL pour exploiter ces nouvelles ressources et je vais enfin pouvoir installer l'extension eZ Find sur mes différents sites eZ Publish.
En attendant un rapide benchmark sur pwet.fr avec siege sur les 200 pages les plus vues m'a montré que cette machine est capable de servir quelque chose comme 40 pages / seconde sans broncher là ou l'ancienne machine était capable de servir péniblement 7 pages / secondes. Il y a de la place pour quelques nouveaux projets!
- Publié le 13 Septembre 2009 à 18:00
Après un peu plus de 2 ans et demi de bons et loyaux services (malgré quelques aléas ponctuels), il semble que ma première Dedibox ait quelques soucis. Samedi matin, elle a planté mais impossible de la faire redémarrer malgré l'utilisation du système de secours pour vérifier les trucs habituels (fsck très long, mauvais paramètrage du grub, ...). Bref, j'ai migré les sites sur mon second serveur, le temps que la propagation des DNS se fasse, et revoila Planet eZ Publish.fr, Bioutifoul Photos et pwet.fr à nouveau en ligne. Au passage, des backups fonctionnels, ça simplifie énormément les choses :-) J'envisage depuis un bon moment de prendre un serveur plus puissant type Dedibox XL ou Kimsufi 750G, au moins j'ai éprouvé la migration potentielle.
Pour revenir à cette Dedibox, j'ai refait une installation propre de Debian. Malgré l'absence totale de charge et un test matériel normal, elle a à nouveau planté ce matin. La messe est dite, RIP Dedipwet.
- Publié le 18 Août 2008 à 00:24
Notes aux grincheux de service : la manipulation exposée dans ce billet fonctionne évidemment ailleurs que sous Ubuntu (en fait partout où Apache2 est installable), néanmoins elle a été testée et mise en place sous Ubuntu et fonctionne telle quelle avec l'installation d'Apache2 par défaut sur cette distribution.
Après avoir appliqué la règle 3 en ajoutant et configurant l'entête Expires, passons à la règle 4 du Livre High Performances Web Sites (ou des recommandations de performances Yahoo!) en compressant avec gzip les données transmises par le serveur web, ici Apache2. Comme son nom le suggère, cette règle vise à limiter au maximum le poids des contenus distribués en réduisant de près de 70% la taille des fichiers textes. Cela permet d'accélérer le premier chargement du site avant la mise en cache par le navigateur. Pour cela, on peut configurer Apache2 pour utiliser le mod_deflate qui va se charger de compresser ce qui peut l'être pour un sur coût CPU faible.
La première étape consiste à activer ce module ainsi que le module headers avec a2enmod et à recharger Apache pour prendre en compte ce nouveau module :
$ sudo a2enmod deflate
$ sudo a2enmod headers
$ sudo /etc/init.d/apache2 reload
Le module headers est nécessaire pour envoyer des entêtes spécifiques aux proxy caches de manière à ne pas envoyer de documents compressés à certains navigateurs buggés mais populaires...
La configuration par défaut, stockée dans le fichier /etc/apache2/mods-available/deflate.conf, fait en sorte de compresser les fichiers texte brut, HTML et XML ce qui est déjà bien, mais on peut aller plus loin en traitant tout ce qui est texte. Il est en effet inutile de compresser les images (JPG, PNG, GIF, ...), les PDF et bien d'autres types de fichier qui sont déjà compressés par nature. J'utilise la configuration suivante dans /etc/apache2/conf.d/deflate pour compresser en plus les feuilles de style et les scripts Javascript tout évitant certains bugs connus de quelques navigateurs.
AddOutputFilterByType DEFLATE text/plain text/css application/x-javascript text/xml text/html
# gestion des navigateurs buggés
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# gestion des proxy caches
Header append Vary User-Agent
Pour faire prendre en compte cette configuration, il ne reste plus qu'à recharger Apache et le tour est joué.
- Publié le 12 Août 2008 à 21:55
Pascal Specht asks a good question in the eZ Publish forums : how to put a site under maintenance without breaking bookmarks and external links ?
The easiest way (the only ?) is probably to use mod_rewrite of Apache to distribute a maintenance page instead of the normal page. This can be done with those few lines in a .htaccess file :
RewriteEngine on
# RewriteCond %{REMOTE_ADDR} !^82.225.188.34$
RewriteRule (.*) /path/to/your/maintenance/file/index.htm [L]With this setting, Apache distributes the index.htm file for all request. You can also put your own IP address on the second line and uncomment it so that you can view the normal site for example to generate some caches in eZ Publish before putting your site online again.
