Page suivante Page précédente Table des matières 7. Mise en série des requêtes d'application Web Par Colin C. Wilson Les serveurs d'application Web sont des extensions extrêmement utiles du concept de serveur Web de base. Au lieu de fournir des pages statiques simples ou les résultats de requêtes dans une base de données, on peut rendre disponible une application complexe à travers le réseau. Un problème avec les applications serveurs est que le traitement des données peut prendre un certain temps et des ressources processeur importantes: cela peut conduire à des taux de réponse médiocres ou à des erreurs par manque de mémoire quand de multiples utilisateurs envoient des requêtes simultanément. Il y a classiquement trois stratégies de base pour le traitement des requêtes web qui ne peuvent pas être satisfaites immédiatement: ignorer le problème, utiliser du code CGI unbuffered no-parsed-header (NPH) pour émettre un message "Processing" alors que la tâche se termine ou encore envoyer immédiatement une réponse qui donne à l'utilisateur une référence vers une page créée à la terminaison du travail demandé. A mon avis, la première option n'est pas efficace. Si l'on ne leur donne pas d'informations, les utilisateurs recommencent invariablement leurs requêtes en pensant qu'il s'est produit une erreur d'émission. Les requêtes redondantes aggraveront le problème si elles ne sont pas éliminées. Pire, le nombre de ces requêtes redondantes fera un pic précisément au moment de la charge maximale. Le NPH CGI est le plus utile quand les temps de traitement sont courts et que le serveur est capable de gérer de nombreuses instances simultanées de l'application. Le défaut en est que les utilisateurs doivent attendre que le traitement soit terminé et ne peuvent pas se rendre rapidement sur la page. La méthode que je préfère est de faire une référence vers une page dynamique en complément d'une méthode fiable de mise en série des requêtes. 7.1 Description Les origines de Generic NQS (Linux Journal 55) NQS a été originellement développé pour la NASA en 1985. Le code source a été vendu à de nombreuses compagnies dont Silicon Graphics, Cray Research et Monsanto Company. SG a développé sa propre variante pour l'utiliser sous IRIX 4 bien qu'il en ait été retiré avant IRIX 5. Cray a bénéficié d'un bon succès commercial avec son produit NQE qui contenait de nombreuses améliorations sur le NQS originel. Monsanto a décidé de placer "Monsanto NQS" sous licence GPL GNU et a distribué des améliorations pour IRIX et des portages vers quelques versions d'UNIX dont SunOS et DEC OSF/UNIX en culminant avec NQS v3.36 en 1994. En 1994, l'Université de Sheffield a commencé un programme de deux ans pour fournir à toutes les académies du Royaume-Uni un système de traitement par lots pour UNIX robuste et portable. L'Université s'est basée sur l'excellent travail de John Roman de chez Monsanto, livrant "Generic NQS" avec de nouvelles fonctionnalités, des corrections de bogues et le support de plus d'une vingtaine de versions d'UNIX, dont Linux. De nos jours, Generic NQS continue à être supportée par Stuart Herbert sur son temps libre en utilisant des machines sous Linux et FreeBSD. Exemple Comme exemple, je vais décrire mon utilisation de Generic NQS (GNQS) (voir http://www.shef.ac.uk/~nqs/ et http://www.gnqs.org) pour effectuer la mise en série et l'élimination des jobs redondants d'une manière robuste pour un ensemble de serveurs d'applications web au Centre du Génome de l'Université de Washington. GNQS est un paquetage Open Source de gestion de queues, disponible pour Linux ainsi que sur un grand nombre d'autres plate-formes UNIX. Il a principalement été écrit pour optimiser l'utilisation de super-ordinateurs et de grandes fermes de serveurs. Cependant, il est également utile pour les machines seules. GNQS est maintenu pour le moment par Stuart Herbert. Au Centre du Génome, nous avons développé un certain nombre d'algorithmes pour l'analyse de séquences d'ADN. Certains de ces algorithmes sont gourmands en temps CPU et en mémoire et nécessitent par ailleurs d'accéder à de grandes bases de données de séquence. En sus de la distribution du code, nous avons mis à disposition plusieurs de ces programmes via un serveur web et e-mail pour les scientifiques du monde entier. N'importe qui disposant d'un navigateur peut aisément analyser une séquence sans l'aide d'une expert UNIX et, ce qui est le plus important pour notre application, sans maintenir une copie locale de notre base de données. Compte tenu du fait que les bases de données de séquence sont énormes et en constante révision, en maintenir des copies peut être une dépense trop lourde pour de petits centres de recherche. Ce site a d'abord été mis en oeuvre avec un Pentium Pro à 200MHz avec 128 Mo de RAM qui tournait avec une RedHat 4.2 et Apache, ce qui était plus que suffisant pour le nombre de requêtes de traitement. La plupart des requêtes sur notre site pouvaient être traitées en quelques secondes, mais quand de grosses requêtes étaient faites simultanément, les temps de réponse devenaient inacceptables. A mesure que le nombre de requêtes et que la taille des données augmentaient, le serveur était de plus en plus souvent surchargé. Nous avions d'abord pensé réduire la taille maximale des problèmes que nous acceptions mais nous savions qu'avec l'avancement du projet Human Genome Project, des jeux de données plus importants allaient devenir monnaie courante. Après avoir analysé les logs d'utilisation, il est devenu évident que, durant les périodes de pointe, les gens envoyaient de multiples copies de leur requête quand le serveur ne renvoyait pas les résultats suffisamment rapidement. J'ai eu ce problème de performance peu après la mise en ligne de notre site web. 7.2 Implémentation Exemples de commandes GNQS (Linux Journal 55) #Créer une queue de traitement par lots: qmgr create batch_queue web-queue #Soumettre un travail qsub -q web-queue <<EOF command -args data EOF #Voir l'état de la queue qmgr show queue web-queue@webserver; type=BATCH; [ENABLED, INACTIVE]; pri=16 lim=1 0 exit; 0 run; 0 stage; 0 queued; 0 wait; 0 hold; 0 arrive; #Créer une queue réseau sur webserver.genome, la lancer #sur deux serveurs de cpu, "round robin" à charge égale qmgr create pipe_queue web-queue add destination=job-queue@cpu1.genome,job-queue@cpu2.genome web-queue set lb_out web-queue (sur chaque serveur de cpu) qmgr create batch_queue job-queue run_limit=1 set lb_in job-queue qmgr set scheduler webserver.genome Solution Au lieu d'augmenter la taille du serveur web, j'ai pensé qu'une mise en série robuste réglerait de manière plus satisfaisante ce problème. J'ai installé GNQS version 3.50.2 sur le serveur et j'ai écrit de petites extensions aux scripts CGI pour mettre dans une queue des requêtes plus importantes au lieu de les traiter sur le champ. Plutôt que de m'en remettre aux scripts NPH CGI qui bloqueraient la page web d'un utilisateur pendant plusieurs minutes le temps que le serveur web traite la requête, je préfère écrire une page temporaire contenant un message disant que le serveur est toujours en cours de traitement et détaillant comment recharger la page ultérieurement. En créant un nom pour la page dynamique à partir d'une somme md5 des paramètres de la requête et des données, j'ai été en mesure de complètement éliminer le problème de multiples requêtes identiques. Finalement, toutes les requêtes web sont mises en série dans une queue de job unique et une queue supplémentaire de priorité inférieure est utilisée pour les requêtes e-mail. C'était une amélioration mineure de permettre que les requêtes soumises à réponse au serveur web par e-mail puissent être simplement mises dans une queue (la queue de priorité inférieure pour les e-mail). Par là-même, l'utilisation du processeur a été augmenté et les conflits entre jobs ont été réduits. Bien que cela se soit montré plutôt efficace du point de vue utilisation de la machine, la queue de jobs tend à devenir si longue durant les périodes de pointe que certains utilisateurs en perdent leur patience. Une amélioration additionnelle a été de signaler la longueur de la queue lors de la mise dans la queue de la requête. Cela a donné aux utilisateurs une meilleure évaluation du temps de traitement de la commande. Par ailleurs, quand un job est réenvoyé dans la queue, la position actuelle dans la queue est retournée. Ces changements ont complètement éliminé les mise en causes erronées de l'état du serveur web. Après un an de fonctionnement, nous avons mis à disposition une application supplémentaire et décidé de migrer le serveur vers un système Linux/Alpha tournant sous une RedHat 5.0. Le passage à glibc a mis à jour un bogue dans GNQS qui était à l'origine difficile à trouver. Cependant, puisque le code source était disponible, j'ai été capable de trouver et de corriger ce bogue moi-même. J'ai depuis soumis ce patch à Stuart pour qu'il l'inclue dans la prochaine version de GNQS. Par ailleurs, j'ai mis à disposition un RPM source (ftp://ftp.redhat.com/pub/contrib/SRPMS/Generic-NQS-3.50.4-1.src.rpm sur le site FTP de RedHat. 7.3 Évolutions envisagées La mise en queue des requêtes avec GNQS permet également une autre option intéressante qui pourrait être prise en compte au vu de l'augmentation de nos demandes de traitement. Au lieu de migrer notre serveur une nouvelle fois vers une machine encore plus puissante ou de s'en remettre à la complexité d'une chaîne de serveurs Web, nous pourrions conserver le serveur web existant comme serveur frontal. Sans aucun changement dans les scripts CGI sur le serveur web, GNQS pourrait être reconfiguré pour distribuer les jobs mis en queue entre de nombreuses machines additionnelles de manière à tenir nos besoins en temps de réponse. Compte tenu du fait que GNQS peut s'occuper de l'équilibrage de la charge, son extension peut se faire aisément, efficacement et dynamiquement sans avoir à éteindre le serveur. Le nombre de serveurs de queue serait complètement transparent pour le serveur web. 7.4 Évaluation Il y a plusieurs manières de gérer les applications web qui demandent un temps de traitement conséquent. L'optimisation des serveurs d'application fait appel à des techniques différentes de celles requises pour l'optimisation des serveurs devant répondre à de nombreuses requêtes. Pour les serveur d'application, la ressource limitante peut être le processeur, la mémoire ou les E/S sur le disque plus que la bande passante. Les temps de réponse à certaines requêtes données doit être relativement court et l'information des utilisateurs qui attendent sur l'état de leur requête est important. Envoyer des requêtes vers une queue avec GNQS et renvoyer l'utilisateur vers une page de résultats est une technique qui s'est montrée plus efficace, facile à implémenter et robuste. 7.5 Remerciements Merci à Stuart Herbert, le mainteneur de GNQS. Ce travail a été partiellement effectué grâce à des aides du Département de l'Energie (Department of Energy et l'Institut National de Recherche sur le Génome Humain (National Human Genome Research Institute). Copyright © 1998, Colin C. Wilson - Adaptation française de Pierre Tane Page suivante Page précédente Table des matières