Week end en famille chez Wilson

Novembre 4th, 2005

Toujours en retard pour quand il s'agit de parler de mes weekends (désolé Papy).
Enfin, mieux vaut tard que jamais (j'adore ces expressions passe partout que l'on sort quand on sait pas quoi dire), nous avons décidé de partir en vadrouille dans le Victoria en famille (mon père et mon frère. Le premier étant là pour le boulot et le second pour dormir visiter la partie * Victoria * de l'Australie).
Famille sur la Great Ocean Road
Famille sur la Great Ocean Road

Après un quick week end entre les Dandenongs et la Great Ocean Road, c'est au tour de Wilson's promontory d'accueillir la visite de la famille Ledru.... Tous motivés, moi le premier. Impatient de visiter ce parc que j'avais prévu d'aller voir déjà l'an dernier avant que celui ne brule le mercredi juste avant mon départ le week end... Pas de chance...
Le parc est vraiment superbe. La partie qui a brulé (6000 hectares quand même) repousse à une vitesse folle... On ne dirait pas que 6 mois nous sépare de l'incendie. Certe beaucoup d'arbres sont carbonisés mais les branches repoussent et le sol est déjà recouvert d'herbes et de fleurs). J'avais déjà entendu que la nature australienne revient très vite après un feu (elle est même essentielle) mais ça fait plaisir de le constater soit même.
Retour de la végétation
Retour de la végétation

Le premier jour, on s'est fait la Sealers Cove, une bonne balade de 20 kilomètres prévue en 6/7 heures (4h30 pour nous) partant Mont Oberon à l'ouest de la presque ile pour arriver sur la place de Sealers Cove (Justement) du coté Est. Pas mal de lézards, quelques lapins, pas de kangourou, un bon gros serpent (mon deuxième en Australie)... Et surtout, ce qui fait la spécificité du parc, des changements de végétation tous les 200 mètres... Radicaux en plus ces changements.

Foret
Foret
Chemin dans le marais
Chemin dans le marais

La plage de Sealers cove est superbe ... Personne ... Juste pour nous trois. Un bonheur !!!
Plage de sealers cove
Plage de sealers cove

Le soir, barbequeue (BBQ) sur les bbq publics et dodo au camping de Tidal River ... Juste avant de s'endormir, on aura même la chance de voir un Wombat !!! Mon premier dans la nature !! Enfin !! :D

Lendemain matin, on s'est fait l'ascenssion du Mont Oberon. Un sacrès dénilevé avalé sans trop de problème même si les gens tireront pas mal les jours après. Entre les montagnes environnantes et la mer de tous les cotés, la vue en haut de ce Mont est superbe.

Végétation morte ...
Végétation morte ...
La récompence : Vue du sommet
La récompence : Vue du sommet

Un petit stop sur Picnic beach & Whiskey Beach (no comment) et on repart sur Melbourne la tête pleine de souvenir...

Au sujet du feu d'avril 2005, c'est un retour de feu non controlé après un incendie d'entretien... Les 600 touristes ont été obligés de dormir sur la plage vu que le feu bordait le camping et la ville. Ils ont merdé dans leur controle... Tellement que l'état du Victoria s'excuse pour le désastre (ils peuvent, le manque a gagner pour les environs se comptent en millions de $$$...)
Plus d'infos

A silly & boring PHP bug ...

November 3rd, 2005

This morning, I received a emails telling me that there is a big problem on a website that I host. Users are not able to upload any image on the server. (Warning: imagejpeg(): Unable to access 474/10434/59107.jpg in /www/libs/functions.php on line 226) Weird... The problem is in a daily used function which has been running for years. The only recent changed was the migration from v4.4.0 => v4.4.1 of PHP few days ago.
Because of the time difference, I only saw this problem when I woke up this morning. And fortunately, Julien has been able to find a temporary workaround... By disabling the safe mode... Dirty but it fixes the problem.

In the first place, I thought it was a change in the default configuration of PHP but I received a other email about the same kind of problems. Let's see the bug tracker of PHP... Ok, I am not the first one who has this issue.
http://bugs.php.net/bug.php?id=35060
http://bugs.php.net/bug.php?id=35071

One of the workaround that I found in this bug report is to make a touch() before calling the imagejpeg() function... Almost worster than the safe mode fix as I use it everywhere.
And I saw that Sniper is considering this as a feature (this is not a bug but a feature). Well, I don't see the point of touching a file before creating it after but well...
And people are complaining about this. Like this message :

Changing the way functions work within a minor update (version+=0.0.1) is an irresponsible way of maintaining software. This bug (please don't call it a "feature") caused a lot of trouble on our servers.

And I don't think that the way Sniper is any answering really help in the first bug report.
However, it seems that he considers this as a bug in the second bug report. The modification here shows it : http://cvs.php.net/php-src/ext/gd/php_gd.h (details here : http://cvs.php.net/diff.php/php-src/ext/gd/php_gd.h?r1=1.59.2.1&r2=1.59.2.2&ty=u).

Now, let's see if they are going to release a 4.4.1.1 version or we will stay with a safe_mode=off for a little while...

Edit : Comments closed. Thank you spammers.

Bug fixes admin & dev

November 2nd, 2005

Three small problems at work/personnal today.

  • I had to update the kernel of my boss's computer (running Ubuntu) in order to change an include.h into the GNU/Linux kernel (no more modification in the kernel). Then, I rebooted the computer but the data partition was not mounted. Getting stuff like :
    root@scully:/# mount /data/
    mount: /dev/hdb1 already mounted or /data busy
    Of course, hdb1 is not mounted and /data is not busy (fuser -v /data is your friend).

    After a few investigation, I found that evms is trying to access to the drive on boot and I guess it is not releasing the hard drive properly or something like that.
    Nov 02 17:07:28 scully _5_ Engine: is_volume_change_pending: Change pending: Volume /dev/evms/hdb1 needs to be activated.
    The dirty workaround is to launch evms AFTER the mount all options.
    mv /etc/rcS.d/S27evms /etc/rcS.d/S99evms

    Be carreful, this could cause side effects.

  • I had to debug an issue under the linux version of our softwares. Impossible to read big files (over 2 go).
    Then, I created a fake file of 3 go and made a small program to reproduce the issue.
    Here is the source :

    #include 
    
    void myRead(FILE * fichier){
    	/*lit le fichier caractere par caractere*/
    	char buf;
    	int ret=1;
    	
    	if (fichier!=NULL)
    		do
    			{        
    				ret=fread(&buf,sizeof(char),1,fichier);
    				printf("%c",buf);
    			}while(!feof(fichier));
    }
    
    int main () {
    	FILE *myFile = fopen( "bigfile","r" );
    	
    	if (myFile!=NULL) {
    		myRead(myFile);
    	}else{
    		printf("myFile not opened");
    	}
    
    	return 0;
    }
    

    Amazing, isn't it ?

    When I run this program (after tsize testsize.cpp), I only get a myFile not opened.
    Launching again this software with strace and I can see in the middle of the dump a :
    open("bigfile", O_RDONLY) = -1 EFBIG (File too large)

    After a few links, I finally found the solution :
    Add at the beginning of the source (before some includes) these three lines
    #define _FILE_OFFSET_BITS 64
    => defines which interface will be used by default
    #define _LARGEFILE64_SOURCE
    => permits the use of 64 bits functions
    #define _LARGEFILE_SOURCE
    => permits the use of fseeko() and ftello()
    Of course, it is possible to specify these define in the g++ command line like that : g++ -D_FILE_OFFSET_BITS=64 -o testsize testsize.cpp

    source

  • Sealers Cove - Wilson PromontoryLast but not least (I like this expression), an trick avoid stealer to make a direct link to one of your image on their website and wasting your bandwith. Personally, I don't care. I have plenty of bandwith and it represents a small part of the current traffic.
    However, I had to fix this problem for a website which offers legal mp3 & avi.
    The trick consists of using mod_rewrite. It checks the referent and if it is not from the official website and that it is trying to reach a file with a specific extension (mp3 and so on), we redirect the navigator to an other URL.

    Just put this few lines into your .htaccess and it should do it (if you have access to mod_rewrite for your website) :

    DirectoryIndex index.php
    RewriteEngine On
    
    # Rewrite Rules for files
    # if the referent is not empty
    RewriteCond %{HTTP_REFERER} !^$
    # if the domain is not our
    RewriteCond %{HTTP_REFERER} !^(.*)(domain.com|domain.com.au)(.*)$
    # if the extension if in the list 
    RewriteCond %{REQUEST_URI} \.(mp3|wmv|wma|zip|avi|mpg)$ [NC]
    # Redirect to an URL 
    RewriteRule ^(.*)$ http://sylvestre.ledru.info/ [L]
    

    Pretty simple isn't it ?

PS : why this image ? Well, this post is too technical... This picture has been taken last week end in Sealers Cove in Wilson 's Promontory in Victoria.

Edit : comments are closed. Thank you spammer.

Le 1 er novembre

Novembre 1st, 2005
Dessin de Jason Brooks
Dessin de Jason Brooks
Le premier novembre en Australie, à défaut d'être la fête des morts, est aussi une fête. En effet, chaque année a lieu la Melbourne Cup... Toute l'Australie est braquée sur cet évènement, tous les journaux en parlent, on en entend parler dans la rue, c'est tellement célèbre que toutes les sociétés s'arrêtent de travailler et parrier là dessus et dans l'état de Melbourne * Le Victoria *, c'est férié pour ce moment... Vous vous demandez ce qui peut être aussi important que celà ?
Hé bien, c'est une course de chevaux (ça calme hein). Toute l'Australie est vraiment fada de ce truc là. Tellement que tous les spectateurs s'habillent comme jamais pour aller voir une course de canaçon... Perso, j'ai vu la course rediffusé à l'aéroport où j'allais racompagner mon frère et mon père après dix * trop cours * jours.

Enfin, heureusement qu'ils ont des choses intéressantes et importantes ici ... Comme la chaine ABC qui est accusée de déshonorer les soldats de la premier guerre mondiale en ... oubliant d'obliger les présentateurs télé de porter les fameux poppies (coquelicot) le 11 novembre de l'année dernière sauf le présentateur économique (aucun lien).

L'importance de l'optimisation

Novembre 1st, 2005

La fréquentation... On l'espère sur chacun des sites que l'on lance. Une des contre partie est l'accroissement de ressources utilisées. J'avais pas réalisé comment un trafic très important peut impacter rapidement un serveur via un site mal optimisé.

Durant ces dernières semaines, j'en avais marre de voir le processeur de [i]mes[/i] serveurs de plus en plus utilisés par quelques sites. Prenant le kangourou par les oreilles, j'ai décidé de m'attaquer aux problèmes... Avec, en toute modestie, succès. Voila donc les deux cas réels que j'ai du traiter ces derniers temps :

* Le premier exemple est le passage à la dernière version (dawn - 0.9.1) de b2evolution.
Mon blog et le blog groupé (http://blog.jovialyteam.com) sont hébergés sur le même serveur. Ils se font spammer à une moyenne de 2/3 connexions HTTP à la seconde pour des fake referents vers des sites porno ou de médicaments de tout genre. Malgré les protections, les spammeurs trouvent toujours des contournements et leurs robots spammeurs se connectent toujours sur le site et entrainent le traitement PHP et SQL du site.
J'ai donc mis à jour b2evolution et l'impact sur les performances est phénoménal comme on peut le voir sur ce graphe :
Avant et après la maj de b2evolution
Avant et après la maj de b2evolution sur une semaine

(les piques sont normaux et causés par un autre programme).
On voit clairement l'impact... Impact qui se voit aussi sur la base de données en terme de requêtes SQL et donc en utilisation du serveur SQL.
Comme quoi, bien choisir son logiciel est important et malheureusement, il est très difficile d'évaluer ce critère dans le monde réel...

* Deuxième exemple. J'ai développé pour l'association australia-australie.com un système de carnet de voyage http://www.carnets.australia-australie.com/ sur l'Australie. A l'époque, je ne pensais pas que ça prendrait autant d'importance donc les questions de performance n'avaient pas été un point crutial dans le développement du site mais voila, c'est devenu un succès en terme d'utilisation et de fréquentation causant ainsi un ralentissement notable dans l'accès au site. J'ai donc regardé le code (que je ne touchais plus depuis quelques temps vu que je développe la nouvelle version ...) et je me suis rapidement aperçu que j'avais zappé de créer les index sur les clés secondaires (je sais, j'ai honte).
Par exemple, les commentaires sur les carnets fonctionnent en arbre et du à la version de MySQL à l'époque, je dois faire une requête par branche dans une fonction récursive. Autant dire quelque chose qui tire sur un carnet à forte fréquentation avec beaucoup de commentaires.
Je l'ai donc généré les index à tous les endroits nécessaires (enfin, tout ceux que j'ai vu) et la rapidité a été vraiment augmentée et l'utilisation processeur réduite par un facteur énorme... (J'ai l'impression de vendre une lessive en disant ça).
Evolution sur un mois avant et apres les index
Evolution sur un mois avant et apres les index

Moralité... utiliser les index de base de données...

Ceci dit, une chose que je déplore dans les applications web comme par exemple mediawiki, c'est la non ou pauvre utilisation des caches. Par cache, j'entend conserver une copie de la page web générée pour la reservir directement si le contenu n'a pas changé... Evitant ainsi tout le processus de génération classique (boucles, traitement, connexion sql...). Au contraire, ils refont tous le processus à chaque connexion sachant pertinemment que le ratio (nouvelle page devant être généré)/(page déjà généré) est toujours à considérer... L'utilisation d'un moteur de template comme smarty réglant ce genre de problème (j'avoue que c'est long, parfois complexe et prévu depuis le début ou dans une refonte mais on y gagne tellement ...). A la place, on préfère demander de nouveaux serveurs...