M1 CERI. CADET Cyril BAKAKAS Habib CAHIER DES CHARGES. Présentation de la technologie de serveur web choisie

Transcription

1 2011 M1 CERI CADET Cyril BAKAKAS Habib CAHIER DES CHARGES Présentation de la technologie de serveur web choisie

2 TABLE DES MATIERES AVANT PROPOS... 4 CONTEXTE... 4 Finalité... 4 Pres-requis... 4 PRESENTATION DES SERVEURS WEB... 5 Apache... 5 Nginx... 5 Lighttpd... 6 Comparaison des modules... 6 Les principaux modules... 7 Le module rewrite... 7 Le module evasive... 8 Le module LOG... 8 TESTS DE PERFORMANCE Introduction Schémas Protocole Contenu Statique SIEGE APACHE BENCH Contenu Dynamique SIEGE APACHE BENCH Emprunte mémoire et CPU TESTS DE CHARGE Introduction Protocole Scénario Scénario Disponibilité Temps total de durée du test Utilisation mémoire Utilisation CPU Estimation

3 CONCLUSION

4 AVANT PROPOS Nous participons au développement et à la mise en production d un jeu de stratégie Web moderne (ajax/jquery, php5/symfony/doctrine) utilisant des techniques innovantes. Plus précisément nous déterminerons l'architecture réseau (serveur web, mysql, php) permettant un fonctionnement optimal du jeu de stratégie. Cette recherche de la configuration adaptée comportera deux phases : une première phase pendant laquelle le serveur web sera choisit, parmi trois possibilités, après une batterie de tests qui serons explicités, puis une deuxième phase pendant laquelle le serveur sera optimisé dans son interaction avec les composantes php et mysql. Ce cahier des charges a pour but de justifier la technologie du serveur web à utiliser. CONTEXTE FINALITE Le choix des serveurs web se fera parmi les trois solutions les plus populaires sur internet actuellement : Apache, Lighttpd et Nginx. Nous pouvons classer ces serveurs selon deux catégories : synchrone ( apache : orienté processus) et asynchrone ( nginx, lighttpd ). Un serveur orienté processus traite chaque processus simultané en créant un processus (thread) nouveau, on obtient donc un processus par requête client. Au contraire, un serveur asynchrone traite les requêtes dans un seul ou peu de processus. On en déduit que les serveurs asynchrones devraient utiliser moins de mémoire et être plus performant que le serveur synchrone. Cette intuition devra être confirmée ou infirmée par les tests que nous conduirons. Par ailleurs, nous devrons fournir un travail en synergie avec les autres groupes du projet en vue de mettre en production et pérenniser le jeu. Cette coopération prendra la forme de réunions entre les différents groupes et éventuellement la mise en place d'un espace collaboratif ( wiki, chat etc ) et nous permettra d'atteindre l'objectif de publication du jeu optimisé, c'est à dire un jeu tournant sur un serveur web doté d'une stratégie de continuité de service efficace. PRES-REQUIS Nous disposons d une machine linux Debian Lenny 64 bits doté de 2Go de mémoire RAM et d un processeur Intel Pentium D doté de 2,80GHz et de 2 coeurs. 4

