Nous sommes toujours dans nos bench. Avant de repasser sur ab, nous avons testé l’outil siege. Siege est un outil de test et benchmark. Il peut attaquer une URL unique avec un nombre défini d’utilisateurs simulés. Le programme indique le nombre total de visites enregistrées, les octets transférés, les temps de réponse et le nombre de requête par seconde.

La base du test est de lancer en parallèle 10,20 ... 150 clients sur la même page (une copie de spip-blog). On cherche ici à mesurer une page mise en cache.

Que ressortir de ce « beau » graphique :

 La courbe jaune semble la plus favorable. C’est la courbe qui représente le nombre de requêtes par seconde avec le plugin memoization activé et configuré pour utiliser xcache.

 On remarque que Cache Cool n’apporte pas de gain de performance en capacité. C’est attendu : Cache Cool donne l’impression que le site va vite en envoyant du contenu plus rapidement, mais au final, il fait les mêmes mises à jour des pages vues, sans gain pour le serveur. Au contraire, on s’aperçoit ici que la capacité se dégrade sous forte sollicitation. Cela s’explique ici par une gestion perfectible de la file de travail par le plugin Job-Queue sous forte contrainte et en SQLite. Il apparaît à l’analyse des logs que des tâches identiques sont exécutées plusieurs fois en parallèle par des processus concurrents. Combiné avec une lenteur relative de SQLite en modification de la base de données, cela donne donc un résultat décevant sous forte contrainte.

De plus, il faut éclairer les résultats de performance par le graphique ci-dessous qui représente la proportion de requêtes en erreurs.

Il semble ici à première vue que c’est mémoization+filecache qui réussit le mieux.

runSiege
Script bash de lancement de Siege
siegerc.txt
fichier de config Siege

Deux points sont à creuser pour expliquer ces résultats :
 les « sieges » sont lancés depuis notre propre ordinateur, et donc derrière un FAI.
 le MaxClient Apache n’est pas encore optimisé sur notre configuration serveur.

Il convient donc de suivre ces 2 pistes tests avant de conclure définitivement.

photo par cseeman

[Edit : la suite dans Les différentes méthodes de Cache pour SPIP - Episode II ]

Vos commentaires

  • Le 11 février 2011 à 09:21, par Fil En réponse à : Les différentes de méthodes de Cache pour SPIP

    De quelles erreurs s’agit-il ? Et qu’est-ce qui les provoque ?

  • Le 11 février 2011 à 11:39, par Cédric Morin En réponse à : Les différentes de méthodes de Cache pour SPIP

    Les erreurs relevées ici par Siège correspondent à des Timeout serveur. Dans ce test il s’agit essentiellement de problèmes liés à la configuration MaxClient d’Apache : configuré trop haut, il laisse Apache lancer trop de clients, ce qui provoque une consommation mémoire excessive et un swap intensif. Cela se traduit par un allongement des délais de réponse, qui finissent par échouer en timeout.

    Il n’est pas exclus que nous ayons eu aussi des défaut liés à la connexion ADSL elle même. En particulier, nous avons voulu lancer ce même test depuis une connexion d’un autre FAI, et on constate que tout d’un coup toutes les requêtes sont en echec, comme si on déclenchait une protection contre les attaques sortantes de type DOS chez le FAI.

    Pour la suite des tests, nous allons utiliser un autre serveur comme point de lancement des requêtes, en veillant à ce qu’il se trouve chez un autre hébergeur/réseau que le serveur que nous testons.

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom

Voir aussi...

Les méthodes de Cache pour SPIP - Episode III ( la revanche du cache-cool)

Lors de l’épisode précédent ( Les différentes méthodes de Cache pour SPIP - Episode II), nous avions vu que Cache-Cool n’était plus efficient au bout d’un certain nombre de requêtes en parallèle. Un peu (...)

Lire la suite
Formation SPIP pour les associations

Deux modules de formations web organisés par Ritimo autour de SPIP et de la distribution e-change. Les dates Ritimo organise deux journées de formations pour accompagner les associations dans la (...)

Lire la suite
En 2013 : Nursit, c’est encore mieux !

Chez Nursit, nous avons tellement la tête dans le guidon que nous avons failli oublier de vous souhaiter une bonne année 2013 pleine de succès, de réussite, et de bonheur ! En nous confiant (...)

Lire la suite