Dans le cadre de mon projet, l'objectif était de traiter plusieurs gigas octets de logs dans les meilleurs délais pour cela je décide d'implémenter la technique des memoryMappedFile. Cette technique d'accès aux fichiers est très performante, le principe est de mapper, par des appels à l'API système, la zone de données de l'application sur le disque dur de la même façon que le fait Windows avec sa mémoire virtuelle (swap disk). Bien que le disque soit d'une lenteur incomparable à celle de la mémoire vide, le gain de temps se fait sur l'allocation mémoire et le chargement des données ce qui donne des performances excellentes. Le gain de temps obtenu est de l'ordre de trois et n'est pas sensible à la taille du fichier traité (problématique du swap en cas de chargement en mémoire).\\

Sur un fichier de 70Mo, sous Windows, le temps de traitement ne dépasse pas 12 secondes (à la première exécution, car un cache accélere grandement les choses par la suite) et atteint 30 secondes par la méthode classique. Sous AIX, le rapport entre les deux méthodes est très proche car je n'ai pas observé de variation entre deux exécutions. A noter, que bien que la machine AIX utilisée pour mes tests date d'environ six ans, les temps de traitement mesurés étaient deux fois meilleurs que ceux obtenus sous Windows ce qui semble montrer l'extrême importance des performances des disques (une baie de stockage connectée en fiber channel pour AIX et un disque IDE pour Windows).\\

Sur un fichier de 70Mo, sous Windows, le temps de traitement ne dépasse pas 12 secondes (à la permière exécution, car un cache accélere grandement les choses par la suite) et atteint 30 secondes par la méthode classique. Sous AIX, le rapport entre les deux méthodes est le même et je n'ai pas observé de variation entre deux exécutions. A noter, que bien que la machine AIX utilisée pour mes tests date d'environ six ans, les temps de traitement mesurés étaient deux fois meilleurs que ceux obtenus sous Windows ce qui semble montrer l'extrême importance des performances des disques (une baie de stockage pour AIX et un disque IDE pour Windows).\\

Dans le cadre de mon projet, l'objectif était de traiter plus de un giga octets de logs dans des temps très courts. Je décide d'implémenter la technique des memoryMappedFile. Cette technique d'accès aux fichiers est très performante, le principe est de mapper, par des appels à l'API système, la zone de données de l'application directement sur le disque dur de la même façon que le fait Windows avec sa mémoire virtuelle (swap disk). Bien que le disque soit d'une lenteur incomparable à celle de la mémoire vide, le gain de temps se fait sur l'allocation mémoire et le chargement des données ce qui donne des performances excellentes, le gain de temps obtenu est de l'ordre de trois et n'est pas sensible à la taille du fichier traité (problématique du swap en cas de chargement en mémoire).\\
Il restait à résoudre la problématique de la portabilité de mon code source, je n'eu pas loin à chercher car dans la partie iostreams des librairie boost se trouve une libairie d'abstraction prête à l'emploit (http://www.boost.org/libs/iostreams/doc/index.html).

Pour vous donner une meilleur idée des performances du couple mmap/regex, vous trouverez ci-dessous un court exemple :