5 PRESENTATION DES SERVEURS WEB APACHE Synchrone (un processus par requête). Ressources mémoire relativement élevée. Apache, est un logiciel de serveur HTTP produit par l'apache Software Foundation. C'est le serveur HTTP le plus populaire du Web (Apache représente 50,93% des parts de marché). C'est un logiciel libre avec un type spécifique de licence, nommée licence Apache. Apache est conçu pour prendre en charge de nombreux modules lui donnant des fonctionnalités supplémentaires : interprétation du langage Perl, PHP, Python et Ruby, serveur proxy, Common Gateway Interface, Server Side Includes, réécriture d'url, négociation de contenu, protocoles de communication additionnels, etc. Néanmoins, il est à noter que l'existence de nombreux modules Apache complexifie la configuration du serveur web. En effet, les bonnes pratiques recommandent de ne charger que les modules utiles : de nombreuses failles de sécurité affectant uniquement les modules d'apache sont régulièrement découverts. Les possibilités de configuration d'apache sont une fonctionnalité phare. Le principe repose sur une hiérarchie de fichiers de configuration, qui peuvent être gérés indépendamment. Cette caractéristique est notamment utile aux hébergeurs qui peuvent ainsi servir les sites de plusieurs clients à l'aide d'un seul serveur HTTP. Pour les clients, cette fonctionnalité est rendue visible par le fichier.htaccess. NGINX Asynchrone (Un processus ou peu de processus gèrent les requêtes). Nginx est un reverse proxy et serveur web, ainsi qu'un proxy mail (IMAP et POP3), sous licence BSD. Igor Sysoev a commencé à le développer en 2002 pour un site russe à fort trafic, et depuis la popularité de nginx n'a cessé de croître. Selon netcraft, 6,5% des sites web dans le monde seraient servis par nginx. Nginx est réputé pour ses performances et sa faible consommation mémoire. Cela vient de son architecture : au lieu de dédier un processus ou un thread (processus) pour traiter chaque requête, il utilise un modèle événementiel. Cela lui permet notamment de tenir un grand nombre de connexions simultanées sans voir sa consommation mémoire s'envoler. Des sites connus comme Wordpress, github et Sourceforge l'ont choisi pour cette raison. Nginx est également développé selon une approche modulaire : il est composé d'un cœur réduit et d'un grand nombre de modules que l'on peut choisir d'inclure à la compilation. 5

