@@ -57,10 +57,10 @@ Le mode _single_ permet, comme son nom l'indique, de lancer un workflow une fois
\cimg{figs/bulk.png}{scale=.35}{Exemple d'application du mode bulk}{Source : créé par Théo PIRKL}
Les informations entrées dans le mode bulk sont combinées entre elles. Par exemple, à la figure 2.2, une tâche est lancée avec le paramètres `month` à 9, `sid` à 6307.9099 et `year` à 2017; une autre est lancée avec les paramètres `month` à 10, `sid` à 6307.9099 et `year` à 2017. Toutes les combinaisons des paramètres rentrés sont alors convertis en tâche. Cette façon de faire permet de rentrer rapidement un nombre important de tâches. Afin d'éviter de charger le contrôleur inutilement, c'est le client qui calcule toutes les combinaisons. Le contrôleur, quant à lui, reçoit les tâches générées et se contente de les départager entre les clients Inari disponibles.
Les informations entrées dans le mode bulk sont combinées entre elles. Par exemple, à la figure 2.2, une tâche est lancée avec le paramètres `month` à 9, `sid` à 6307.9099 et `year` à 2017; une autre est lancée avec les paramètres `month` à 10, `sid` à 6307.9099 et `year` à 2017. Toutes les combinaisons des paramètres rentrés sont alors convertis en tâche. Cette façon de faire permet de rentrer rapidement un nombre important de tâches. Afin d'éviter de charger le contrôleur inutilement, c'est le client qui calcule toutes les combinaisons. Le contrôleur, quant à lui, reçoit les tâches générées et se contente de les répartir entre les clients Inari disponibles.
Inari envoie de façon intelligente les workflow sur le client le moins chargé. Il compare pour cela sa base de données, et sélectionne le client possédant le moins de workflow. Cela permet de garantir un fonctionnement équitable de chaque client, et, en cas de panne, de ne pas devoir à relancer une grande partie des workflow.
Dans le mode _single_, un workflow est automatiquement assigné à un client Inari. Dans le mode _bulk_, en revanche, l'ensemble des workflows reçus sont distribués à tous les clients. De cette façon, si un utilisateur génère par exemple 200 workflow à exécuter puis 2000, les tâches seront malgré tout départagées également entre chaque client. Il y aura donc deux clients avec 1100 workflow et non un avec 200 et l'autre avec 2000.
Inari envoie de façon intelligente les workflow sur le client le moins chargé. Il consulte pour cela sa base de données, et sélectionne le client possédant le moins de workflow. Cela permet de garantir un fonctionnement équitable de chaque client, et en cas de panne, de ne pas avoir à relancer une grande partie des workflow.
Dans le mode _single_, un workflow est automatiquement assigné à un client Inari. Dans le mode _bulk_, en revanche, l'ensemble des workflows reçus sont distribués à tous les clients. De cette façon, si un utilisateur génère 200 workflow à exécuter puis 2000, les tâches sont malgré tout réparties également entre chaque client. Il y aura donc deux clients avec 1100 workflow et non un avec 200 et l'autre avec 2000.
### Parallélisme
...
...
@@ -69,11 +69,11 @@ Le parallélisme permet, de manière générale, d'accélérer le traitement de
* Le multiprocessing;
* L'utilisation d'un pool de clients Inari.
Le multiprocessing permet de mettre à contribution chaque coeur du processeur sur lequel s'exécute le client Inari. Le multiprocessing permet d'isoler chaque traitement. Le multithreading n'était pas utilisable dans le cadre de ce projet en raison de la technologie utilisée pour télécharger les documents [@noauthor_multithreading_nodate].
Le multiprocessing permet de mettre à contribution chaque coeur du processeur sur lequel est exécuté le client Inari. Le multiprocessing permet d'isoler chaque traitement. Le multithreading n'était pas utilisable dans le cadre de ce projet en raison de la technologie utilisée pour télécharger les documents [@noauthor_multithreading_nodate].
L'utilisation d'un pool de clients Inari, quant à elle, permet d'ajouter une couche de parallélisme : on pourrait comparer son utilisation à un multiprocessing de haut niveau, où tous les ordinateurs formeraient ensemble un seul processeur. Mais utiliser plusieurs ordinateur apporte aussi une redondance dans le traitement des documents. Dans le cas où un ordinateur hébergeant un client Inari venait à tomber en panne pendant un traitement, il est possible d'une part de relancer les tâches sur l'ordinateur une fois son fonctionnement restauré, ou entièrement sur un autre ordinateur. L'utilisation des deux technologies de parallélisme permet non seulement de se protéger des pannes, mais aussi d'utiliser de façon optimale les ressources de chaque ordinateur accueillant un client Inari.
L'utilisation d'un pool de clients Inari, quant à elle, permet d'ajouter une couche de parallélisme : on pourrait comparer son utilisation à un multiprocessing de haut niveau, où tous les ordinateurs formeraient ensemble un seul processeur. Utiliser plusieurs ordinateur apporte aussi une redondance dans le traitement des documents. Dans le cas où un ordinateur hébergeant un client Inari venait à tomber en panne pendant un traitement, il est possible d'une part de relancer les tâches. On pourrait ensuite choisir de relancer sur le même ordinateur une fois son fonctionnement restauré, ou sur un autre. L'utilisation des deux technologies de parallélisme permet non seulement de prévenir des pannes, mais aussi d'utiliser de façon optimale les ressources de chaque ordinateur accueillant un client Inari.
De cette façon, il est possible de traiter plusieurs workflow en même temps. Le workflow n'est donc pas accéléré mais la quantité de workflow exécutables en simultané est augmentée.
Par exemple, si huit machines sont considérées comme clients et que chacune possède huit coeurs, il est théoriquement possible de lancer $64$ workflow à la fois. Théoriquement, car les workflow peuvent consommer des ressources importantes, et lancer trop de workflow à la fois peut surcharger l'ordinateur sur lequel est hébergé un des clients Inari. Il est donc important, en configurant les clients Inari, de ne pas allouer à ces derniers la totalité des ressources système à disposition.
Par exemple, si huit machines sont considérées comme clients et que chacune possède huit coeurs, il est théoriquement possible de lancer $64$ workflow à la fois. Théoriquement, car les workflow peuvent consommer des ressources importantes et lancer trop de workflow à la fois peut surcharger l'ordinateur sur lequel est hébergé un des clients Inari. Il est donc important, en configurant les clients Inari, de ne pas allouer à ces derniers la totalité des ressources système à disposition.
Le chapitre _mesures_ montre l'accélération observée lors des mesures grâce au parallélisme.
### Interface graphique
...
...
@@ -84,31 +84,31 @@ L'interface web permet à l'utilisateur de _dessiner_ son workflow : un certain
\cimg{figs/inari-frontend-ui.png}{scale=.35}{Interface web Inari}{Source : créé par Théo PIRKL}
Comme la figure 2.3 l'indique, l'interface est composée de la façon suivante : à droite, l'interface permet de _dessiner_ son workflow en ajoutant des modules et en les interconnectant. Les boutons en bas à droite permettent la construction, la sauvegarde du workflow et l'ajout d'un module. Le menu à gauche permet de naviguer entre les différentes ressources accessibles à l'utilisateur, comme les workflows, les modules, les clients et les clicks. Chaque client Inari propose de télécharger l'intégralité des documents récupérés jusqu'ici. En outre, il est possible à l'utilisateur de gérer ses _clicks_. Quant aux clicks, il s'agit d'une ressource permettant à l'utilisateur de décrire à Inari ce qu'il faut sélectionner sur un site web en particulier. Ces clicks sont représentés sous la forme d'un XPath, une sorte de langage de programmation permettant de désigner un ou plusieurs éléments sur une page web. La figure 2.4 donne un exemple de clicks insérés dans l'application.
Comme la figure 2.3 le montre, l'interface est composée de la façon suivante : à droite, l'interface permet de _dessiner_ son workflow en ajoutant des modules et en les interconnectant. Les boutons en bas à droite permettent la construction, la sauvegarde du workflow et l'ajout d'un module. Le menu à gauche permet de naviguer entre les différentes ressources accessibles à l'utilisateur, comme les workflows, les modules, les clients et les clicks. Chaque client Inari propose de télécharger l'intégralité des documents récupérés jusqu'ici. En outre, il est possible à l'utilisateur de gérer ses _clicks_. Quant aux clicks, il s'agit d'une ressource permettant à l'utilisateur de décrire à Inari ce qu'il faut sélectionner sur un site web en particulier. Ces clicks sont représentés sous la forme d'une formule XPath, l'équivalent d'un langage de programmation permettant de désigner un ou plusieurs éléments sur une page XML comme du HTML. La figure 2.4 donne un exemple de clicks insérés dans l'application.
\cimg{figs/inari-frontend-xpath.png}{scale=.32}{Exemple de clicks}{Source : créé par Théo PIRKL}
Programmer une XPath n'est pas un prérequis prévu par le cahier des charges. Il suffit donc à l'utilisateur d'installer un module complémentaire Firefox, nommé _Inari Express_ permettant de les générer pour lui. Le module complémentaire consiste simplement en un viseur capable de sélectionner un élément dans la page, et de générer le XPath correspondant. Il est ensuite possible d'importer ce qu'a généré le module complémentaire dans l'interface web.
Programmer une XPath n'est pas un prérequis prévu par le cahier des charges. Il suffit à l'utilisateur d'installer un module complémentaire Firefox, nommé _Inari Express_ permettant de les générer pour lui. Le module complémentaire consiste simplement en un viseur capable de sélectionner un élément dans la page, et de générer le XPath correspondant. Il est ensuite possible d'importer ce qu'a généré le module complémentaire dans l'interface web.
Un utilisateur se servirait de l'interface de la façon suivante : après s'être inscrit et s'être connecté, il aurait la possibilité de créer un workflow. Là, il pourra ajouter des modules, et les interconnecter entre eux. Une fois son workflow terminé, il aura la possibilité de le sauvegarder et de le générer. L'action de générer un workflow convertit le workflow du format visuel au format d'exécution. Ces deux formats sont discutés plus en détail dans la section _fonctionnement du workflow_.
Un utilisateur se servirait de l'interface de la façon suivante : après s'être inscrit et s'être connecté, il aurait la possibilité de créer un workflow. Là, il pourra ajouter des modules, et les connecter entre eux. Une fois son workflow terminé, il aura la possibilité de le sauvegarder et de le générer. L'action de générer un workflow convertit le workflow du format visuel au format d'exécution. Ces deux formats sont discutés plus en détail dans la section _fonctionnement du workflow_.
Une fois son workflow généré, l'utilisateur a la possibilité de contrôler l'avancement en demandant, via la page _clients_, l'avancement de la récupération.
### Robustesse
Inari a été conçu de façon à pouvoir résister aux erreurs le plus possible. La majorité des composants sont dépendants les uns des autres au moment où ils discutent entre eux, mais pas avant ou après la discussion.
Inari a été conçu de façon à pouvoir résister aux erreurs le mieux possible. La majorité des composants sont dépendants les uns des autres au moment où ils discutent entre eux, mais pas avant ou après la discussion.
Par exemple, le contrôleur Inari n'est pas essentiel au fonctionnement de l'application une fois que ce dernier a transmis aux clients Inari leurs tâches respectives. Un client Inari peut subir une panne : le contrôleur est en mesure de renvoyer les tâches d'un client Inari pour reprendre là où le client en était.
Enfin, l'interface de contrôle web est complètement détachée du reste du projet : même si elle tombe en panne, aucun composant ne sera impacté.
L'exécution des tâches est elle aussi prévue pour résister aux pannes : chaque client Inari signale chaque tâche comme terminée ou en échec. Si trop d'échecs surviennent sur un client, le contrôleur Inari ordonne automatiquement son arrêt temporaire. L'arrêt se caractérise comme une pause de cinq minutes, le temps au client Inari de terminer les tâches en cours. Cette pause de cinq minutes est particulièrement utile lors du ralentissement d'un site web : si le site sur lequel Inari tente de récupérer des documents commence à ralentir, cela s'observera sous forme d'une vague d'erreurs au niveau des tâches. Le contrôleur bloquera alors les clients Inari, le temps que le site web puisse retrouver ses performances.
Enfin, le parallélisme des tâches amène lui aussi une robustesse : chaque exécution de workflow est isolée des autres, ce qui permet d'éviter des effets de bords. Si un workflow devait à s'arrêter en cours de route, il serait signalé en tant que tel au contrôleur, renvoyé au client et réexécuté dès qu'un des coeurs est disponible.
L'exécution des tâches est elle aussi prévue pour résister aux pannes : chaque client Inari signale chaque tâche comme terminée ou en échec. Si trop d'échecs surviennent sur un client, le contrôleur Inari ordonne automatiquement son arrêt temporaire. L'arrêt se caractérise comme une pause de cinq minutes, le temps au client Inari de terminer les tâches en cours. Cette pause de cinq minutes est particulièrement utile lors du ralentissement d'un site web : si le site sur lequel Inari tente de récupérer des documents commence à ralentir, cela s'observe sous forme d'une vague d'erreurs au niveau des tâches. Le contrôleur bloque alors les clients Inari, le temps que le site web retrouve ses performances.
Enfin, le parallélisme des tâches amène lui aussi une robustesse : chaque exécution de workflow est isolée des autres, ce qui permet d'éviter des effets de bords. Si un workflow devait à s'arrêter en cours de route, il serait signalé au contrôleur, renvoyé au client et réexécuté dès qu'un des coeurs est disponible.
### Fonctionnement du workflow
Le workflow se présente à l'utilisateur sous une forme de graphe unidirectionnel, où chaque noeud correspond à un module (ou action). Chaque noeud possède un nombre prédéterminé d'entrées et de sorties. Le graphe est unidirectionnel de façon à indiquer un ordre d'exécution. La figure 2.5 donne un exemple de workflow.
Le workflow se présente à l'utilisateur sous la forme d'un graphe unidirectionnel, où chaque noeud correspond à un module (ou action). Chaque noeud possède un nombre prédéterminé d'entrées et de sorties. Le graphe est unidirectionnel afin d'indiquer un ordre d'exécution. La figure 2.5 donne un exemple de workflow.
\cimg{figs/inari-example-workflow.png}{scale=.28}{Exemple de workflow}{Source : créé par Théo PIRKL}
Une fois le graphe dessiné, il est nécessaire au système de convertir le format permettant de dessiner et d'afficher le workflow à un format permettant de l'exécuter. Ce dernier n'est pas du code : Inari ne possède en effet pas de moteur syntaxique lui permettant d'autogénérer du code. A la place, un fichier contenant les modules à exécuter avec leurs arguments est généré. De cette façon, il suffit au client de démarrer le module indiqué par le fichier généré et d'indiquer les arguments nécessaires au fonctionnement du workflow.
Une fois le graphe dessiné, il est nécessaire au système de convertir le format permettant de dessiner et d'afficher le workflow à un format permettant de l'exécuter. Ce dernier n'est pas du code, car Inari ne possède pas de moteur syntaxique lui permettant d'autogénérer du code. A la place, un fichier contenant les modules à exécuter avec leurs arguments est généré. De cette façon, il suffit au client de démarrer le module indiqué par le fichier généré et d'indiquer les arguments nécessaires au fonctionnement du workflow.
\begin{figure}[t!]
\begin{subfigure}{.48\linewidth}
...
...
@@ -138,38 +138,38 @@ Le format d'affichage se contente d'indiquer comment redessiner ce que l'utilisa
\caption*{\textit{Source : réalisé par Théo Pirkl}}
\end{figure}
La figure 2.7 montre un exemple de comment Inari indique à un module qu'un argument sera passé par un module précédent. En donnant l'ID unique du module ainsi que le nom de l'argument il est possible de récupérer la valeur nécessaire. Un tel système pourrait s'apparenter à un pointeur. Chaque tâche possède, comme indiqué plus haut, un certain nombre d'entrées et de sorties. Chaque sortie de chaque tâche est conservé dans un tableau de façon à pouvoir s'en servir plus tard en cas de besoin.
Si un argument commence et finit par _$_, il est considéré comme un pointeur. Le pointeur est décomposé en deux parties, séparé d'un point. Un exemple de pointeur serait le suivant :
La figure 2.7 montre un exemple de comment Inari indique à un module qu'un argument sera passé par un module précédent. En donnant l'ID unique du module ainsi que le nom de l'argument il est possible de récupérer la valeur nécessaire. Un tel système pourrait s'apparenter à un pointeur. Chaque tâche possède, comme indiqué plus haut, un certain nombre d'entrées et de sorties. Les sorties de chaque tâche sont conservées dans un tableau de façon à pouvoir être utilisées plus tard en cas de besoin.
Si un argument commence et finit par _$_, il est considéré comme un pointeur. Le pointeur est composé de deux parties, séparé par un point. Ci dessous, un exemple de pointeur :
`$3f7d4753-8a1b-4f5e-a108-71c9e3854690.output$`
La première partie du pointeur correspond ici à un ID unique du module. C'est cette première information qui permet de savoir si le pointeur pointe sur une ancienne tâche valable ou non. La seconde partie du pointeur correspond à l'argument de sortie de l'ancienne tâche. Par exemple, si une tâche avait comme ID unique `foo` et comme argument de sortie `bar`, le pointeur serait `$foo.bar$`. La figure 2.8 montre comment le système détecte et récupère la valeur d'un pointeur.
La première partie du pointeur correspond ici à l'ID unique du module. C'est cette première information qui permet de savoir si le pointeur pointe sur une ancienne tâche valable ou non. La seconde partie du pointeur correspond à l'argument de sortie de l'ancienne tâche. Par exemple, si une tâche avait comme ID unique `foo` et comme argument de sortie `bar`, le pointeur serait `$foo.bar$`. La figure 2.8 montre comment le système détecte et récupère la valeur d'un pointeur.
\cimg{figs/pointer.png}{scale=.45}{Détection et lecture d'un pointeur}{Source : créé par Théo PIRKL}
## Catégories de scrapers
On départage les workflows en plusieurs catégories, notamment les scrapers simples et ceux complexes. Un scraper correspond à un workflow. Cette section s'intéresse aux différentes catégories de scrapers.
Les workflow sont répartis en plusieurs catégories, notamment les scrapers simples et ceux complexes. Un scraper correspond à un workflow. Cette section s'intéresse aux différentes catégories de scrapers.
## Catégorie un : Scrapers simples
Les scrapers simples correspondent aux workflow où la récupération de documents se limite à consulter une page web et où le traitement (clicks, remplissages de formulaires) est minimal ou inexistant. Cela correspond de manière générale à tous les sites ne dépendant pas de JavaScript pour naviguer sur le site.
Les scrapers simples correspondent aux workflow où la récupération de documents se limite à consulter une page web et où le traitement (clicks, remplissages de formulaires) est minimal ou inexistant. Cela correspond de manière générale à tous les sites ne dépendant pas de JavaScript pour naviguer.
### Application pratique : FAO Genève
La FAO Genève est un site de la République et Canton de Genève, et propose des documents relatant d'avis divers et variés. Les documents sont disponibles sous forme de liste, où chaque document peut être téléchargé en cliquant sur un bouton. Le seul traitement nécessaire est de passer de page en page de façon à récupérer d'anciens documents.
Pour récupérer les documents, la marche à suivre est la suivante : lancer un navigateur, puis le faire naviguer sur le site web de la FAO Genève (https://fao.ge.ch). Là, un captcha est à résoudre, mais qui peut être évité en remplaçant dans l'URL `captcha` par login. C'est ce qui est alors fait. Une fois le captcha détourné, on accède à la liste des fichiers récents. Il faut alors exécuter une XPath pour retrouver l'URL de téléchargement de chaque document : on simule ensuite ces clics pour récupérer les documents en une seule fois.
Le traitement principal consiste donc à aller sur le site, détourner le captcha et détecter les boutons de téléchargement, ce que fait le workflow Inari.
Le traitement principal consiste donc à aller sur le site, contourner le captcha et détecter les boutons de téléchargement, ce que fait le workflow Inari.
Le traitement ci-dessus correspond à une page. Pour télécharger 200 pages, il suffit d'ajouter une étape où une fois que le captcha est résolu, on demande au navigateur d'aller à la page correspondante via le paramètre `page` dans l'URL. Par exemple, la page 40 correspond à l'URL \url{https://fao.ge.ch?page=39}.
## Catégorie deux : Scrapers complexes
Les scrapers complexes correspondent aux workflow où la récupération de documents demande un traitement conséquent sur la page : remplir un ou plusieurs formulaires est considéré comme un traitement complexe. De manière générale, cela correspond soit aux sites possédant des formulaires à remplir, soit aux sites où la navigation est assurée par Javascript. Dès lors qu'il est nécessaire de faire du prétraitement pour atteindre chaque document, le workflow est considéré comme complexe.
Les scrapers complexes correspondent aux workflow où la récupération de documents demande un traitement conséquent sur la page comme remplir un ou plusieurs formulaires. De manière générale, cela correspond soit aux sites possédant des formulaires à remplir, soit aux sites où la navigation est assurée par Javascript. Dès lors qu'il est nécessaire de faire du prétraitement pour atteindre chaque document, le workflow est considéré comme complexe.
### Application pratique : Swiss-Impex
Swiss-Impex est un site où les statistiques d'import/export de ou vers la Suisse sont publiées. Le site fonctionne avec un framework JavaScript et nécessite, pour chaque document, de remplir de nombreux formulaires. Par conséquent, il s'agit d'un workflow complexe. La figure 2.9 montre quelques écrans à remplir pour obtenir un document.
Swiss-Impex est un site où les statistiques d'import-export suisses sont publiées. Le site fonctionne avec un framework JavaScript et nécessite, pour chaque document, de remplir de nombreux formulaires. Par conséquent, il s'agit d'un workflow complexe. La figure 2.9 montre quelques écrans à remplir pour obtenir un document.
\begin{figure}[t!]
\begin{subfigure}{.48\linewidth}
...
...
@@ -191,26 +191,26 @@ Swiss-Impex est un site où les statistiques d'import/export de ou vers la Suiss
Le traitement des documents de Swiss-Impex n'implique pas de captcha comme le site de la FAO Genève, mais nécessite de remplir de nombreux champs pour atteindre un document. Comme le montre la figure 2.9, il faut commencer par remplir la date du document que l'on souhaite obtenir. Il faut ensuite choisir parmi les 6000 catégories de document celle que l'on souhaite obtenir, puis sélectionner les pays d'import ou d'export de la marchandise sélectionnée. Enfin, il est possible d'inclure ou non les matières précieuses comme l'or, avant de pouvoir exécuter la requête. Une fois le document généré, il faut changer quelques réglages esthétiques avant de pouvoir exporter le résultat sous forme de XLSX. Cependant, ce format est propriétaire et peu pratique. Il est donc nécessaire de l'exporter en CSV. C'est encore une action qui est nécessaire d'être effectuée avant de pouvoir passer au prochain document.
Il faut commencer par remplir la date du document que l'on souhaite obtenir. Il faut ensuite choisir parmi les 6000 catégories de document celle que l'on souhaite obtenir, puis sélectionner les pays d'import ou d'export de la marchandise sélectionnée. Enfin, il est possible d'inclure ou non les matières précieuses comme l'or, avant de pouvoir exécuter la requête. Une fois le document généré, il faut changer quelques réglages esthétiques avant de pouvoir exporter le résultat sous forme de XLSX. Cependant, ce format est propriétaire et peu pratique. Il est donc nécessaire de l'exporter en CSV. C'est encore une action qui est nécessaire d'être effectuée avant de pouvoir passer au prochain document.
Dans ce cas, les actions sont nombreuses, et chaque action est synchrone. De plus, chaque clic est envoyé au serveur Swiss-Impex. A chaque
envoi, les formulaires sont verrouillés et il est donc nécessaire d'attendre à chaque clic la réponse du serveur. Il n'est pas possible de récupérer plus qu'un mois de valeurs à la fois (c'est-à-dire un document relatant d'une marchandise pour un mois pour tous les pays en
import ou export). En effet, le site Swiss-Impex limite le nombre de cellules que l'on peut demander à la fois.
envoi, les formulaires sont verrouillés et il est donc nécessaire d'attendre à chaque clic la réponse du serveur. Il n'est pas possible de récupérer plus qu'un mois de valeurs à la fois, c'est-à-dire un document relatant d'une marchandise pour un mois pour tous les pays en
import ou export. En effet, le site Swiss-Impex limite le nombre de cellules que l'on peut demander à la fois.
## Catégorie 1.5 : Scrapers hybrides
Certains sites ne rentrent pas entièrement dans l'une des deux catégories : un traitement spécial est nécessaire. Il peut être au niveau d'une limitation de connexion, d'adresse IP, ou une autre limitation obligatoirement à respecter.
Certains sites ne rentrent pas entièrement dans l'une des deux catégories : un traitement spécial est nécessaire. Il peut être au niveau d'une limitation de connexion, d'adresse IP, ou une autre limitation à respecter.
### Application pratique : Registre du Commerce
Le registre du commerce est un exemple de site nécessitant une attention particulière au nombre de connexions simultanées. Ce site recense les extraits d'entreprises sur tout le canton de Genève.
Les documents sur le site sont générés à la volée : afin d'éviter de surcharger le service, il est donc nécessaire de limiter le nombre de documents générés à la fois en limitant le nombre de connexions simultanées. Qui plus est, le site ne propose la génération que d'un document à la fois, il n'est pas possible de générer un document pour tous les résultats.
Le registre du commerce est un exemple de site nécessitant une attention particulière au nombre de connexions simultanées. Ce site recense les extraits d'entreprises de tout le canton de Genève.
Les documents sur le site sont générés à la demande : afin d'éviter de surcharger le service, il est donc nécessaire de limiter le nombre de documents générés à la fois en limitant le nombre de connexions simultanées. De plus, le site ne propose la génération que d'un document à la fois. Il n'est pas possible de générer un document pour tous les résultats.
## Bilan
L'infrastructure d'Inari se décompose en plusieurs composants relativement complexes.
Toutefois, du point de vue de l'utilisateur, c'est une solution facile à prendre en main, car aucune programmation n'est nécessaire, aucune installation n'est requise puisqu'il suffit d'un navigateur web, et aucune notion en informatique n'est véritablement nécessaire.
Cette infrastructure permet aussi de mitiger les pannes, et donc d'assurer une continuité des opérations même en cas de problème sur l'un des composants.
L'infrastructure installée, il ne reste plus qu'à effectuer des mesures de performance, de façon à déterminer à quel point l'infrastructure résiste aux montées en charge.
L'infrastructure d'Inari est faire de plusieurs composants relativement complexes.
Toutefois, du point de vue de l'utilisateur, c'est une solution facile à prendre en main, car aucune programmation n'est nécessaire, aucune installation n'est requise puisqu'il suffit d'un navigateur web et aucune notion en informatique n'est nécessaire.
Cette infrastructure permet aussi de mitiger les pannes, donc d'assurer une continuité des opérations même en cas de problème sur l'un des composants.
Une fois que l'infrastructure est installée, il ne reste plus qu'à effectuer des mesures de performance afin de déterminer la résistance de l'infrastructure face aux montées en charge.
@@ -10,8 +10,8 @@ Le but de ce travail était de mettre en place une solution complète de scrapin
Inari propose actuellement le téléchargement de documents de plusieurs sites; cette collection de sites peut être facilement étendue. Les résultats lors de la collecte présentés dans la section _mesures_ indiquent à quel point un tel logiciel est utile à la collecte de données puisque les mesures semblent indiquer que dans les pires situations, on va malgré tout trois fois plus vite qu'un être humain.
Le scraping est un sujet présentant bien des difficultés difficilement maîtrisables : la plupart des problèmes, tels que les ralentissements ou les changements d'apparence du site sont liés au prestataire de service. Ce sont des problèmes complexes mais relativement atténuables en changeant par exemple les réglages des clients Inari.
Le scraping est un sujet présentant bien des difficultés difficilement maîtrisables : la plupart des problèmes, tels que les ralentissements ou les changements d'apparence du site sont liés au prestataire de service. Ce sont des problèmes complexes mais atténuables en changeant par exemple les réglages des clients Inari.
Le travail semble répondre au problème initialement observé, de façon plus performante qu'un être humain; il serait maintenant intéressant de le déployer dans une entreprise afin de voir la capacité d'Inari à être véritablement utilisée. Il serait aussi intéressant d'ajouter plusieurs outils au système, plus particulièrement l'ajout de détournement de captchas sans passer par une société tierce, ce qui permettrait de compléter la suite d'outils proposés. Une autre fonctionnalité intéressante à ajouter serait d'ajouter un système de mesure détectant immédiatement les ralentissements du site sur lequel les documents sont téléchargés. Le système actuel ne détecte le ralentissement qu'une fois qu'il est arrivé : le nouveau système permettrait de prévenir les ralentissements juste avant qu'ils arrivent.
Le travail semble répondre au problème initialement observé, de façon plus performante qu'un être humain. Il serait maintenant intéressant de le déployer dans une entreprise afin de voir la capacité d'Inari à être véritablement utilisée. Il serait aussi intéressant d'ajouter plusieurs outils au système, plus particulièrement l'ajout de détournement de captchas sans passer par une société tierce, ce qui permettrait de compléter la suite d'outils proposés. Une autre fonctionnalité intéressante à ajouter serait d'ajouter un système de mesure détectant immédiatement les ralentissements du site sur lequel les documents sont téléchargés. Le système actuel ne détecte le ralentissement qu'à posteriori : le nouveau système permettrait de prévenir les ralentissements juste avant qu'ils arrivent.