Le moteur d'[[http://www.boost.org/libs/regex/doc/index.html|expressions régulières]] de Boost est très performant et de plus compilable sous différentes plateformes (dans mon cas AIX et Windows). Après quelques tests de validation, les performances étant au rendez-vous le choix d'utiliser cette librairie fût arrêté.\\
\\
Dans le cadre de mon projet, l'objectif était de traiter plus de un giga octets de logs dans des temps très courts. Ayant connaissance des memoryMappedFile qui est une technique d'accès aux fichiers très performante dont le principe de fonctionnement est de mapper, par des appels à l'API système, la zone de données de l'application directement sur le disque dur de la même façon que le fait Windows avec sa mémoire virtuelle (swap disk). Bien que le disque soit d'une lenteur incomparable à celle de la mémoire vide, dans notre cas, le gain de temps fait sur l'allocation mémoire et le chargement des données est substentiel. Cette méthode d'accès aux données stockées sur un disque dur est la plus performante que je connaisse, le gain de temps obtenu est de l'ordre de trois et n'est pas sensible à la taille du fichier traités (problématique du swap en cas de chargement en mémoire). Il restait à résoudre la problématique de la portabilité de mon code source, je n'eu pas loin à chercher car dans la partie iostreams des librairie boost se trouve une libairie d'abstraction prête à l'emploit (http://www.boost.org/libs/iostreams/doc/index.html).


POur vous donner une meileur idée des performances du couple mmap/regex, vous trouverez ci-dessous un court exemple :

Le moteur d'[[http://www.boost.org/libs/regex/doc/index.html|expressions régulières]] de Boost est très performant et de plus compilable sous différentes plateformes (dans mon cas AIX et Windows). Après quelques tests de validation, les performances étant au rendez-vous le choix fût arrêté.\\

Le moteur d'[[http://www.boost.org/libs/regex/doc/index.html|expression régulières]] de Boost est très performant et de plus compilable sous différentes plateformes (dans mon cas AIX et Windows). Après quelques tests de validation, les performances étant au rendez-vous le choix fût arrêté.\\
Dans le cadre de mon projet, mon objectif était de traiter des fichiers de logs plus de un giga octets, j'ai cherché une libairie d'abstraction me permettant d'utiliser des [[http://www.boost.org/libs/iostreams/doc/index.html|Memory Mapped File]]. Le memoryMappedFile est une technique d'accès aux fichiers. Le principe est de mapper, par des appels à l'API système, la zone de données de l'application directement sur le disque dur à la façon de la mémoire virtuelle de Windows (swap disk). Bien que le disque soit d'une lenteur incomparable à celle de la mémoire vide, dans notre cas, le gain de temps fait sur l'allocation mémoire et le chargement des données est substentiel. Cette méthode d'accès aux données stockées sur un disque dur est la plus performante que je connaisse, le gain de temps obtenu est de l'ordre de trois et n'est pas sensible à la taille du fichier traités (problématique du swap en cas de chargement en mémoire).

Sur un fichier de 70Mo, sous Windows, le temps de traitement ne dépasse pas 12 secondes (à la permière exécution, car un cache accélere grandement les choses par la suite) et atteint 30 secondes par la méthode classique. Sous AIX, le rapport entre les deux méthodes est le même et je n'ai pas observé de variation entre deux exécutions. A noter, que bien que la machine AIX utilisée pour mes tests date d'environ six ans, les temps de traitement mesurés étaient deux fois supérieurs à ceux obtenus sous Windows ce qui semble montrer l'extrême importance des performances des disques (une baie de stockage pour AIX et un disque IDE pour Windows).\\
Je ne ferai pas de tests sur d'autres plateformes mais serais curieux d'avoir une idée de la performance d'un tel traitement en Java, perl, php ....

Le moteur d'expression régulières de Boost est très performant et de plus compilable sous différentes plateformes (dans mon cas AIX et Windows). Après quelques tests de validation, les performances étant au rendez-vous le choix fût arrêté. Dans le cadre de mon projet, mon objectif était de traiter des fichiers de logs plus de un giga octets, j'ai cherché une libairie d'abstraction me permettant d'utiliser des Memory Mapped File.\\

Voici un court exemple, vous permettant de faire une évaluation de la performance de cette méthode :

(:sourcend:)


Le traitement effectué est l'analyse d'une log IIS par une expression régulière particulièrement longue. \\
Sur un fichier de 70Mo, le temps de traitement ne dépasse pas 12 secondes sous Windows (à la permière exécution, car un cache accélere grandement les choses par la suite) et atteint 30 secondes par la méthode classique. Sous AIX, le rapport reste identique et je n'ai pas observé de variations entre deux exécution. A noter, que bien que la machine AIX utilisée pour mes tests date d'environ six ans, les temps de traitement mesurés étaient deux fois supérieurs à ceux obtenus sous Windows ce qui semble montrer l'extrême importance des performances disque (une baie de stockage pour AIX et un disque IDE pour Windows).\\
Je n'ai pas le courage de faire les tests sur différentes plateforme mais serais curieux d'avoir une idée de la performance d'un tel traitement en Java ....