6 Comme il est facile de développer un module, il en existe de nombreux et qui couvrent une large palette de fonctionnalités, des plus essentielles (SSL, fastcgi, gzip, rewrite, log) aux plus exotiques (servir des fichiers GIF vides, afficher des pages d'index aléatoires). LIGHTTPD Lighttpd est un serveur web (HTTP) qui, de par sa légèreté, se veut rapide. Il supporte un grand nombre de fonctionnalités comparables à celles d'apache (comme les rewrite, fast-cgi, proxy, etc.) pour des performances aussi bonnes sinon meilleures dans les tests faits par Lighttpd. Par rapport à Apache, il ne supporte pas les fichiers htaccess ou encore htpasswd. Ces deux problèmes sont contournables si vous avez accès à la configuration de votre serveur. Lighttpd se trouve dans le top cinq des serveurs les plus utilisés dans le monde. Le principal désavantage de lighttpd face à son concurrent Apache est de ne pas supporter les fichiers.htaccess : les directives ne sont évaluées qu'une seule fois, au démarrage du serveur, et nécessitent de le redémarrer afin d'être prises en compte COMPARAISON DES MODULES Nginx module Apache module Lighttpd Caractéristiques du module module HTTP Upstream Module mod_proxy_balan cer mod_proxy_co re Ce module permet la répartition de charge Access Module mod_access mod_access Contrôle de l accès au serveur Auth Basic Module mod_auth mod_auth Protection à l aide d une authentification de base via http AutoIndex Module mod_autoindex mod_dirlisting Permet de faire des listings automatiques de répertoire (ie commande ls unix) Browser Module mod_setenvif? Création de variables d environnement dépendant des caractéristiques de la requête Charset Module none none Permet l encodage du texte au format précisé dans le module Empty GIF Module none none Garde une image transparente en mémoire qui peut être servie rapidement FastCGI Module mod_fastcgi, mod_fcgid mod_fastcgi Permet l interaction avec le protocole fastcgi GEO Module mod_geoip mod_geoip Permet de créer des variables dont la valeur dépend de l adresse IP. Permet d envoyer du contenu en fonction de la géolocalisation du 6

7 Gzip Compression Module Gzip Pre- Compression Module HTTP Headers Module HTTP Referer Module client mod_deflate mod_deflate Permet la compression des données en sortie du serveur à la volée none none Avant la compression ce module s assure qu il n existe pas de fichier précompressé pour ne pas avoir à compressé le même fichier chaque fois qu il est demandé mod_headers mod_setenv Fournit des directives pour contrôler et modifier les requêtes http et l entête des réponses mod_setenvif? Bloque l accès au site selon que certaines caractéristiques de la requête ne correspondent pas à l expression spécifiée Limit Zone Module mod_limitipconn mod_evasive Permet de limiter le nombre de connections simultanées pour une session ou d une adresse spécifique Log Module mod_log_config mod_accesslog Permet de gérer le fichier de log des clients Proxy Module mod_proxy mod_proxy Permet l utilisation de serveur proxy Rewrite Module mod_rewrite mod_rewrite Permet de réécrire les url SSI Module mod_include mod_ssi Ce module fournit un filtre qui s appliquera aux fichiers avant d être envoyer au client UserID Module mod_usertrack mod_usertrack Permet l utilisation de cookies afin d identifier un client déjà précédemment connecté FLV Module mod_flvx mod_flv_strea Permet d utiliser directement du ming serveur des fichiers flash SSL Module mod_ssl SSL Permet de supporter https ssl tls LES PRINCIPAUX MODULES LE MODULE REWRITE Ce module en particulier beaucoup plus de fonctionnalités à nginx qu une simple série de directives. Il définit une façon nouvelle de traiter les requêtes clients. Au début, le but de ce module est de faire de la réécriture d url. Ce mécanisme permet de se débarrasser des url peut esthétiques, peu porteuse d information et contenant plusieurs paramètres, par exemple instance, certains paramètres sont particulièrement peu informatif. Apres la réécriture de l url, on introduit dans l url des informations utiles, l url de l exemple précédent devient

8 32-US-economy-strengthens.html. La réécriture d url permet aussi une indexation plus aisée par les moteurs de recherche Dans lighttpd le module rewrite existe avec un autre module très proche : mod_redirect. La différence entre rewrite et redirect est que le rewrite se déroule directement dans le serveur tandis que la redirection d une requête est réalisée en envoyant une entête à l utilisateur lui disant où la page se trouve vraiment. Cette différence est importante lorsque le choix de l un ou l autre doit se faire. Dans apache le module rewrite supporte un nombre illimité de règles qui elles mêmes comptent d autres règles conditionnées attachées, pour produire un mécanisme de manipulation d url puissant et flexible. LE MODULE EVASIVE Le mod_evasive de lighttpd est l équivalent de mod_limitipconn d apache et l équivalent de limit zone module de nginx. Ce module permet de limiter la quantité maximale de connections simultanée sur le serveur pour une certaine zone Dans nginx la première étape consiste à définir la zone en utilisant la directive limit_zone puis on y limite les connections simultanées en utilisant limit_conn. Si la limite est atteinte, toutes les requêtes supplémentaires concurrentes auront comme réponse 503 service unaivalable Dans lighttpd le mod_evasive est un module très simple pour limiter les connexions par adresse ip. Ainsi on utilise le paramètre : evasive.max-conns-per-ip Dans apache on peut limiter le nombre de connexion par utilisateur, par vhost ou par charge moyenne. LE MODULE LOG Log module pour nginx, mod_log_config pour apache et mod_accesslog pour lighttpd. Ce module contrôle la façon dont les requêtes sont loguées par le serveur. Dans nginx la directive access_log permet de déterminer le chemin, le format et la taille du tampon du fichier de log. Nginx supporte une puissante séparation en fonction du lieu. La directive open_log_file_cache met en place le cache qui stocke les descripteurs de fichiers de log fréquemment utilisés Dans lighttpd le module mod_accesslog a pour option : accesslog.use-syslog et envoi l accesslog à syslog. Avec accesslog.filename le nom du fichier ou l accesslog devrait être écrit si syslog n est pas utilisé. On définit aussi l accesslog.format, le format du fichier de log. 8

9 Dans apache mod_log_config propose un traitement flexible de log des requêtes clients. Les logs sont écrits dans un format personnalisable et peuvent être écrit directement dans un fichier ou dans un programme externe. Les logs conditionnels sont possible si bien que les requêtes individuelles peuvent être inclues ou exclues des logs en fonction des caractéristiques des requêtes. Trois directives sont fournies par le module : Transferlog pour créer un fichier de log, LogFormat pour configurer un format d utilisation et CustomLog pour définir le fichier de log et le format en même temps. 9

10 TESTS DE PERFORMANCE INTRODUCTION Les tests de performances déterminerons laquelle des technologies est la meilleure. Pour cela nous disposons d une autre machine qui servira à stresser notre serveur web. La machine de benchmark simulera des connexions utilisateurs envoyant plusieurs requêtes en même temps. Il existe des outils qui permettent de faire cela. Dans notre protocole nous nous sommes basés sur les outils ApacheBench et Siege. SCHEMAS Connexions Utilisateurs PROTOCOLE Le protocole nous permet d obtenir un détail des performances globales des serveurs. Il nous permettra de voir quelle technologie de serveur nous allons adopter. Les différents tests ont été effectué sur un code statique (HTML) et dynamique (PHP). Nous simulerons l envoie de 8000 requêtes en tous pour le code HTML et 1000 requêtes pour le PHP. Nous ferons varier le nombre de requêtes envoyées en parallèle pour évaluer les performances. 10

11 Avec Apachebench : ab n8000 -cx Le paramètre n définit le nombre de requête totale à envoyer. Le paramètre c correspond aux requêtes envoyées en parallèle. Avec Siege : siege -d0 -rx -cx Le paramètre r correspond au nombre de requête envoyées pour chaque utilisateur. Le paramètre c correspond au nombre d utilisateur que l on veut simuler. Ici pour obtenir un nombre total de requête égal à 8000, il faudra diviser 8000 par c. CONTENU STATIQUE SIEGE Ce graphique nous montre la performance globale des serveurs, leur facilité à traiter les requêtes rapidement. 35 Performance serveur Concurrency APACHE 0,97 5,79 19,63 22,03 30,56 NGINX 0,94 5,78 14,2 9,78 15,45 LIGHTTPD 0,96 10,27 14,9 12,57 22,26 Nb Utilisateur 11

12 Le paramètre concurrency de Siege correspond au nombre moyen de connexions simultanées traitées par le serveur. Plus ce nombre est petit plus le serveur traite efficacement les requêtes des utilisateurs. Plus ce nombre est grand moins le serveur est performant car il met du temps à répondre par rapport aux requêtes entrantes. Il s agit d un paramètre significatif des performances d un serveur. En abscisse nous avons le nombre d utilisateurs. Nous constatons que les serveurs NGINX et LIGHTTPD se comportent mieux que le serveur APACHE sur ce test. Ce graphe nous montre une moyenne des temps pour répondre à chaque requête simultanée des utilisateurs. 0,14 0,12 Temps de réponse Temps deréponse en s 0,1 0,08 0,06 0,04 0, APACHE 0 0,01 0,03 0,07 0,12 NGINX 0 0,01 0,02 0,04 0,03 LIGHTTPD 0 0,01 0,02 0,04 0,04 Nb Utilisateur En abscisse nous avons toujours le nombre d utilisateurs, en ordonnée nous avons le temps de traitement moyen des requêtes. On relève le temps de réponse de chaque serveur. La performance est ici inversement proportionnelle à l ordonnée. NGINX et LIGHTTPD résistent mieux au test qu APACHE. 12

13 APACHE BENCH Temps traitement Temps moyen de traitement en s APACHE 0,734 2,038 5,254 12,683 38,793 NGINX 0,571 1,955 4,891 9,855 19,439 LIGHTTPD 0,526 1,694 4,852 10,433 17,494 Nb Utilisateur En utilisant Apachebench nous voyons que le comportement pour ce test est similaire au test précédent avec siège. Nous constatons ici encore un meilleur comportement de NGINX et LIGHTTPD notamment lorsque le nombre d utilisateur augmente. Pour traiter du code statique nous remarquons que les serveurs NGINX et LIGHTTPD sont supérieurs à APACHE. Cela est probablement dû à la gestion asynchrone des requêtes clients de NGINX et LIGHTTPD. 13

14 CONTENU DYNAMIQUE SIEGE Performance serveur Concurrency APACHE 1 19,85 48,7 98,12 175,37 NGINX 1 19,84 49,72 95,33 176,28 LIGHTTPD 1 19,95 49,81 95,22 177,16 Les performances des trois serveurs sont globalement identiques. Cela va se jouer au niveau des temps de réponse. Temps de réponse Temps de réponse en s APACHE 0,09 0,9 2,22 4,08 8,12 NGINX 0,07 0,92 2,3 4,4 9,09 LIGHTTPD 0,08 0,91 2,29 4,6 9,51 Nb Utilisateur 14

15 Nous pouvons constater que les temps de réponse sont globalement identiques, Apache à une légère avance. Mais cette avance n est pas significative. APACHE BENCH Temps de traitement en ms Temps traitement Nb utilisateurs APACHE 89, , , , ,846 NGINX 91, , , , ,369 LIGHTTPD 94, , , , ,542 Ce graphique, comme le graphique précédent nous prouve une fois de plus que les performances d Apache ne sont pas significatives. EMPRUNTE MEMOIRE ET CPU Les tests effectués sur le code PHP ne nous ont pas montré de réelles différences significatives entre les serveurs. C est pour cela que nous avons effectué le test sur l utilisation de la mémoire et du processeur. 15

16 Utilisation mémoire RAM en Ko APACHE 1E+06 1E+06 1E NGINX 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 LIGHTTPD 2E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 1E+06 Nous pouvons constater qu Apache consomme beaucoup plus de mémoire par rapport à Nginx et Lighttpd Utilisation CPU CPU en % APACHE NGINX LIGHTTPD L utilisation du processeur quant à lui est identique pour les trois. Le processeur est sollicité du début jusqu à la fin du test. 16

17 L évaluation du temps de réponse en dynamique nous montre que l avance d Apache sur Nginx et Lighttpd n est pas très importante. Etant donné que les performances de Nginx en statique sont, elles, significativement plus importantes que celle d Apache, et que l utilisation mémoire de Nginx est nettement plus satisfaisante que celle d Apache. Nous optons pour Nginx. 17

18 TESTS DE CHARGE INTRODUCTION Le test de charge va permettre de trouver le point limite ou les performances du serveur décroissent, il va permettre de trouver le nombre d utilisateur simultané maximum que le serveur physique peut supporter à l heure actuelle. Des diagnostiques de la mémoire RAM et du processeur seront également établis. PROTOCOLE Nous utiliserons l outil Siège pour simuler les connexions utilisateurs. Siège ira lire dans un fichier texte les requêtes effectuées par les utilisateurs. Ces requêtes solliciteront simultanément du code dynamique (code PHP) et statique (HTML). Pour cela deux scénarios ont été établis. SCENARIO 1 Le premier scénario à pour but de montrer les performances du serveur lors du traitement de fichier statique lourd (unique image lourde). Notre scénario 1 : (7,5 Mo) La première requête sollicitera le serveur Nginx pour le code PHP. La deuxième requête sollicite le serveur Nginx pour traiter le code statique contenant une image lourge de 7.5 Mo. Nous simulerons au total 1000 requêtes par ligne du fichier précédent. Nous ferons ensuite varié le paramètre «c» (nombres d utilisateurs) pour obtenir des résultats exploitable. Lancement du benchmark : siege -f scénario1 d0 r10 c200 En lançant Siege avec de tels paramètres, nous simulons la connexion de 200 utilisateurs, exécutant chacun 10 requêtes. Ce qui fait 2000 requêtes au total. 18

19 SCENARIO 2 Le second scénario à pour but de montrer les performances du serveur lors du traitement de plusieurs fichier statique léger (plusieurs image légère dont la taille totale fait 7.5 Mo). Notre scénario 2 : Mo Nous simulerons également 1000 requêtes par ligne du scénario, ce qui nous fait un total de requêtes. 19

20 DISPONIBILITE Disponibilité : c est le pourcentage de connexions socket réussies. Lorsqu une connexion socket est échouée, l utilisateur verra une page d erreur. Il est donc impératif de garder ce paramètre à 100% pour un serveur. 102 Disponibilité Scénario ,15 Scénario ,99 99,7 98,5 Nous pouvons constater que le scénario 1 est plus efficace que le scénario 2. Le scénario 1 peut supporter jusqu à 400 utilisateurs simultanées, tandis que le scénario 2 peut supporter un peu moins de 200 utilisateurs. Nous pouvons déjà dire que l utilisation de moins de requête malgré la taille du fichier recherché par celle-ci influe sur les performances d un serveur. Typiquement, un fichier de 7 Mo est traité plus rapidement que sept fichiers de 1 Mo. 20

21 TEMPS TOTAL DE DUREE DU TEST Temps total de durée du test Temps total en seconde Scénario 1 11,5 11,57 11,64 11,62 20,72 48,61 Scénario 2 53,32 54,97 57,62 57,88 67,2 70,9 Nous avons mesuré à chaque fois, le temps total de durée du test et nous pouvons constater que le scénario 1 (2 requêtes), est traité plus rapidement (il prend moins de temps). Pour conclure sur ces tests nous pouvons d ores et déjà avancer le fait que l utilisation d image fragmentée influe sur les performances du serveur. En effet mieux vaut exécuter 1 seule requête de grosse taille plutôt que plusieurs de petite taille. Ces conclusions permettront d avancer sur la démarche de développement qu il faudra adopter (utilisation de sprite). 21

22 UTILISATION MEMOIRE Le scénario 1 étant celui que nous allons adopter, nous avons relevé son emprunte mémoire lors de son test. Nous pouvons conclure que la quantité de RAM pour le serveur est correcte car elle ne descend pas en dessous de 1,30 Go. Une mémoire RAM disponible de 1.3 Go est amplement suffisant pour le serveur. RAM en Ko mémoire libre Temps en s mémoire libre 22

23 UTILISATION CPU Ce graphique nous montre bien que lors du test le processeur du serveur est sollicité jusqu à atteindre 0% de processeur non utilisé. Le processeur travaille à fond quasiment du début jusqu à la fin du test. Nous pouvons en conclure que le processeur actuel n est pas suffisamment performant pour répondre aux besoins en ressource nécessaire. % 120 % CPU libre % CPU libre Temps en s 23

24 ESTIMATION Le cahier des charges sert, à partir de notre configuration matérielle de test, d estimer nos futurs besoins en termes de mémoire et de puissance processeur en fonction du nombre d utilisateurs. Nous avons définit plus haut la limite du nombre d utilisateur que le serveur peut supporter : 400 utilisateurs. Regardons maintenant combien de bogomips (millions d instructions par seconde), combien de mémoire RAM, chaque utilisateur consommera. Pour cela nous regardons sur notre serveur sa puissance de calcul : cat /proc/cpuinfo bogomips : bogomips sera utilisé pour 400 utilisateurs. Ce qui nous donne bogomips par utilisateur. Pour l utilisation de la mémoire nous reprenons les résultats obtenus page 22. Mémoire libre (point critique) : ko = 1.33 Go Mémoire totale : 2 go Mémoire utilisée : = 0.67 Go = 670 Mo pour 400 utilisateurs Pour 1 utilisateur = 670/400 = 1,675 Mo 24

25 CONCLUSION Nous avons pus déterminer dans un premier temps quelle technologie de serveur web nous allons adopter pour héberger le jeu. Après différents tests significatifs nous avons conclu que la solution Nginx était la plus intéressante. Elle est notamment supérieure pour le traitement de fichiers statiques et plus intéressante en terme d emprunte mémoire pour le traitement de fichiers dynamiques. Nous avons déterminé grâce à notre serveur de test les dimensions idéales d un serveur futur en fonction du nombre d utilisateurs. Nous avons également prouvé que le serveur est plus performant lorsqu il y a moins de requête à traiter. Cela nous indique que pour la partie modélisation et codage, l utilisation de sprite est vivement conseillée. Ce cahier des charges nous permettra au second semestre de pouvoir effectué l optimisation, la configuration poussée de notre serveur. 25