Monter en charge d'une application web en python

Bonjour,

J'aimerais tester la capacite de monte en charge de mon application en
python.

Est ce qu'il existe des bibliotheques qui permettent de faire ce type
de travail ?

- apache bench donne rapidement des éléments.
- Pour avoir des graphiques voir http://www.slamd.com/ et une archi de
test un peu évolué.
- http://www.websiteoptimization.com/services/analyze/ est interessant
il permet de tester son site depuis l'extérieur avec quelques conseils
en +. (inclu dans la développer toolbar de firefox )
- http://www.ircache.net/cgi-bin/cacheability.py permet de tester la
cachabilité de ces pages.

Bonne soirée.

Merci pour toutes reponses vous aurez des nouvelles de moi bientot :)

Bonjour !

J'ai été intrigué par le lien que tu cites
(http://www.websiteoptimization.com/services/analyze/), car offrir un
service de test sur Internet pourrait être une bonne idée.

Malheureusement, les résultats ne sont pas terribles. J'ai testé avec
un serveur web basé sur SimpleHTTPServer (librairie Python standard),
qui a la particularité de ne gérer qu'une seule connexion à la fois.

Cela n'a pas gêné le site indiqué plus haut, qui congratule sur
l'optimisation du site.

Bref, pour tester une montée en charge, c'est pas vraiment ça...


De toutes façons, comme je l'ai affirmé plus haut (confirmé par Bruno
D.) toute solution de test de montée en charge qui fait l'impasse sur
la taille des tuyaux et de l'architecture, côté testeur, sont à
déconsidérer. En plus, cela émet des doutes sur la capacité de
conception des auteurs de ces outils.





--
@-salutations

Michel Claveau

Bonjour

Bref, pour tester une montée en charge, c'est pas vraiment ça...

Ca donne des éléments de réflexions sur la page.(compression , taille
des images ...). Le but n'est pas de charger son appli à distance.


Après si la page est optimisée on a plus de chance que la montée en
charge se passe bien. Dans notre cas le code zope a été revu et c'était
beaucoup mieux.

Après si il suffisait d'une page de test pour dire ce qu'il faut faire,
il y aurait beaucoup moins d'intégrateurs....

De toutes façons, comme je l'ai affirmé plus haut (confirmé par Bruno
D.) toute solution de test de montée en charge qui fait l'impasse sur la
taille des tuyaux et de l'architecture, côté testeur, sont à
déconsidérer.

On est d'accord.
Slamd et ab sont dans ce registre.
Le résultat d'un bench est lié à l'environnement et à la cible fixée au
départ. Pour être sérieux ( je n'ai pas toujours les moyens de mes
ambitions... ) il faut un environnement qui donne des résultats fidèles
et dédiée aux tests.


En plus, cela émet des doutes sur la capacité de

conception des auteurs de ces outils.

peut être un peu dur pour cette page.... Elle donne quelques conseils ,
après chacun est libre d'adhérer ou non c'est pour ca qu'on fait du
Python non ?

BWE


NB:

Un collègue m'a alerté sur fasterfox:

http://fasterfox.mozdev.org/
+ petite discussion ici:
http://forum.alsacreations.com/topic-9-9516-1-Extension-Fasterfox--une-plaie-pour-les-serveurs-.html

L'optimisation n'est pas que coté serveur.

Bonjour

Bref, pour tester une montée en charge, c'est pas vraiment ça...

Ca donne des éléments de réflexions sur la page.(compression , taille
des images ...). Le but n'est pas de charger son appli à distance.


Après si la page est optimisée on a plus de chance que la montée en
charge se passe bien. Dans notre cas le code zope a été revu et c'était
beaucoup mieux.

Les appli Zope tendent à être gourmandes en ressources, particulièrement
celles basées sur le CMF (Plone et feu CPS). Une solution efficace (par
expérience) est de faire tourner une paire d'instances Zope (connectées
à une même ZODB via Zeo) sur un (ou +) serveur(s) dédié(s) avec une
copieuse quantité de RAM, et de mettre en frontal un autre serveur avec
Squid (ou Apache+Squid s'il y a d'autres applis web à servir sur le port
80). Evidemment, ça ne dispense pas de profiler d'abord l'appli pour
identifier et corriger les "points chauds"...

Les appli Zope tendent à être gourmandes en ressources, particulièrement
celles basées sur le CMF (Plone et feu CPS).

feu CPS est encore vivant pour nous du moins.... Pas trop envie de
migrer vers le lourd Java.

Une solution efficace (par

expérience) est de faire tourner une paire d'instances Zope (connectées
à une même ZODB via Zeo) sur un (ou +) serveur(s) dédié(s) avec une
copieuse quantité de RAM, et de mettre en frontal un autre serveur avec
Squid (ou Apache+Squid s'il y a d'autres applis web à servir sur le port
80). Evidemment, ça ne dispense pas de profiler d'abord l'appli pour
identifier et corriger les "points chauds"...

J'ai adopté varnish en remplacement de squid sur les conseils de la
liste CPS. Eh en effet il est très très rapide.( notre archi = cisco CSS
+ varnish + apache mod_rewrite+ mod_proxy_balance + 1 zeo/cpu )

Zeo c'est bien mais un ab ne donne pas plus de 6/7 requêtes/s ( la page
d'accueil est néamoins assez lourde ).
Avec varnish sans compression on arrive à 5000 requêtes/s contre 2800r/s
avec squid sur un quadripro et 16 GO de mem.


L'optimisation du site pour des utilisateurs authentifiés est un vrai
casse tête. On ne cache que les images.
L'utilisation de vary: Cookie + squid , un énorme cache doit répondre
à ce type de problématique avec des contenus fortement liés à un
utilisateur.

Php fait surement mieux ? , je serais curieux de savoir quelle est
l'archi proposée en règle générale pour php afin de la comparer à celle
des applis Python.
Un ab rapide sur une appli php m'a donné 250r/s.

Bonne soirée

Les appli Zope tendent à être gourmandes en ressources,
particulièrement celles basées sur le CMF (Plone et feu CPS).

feu CPS est encore vivant pour nous du moins.... Pas trop envie de
migrer vers le lourd Java.

<aol />

(snip)

J'ai adopté varnish en remplacement de squid sur les conseils de la
liste CPS.

Connais pas. Faudra que je regarde...

Eh en effet il est très très rapide.( notre archi = cisco CSS
+ varnish + apache mod_rewrite+ mod_proxy_balance + 1 zeo/cpu )
(snip)

L'optimisation du site pour des utilisateurs authentifiés est un vrai
casse tête. On ne cache que les images.

Le RAMCache peut être une bonne solution pour les calculs un peu
intensifs...

Php fait surement mieux ?,

Difficile de comparer des pommes et des oranges... Il faudrait comparer
deux "page" avec les mêmes traitements, l'une en PHP et l'autre en
Python + mod_python. Ce qui nous éloigne beaucoup des problématiques
spécifiques à Zope et plus particulièrement au CMF (pour ce que ça vaut,
un dev spécifique Zope sans CMF et avec une base PostgreSQL pour là où
ça semble indiqué ne pose pas du tout les mêmes problèmes de perf et de
montée en charge qu'une appli Plone ou CPS).

je serais curieux de savoir quelle est
l'archi proposée en règle générale pour php
afin de la comparer à celle
des applis Python.

Ca dépend des applis PHP et des applis Python. Mais une chose est sûre:
si tu voulais faire en PHP quelque chose de comparable à Zope (ce qui
relève peu ou prou de la science-fiction AMHA), tu n'aurais certainement
pas de meilleurs résultats de ce point de vue...