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 ?
Ici http://wwwsearch.sourceforge.net/ tu trouveras une librairie intéressante pour tout ce qui est test d'appli web.
Sinon, une liste d'outils : http://www.opensourcetesting.org/performance.php
-- William Dodé - http://flibuste.net Développeur informatique indépendant
Méta-MCI
Bonjour !
La question est intéressante.
Mais, je m'interroge, sur plusieurs points : - si le test a lieu sur la même machine que le serveur Web, ne risque-t'on pas de tomber sur les limites de l'OS, pour les sockets ? Certains OS limitent volontairement le nombre de connexions simultanées. - si le test utilise une autre machine (en réseau local, par exemple), ne risque-t'on, pas de tomber sur les mêmes limites ? D'où impossibilité de tester plus d'un certain nombre de connexions "externes". - si l'on utilise des machines "extérieures", à partir d'un seul lieu, ne risque-t'on pas de buter sur des contraintes des routeurs ? (et, éventuellement, d'un parefeu sortant) ; les limites des connexions Internet utilisées ne risquent-elles pas de "brider" le test, le rendant ainsi non fiable ?
En fait, je m'étais posé la question, et n'avais rien trouvé de mieux que de demander à plusieurs participants d'un (autre) newsgroup de lancer un script de test à une heure précise. Mais le résultat est peu convainquant (même si rassurant).
@+
MCI
Bonjour !
La question est intéressante.
Mais, je m'interroge, sur plusieurs points :
- si le test a lieu sur la même machine que le serveur Web, ne
risque-t'on pas de tomber sur les limites de l'OS, pour les sockets ?
Certains OS limitent volontairement le nombre de connexions simultanées.
- si le test utilise une autre machine (en réseau local, par exemple), ne
risque-t'on, pas de tomber sur les mêmes limites ? D'où impossibilité de
tester plus d'un certain nombre de connexions "externes".
- si l'on utilise des machines "extérieures", à partir d'un seul lieu, ne
risque-t'on pas de buter sur des contraintes des routeurs ? (et,
éventuellement, d'un parefeu sortant) ; les limites des connexions Internet
utilisées ne risquent-elles pas de "brider" le test, le rendant ainsi non
fiable ?
En fait, je m'étais posé la question, et n'avais rien trouvé de mieux que de
demander à plusieurs participants d'un (autre) newsgroup de lancer un script
de test à une heure précise. Mais le résultat est peu convainquant (même si
rassurant).
Mais, je m'interroge, sur plusieurs points : - si le test a lieu sur la même machine que le serveur Web, ne risque-t'on pas de tomber sur les limites de l'OS, pour les sockets ? Certains OS limitent volontairement le nombre de connexions simultanées. - si le test utilise une autre machine (en réseau local, par exemple), ne risque-t'on, pas de tomber sur les mêmes limites ? D'où impossibilité de tester plus d'un certain nombre de connexions "externes". - si l'on utilise des machines "extérieures", à partir d'un seul lieu, ne risque-t'on pas de buter sur des contraintes des routeurs ? (et, éventuellement, d'un parefeu sortant) ; les limites des connexions Internet utilisées ne risquent-elles pas de "brider" le test, le rendant ainsi non fiable ?
En fait, je m'étais posé la question, et n'avais rien trouvé de mieux que de demander à plusieurs participants d'un (autre) newsgroup de lancer un script de test à une heure précise. Mais le résultat est peu convainquant (même si rassurant).
@+
MCI
Olivier Ravard
Méta-MCI wrote:
Bonjour !
La question est intéressante.
Mais, je m'interroge, sur plusieurs points : - si le test a lieu sur la même machine que le serveur Web, ne risque-t'on pas de tomber sur les limites de l'OS, pour les sockets ? Certains OS limitent volontairement le nombre de connexions simultanées. - si le test utilise une autre machine (en réseau local, par exemple), ne risque-t'on, pas de tomber sur les mêmes limites ? D'où impossibilité de tester plus d'un certain nombre de connexions "externes". - si l'on utilise des machines "extérieures", à partir d'un seul lieu, ne risque-t'on pas de buter sur des contraintes des routeurs ? (et, éventuellement, d'un parefeu sortant) ; les limites des connexions Internet utilisées ne risquent-elles pas de "brider" le test, le rendant ainsi non fiable ?
A ce propos, quelqu'un aurait-il expérimenté si une appli faite avec cherrypy tient correctement la charge ? J'ai << cru >> constater des blocages lors de requêtes simulatées ...
En fait, je m'étais posé la question, et n'avais rien trouvé de mieux que de demander à plusieurs participants d'un (autre) newsgroup de lancer un script de test à une heure précise. Mais le résultat est peu convainquant (même si rassurant).
@+
MCI
Méta-MCI wrote:
Bonjour !
La question est intéressante.
Mais, je m'interroge, sur plusieurs points :
- si le test a lieu sur la même machine que le serveur Web, ne
risque-t'on pas de tomber sur les limites de l'OS, pour les sockets ?
Certains OS limitent volontairement le nombre de connexions simultanées.
- si le test utilise une autre machine (en réseau local, par exemple),
ne risque-t'on, pas de tomber sur les mêmes limites ? D'où
impossibilité de tester plus d'un certain nombre de connexions "externes".
- si l'on utilise des machines "extérieures", à partir d'un seul lieu,
ne risque-t'on pas de buter sur des contraintes des routeurs ? (et,
éventuellement, d'un parefeu sortant) ; les limites des connexions
Internet utilisées ne risquent-elles pas de "brider" le test, le rendant
ainsi non fiable ?
A ce propos, quelqu'un aurait-il expérimenté si une appli faite avec cherrypy
tient correctement la charge ? J'ai << cru >> constater des blocages lors de requêtes
simulatées ...
En fait, je m'étais posé la question, et n'avais rien trouvé de mieux
que de demander à plusieurs participants d'un (autre) newsgroup de
lancer un script de test à une heure précise. Mais le résultat est peu
convainquant (même si rassurant).
Mais, je m'interroge, sur plusieurs points : - si le test a lieu sur la même machine que le serveur Web, ne risque-t'on pas de tomber sur les limites de l'OS, pour les sockets ? Certains OS limitent volontairement le nombre de connexions simultanées. - si le test utilise une autre machine (en réseau local, par exemple), ne risque-t'on, pas de tomber sur les mêmes limites ? D'où impossibilité de tester plus d'un certain nombre de connexions "externes". - si l'on utilise des machines "extérieures", à partir d'un seul lieu, ne risque-t'on pas de buter sur des contraintes des routeurs ? (et, éventuellement, d'un parefeu sortant) ; les limites des connexions Internet utilisées ne risquent-elles pas de "brider" le test, le rendant ainsi non fiable ?
A ce propos, quelqu'un aurait-il expérimenté si une appli faite avec cherrypy tient correctement la charge ? J'ai << cru >> constater des blocages lors de requêtes simulatées ...
En fait, je m'étais posé la question, et n'avais rien trouvé de mieux que de demander à plusieurs participants d'un (autre) newsgroup de lancer un script de test à une heure précise. Mais le résultat est peu convainquant (même si rassurant).
@+
MCI
MC
Re !
J'ai fait un petit test, à l'automne dernier : - Cherrypy sous windows-2003-server-web-edition sur une machine reliée à Internet par une liaison à 100 Mbd. - tests réalisés à partir de 4 sites utilisant des liaisons ADSL (128k/512k 1M/8M 1M/10M) et SDSL (2M/2M) - chaque sites lançait 2 ou 3 connexions simultanées - le test consistait à effectuer une requête sur les code postaux d'un département, dans une table (de 56000 enregistrements) gérée par le BDE (Borland), piloté par le même script Python qui utilise Cherrypy. - le résultat consistait en une page Html, contenant un tableau limité à 1000 lignes.
Performances : le temps de réponse (2 secondes, mais 3 pour la liaison 128/512) a toujours été stable, quelque soit le nombre de connexions.
Donc, pour moi, Cherrypy tient vraiment la route. En plus, la dernière version est donnée pour être 2 ou 3 fois plus rapide.
-- @-salutations
Michel Claveau
Re !
J'ai fait un petit test, à l'automne dernier :
- Cherrypy sous windows-2003-server-web-edition sur une machine
reliée à Internet par une liaison à 100 Mbd.
- tests réalisés à partir de 4 sites utilisant des liaisons ADSL
(128k/512k 1M/8M 1M/10M) et SDSL (2M/2M)
- chaque sites lançait 2 ou 3 connexions simultanées
- le test consistait à effectuer une requête sur les code postaux
d'un département, dans une table (de 56000 enregistrements) gérée par
le BDE (Borland), piloté par le même script Python qui utilise
Cherrypy.
- le résultat consistait en une page Html, contenant un tableau
limité à 1000 lignes.
Performances : le temps de réponse (2 secondes, mais 3 pour la liaison
128/512) a toujours été stable, quelque soit le nombre de connexions.
Donc, pour moi, Cherrypy tient vraiment la route. En plus, la dernière
version est donnée pour être 2 ou 3 fois plus rapide.
J'ai fait un petit test, à l'automne dernier : - Cherrypy sous windows-2003-server-web-edition sur une machine reliée à Internet par une liaison à 100 Mbd. - tests réalisés à partir de 4 sites utilisant des liaisons ADSL (128k/512k 1M/8M 1M/10M) et SDSL (2M/2M) - chaque sites lançait 2 ou 3 connexions simultanées - le test consistait à effectuer une requête sur les code postaux d'un département, dans une table (de 56000 enregistrements) gérée par le BDE (Borland), piloté par le même script Python qui utilise Cherrypy. - le résultat consistait en une page Html, contenant un tableau limité à 1000 lignes.
Performances : le temps de réponse (2 secondes, mais 3 pour la liaison 128/512) a toujours été stable, quelque soit le nombre de connexions.
Donc, pour moi, Cherrypy tient vraiment la route. En plus, la dernière version est donnée pour être 2 ou 3 fois plus rapide.
-- @-salutations
Michel Claveau
jp.camguilhem
On 8 mai, 01:56, Pensee wrote:
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 ?
Si tu as apache d' installé sur les machines clientes qui doivent faire tes tests, tu as le module apache bench qui te permet entre autres de gérer les clients et les requêtes simultanées : sudo ab -n 100 -c 100 http://tonsupersite.com/
Par contre tu ne sauras pas où ton application se traine si tel était le cas. Il te faudra mesurer en interne.
les principales sources d'optimisation sont : vérifier la bonne négociation des objets en cache du coté client le caching coté serveur des fichiers css, images et autres javascript. Si tu as apache en frontal de ton application, il fait celà très bien (mod_cache) tu peux bien entendu aussi diminuer la taille de ces derniers(virer les sauts de ligne etc..., diminuer la taille des images, compresser ces derniers.
Le caching des requêtes sql s'il y en a. Les languages de templates ne sont pas tous égaux en termes de performances etc...
Voilà pour un début.
@++
On 8 mai, 01:56, Pensee <aneg...@gmail.com> wrote:
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 ?
Si tu as apache d' installé sur les machines clientes qui doivent
faire tes tests, tu as le module apache bench qui te permet entre
autres de gérer les clients et les requêtes simultanées :
sudo ab -n 100 -c 100 http://tonsupersite.com/
Par contre tu ne sauras pas où ton application se traine si tel était
le cas.
Il te faudra mesurer en interne.
les principales sources d'optimisation sont :
vérifier la bonne négociation des objets en cache du coté client
le caching coté serveur des fichiers css, images et autres javascript.
Si tu as apache en frontal de ton application, il fait celà très bien
(mod_cache)
tu peux bien entendu aussi diminuer la taille de ces derniers(virer
les sauts de ligne etc..., diminuer la taille des images, compresser
ces derniers.
Le caching des requêtes sql s'il y en a.
Les languages de templates ne sont pas tous égaux en termes de
performances etc...
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 ?
Si tu as apache d' installé sur les machines clientes qui doivent faire tes tests, tu as le module apache bench qui te permet entre autres de gérer les clients et les requêtes simultanées : sudo ab -n 100 -c 100 http://tonsupersite.com/
Par contre tu ne sauras pas où ton application se traine si tel était le cas. Il te faudra mesurer en interne.
les principales sources d'optimisation sont : vérifier la bonne négociation des objets en cache du coté client le caching coté serveur des fichiers css, images et autres javascript. Si tu as apache en frontal de ton application, il fait celà très bien (mod_cache) tu peux bien entendu aussi diminuer la taille de ces derniers(virer les sauts de ligne etc..., diminuer la taille des images, compresser ces derniers.
Le caching des requêtes sql s'il y en a. Les languages de templates ne sont pas tous égaux en termes de performances etc...
Voilà pour un début.
@++
Olivier Ravard
MC wrote:
Re !
J'ai fait un petit test, à l'automne dernier : - Cherrypy sous windows-2003-server-web-edition sur une machine reliée à Internet par une liaison à 100 Mbd. - tests réalisés à partir de 4 sites utilisant des liaisons ADSL (128k/512k 1M/8M 1M/10M) et SDSL (2M/2M) - chaque sites lançait 2 ou 3 connexions simultanées - le test consistait à effectuer une requête sur les code postaux d'un département, dans une table (de 56000 enregistrements) gérée par le BDE (Borland), piloté par le même script Python qui utilise Cherrypy. - le résultat consistait en une page Html, contenant un tableau limité à 1000 lignes.
Performances : le temps de réponse (2 secondes, mais 3 pour la liaison 128/512) a toujours été stable, quelque soit le nombre de connexions.
Donc, pour moi, Cherrypy tient vraiment la route. En plus, la dernière version est donnée pour être 2 ou 3 fois plus rapide.
Merci pour ces infos. Ceci confirme la bonne opinion que j'ai sur ce produit.
MC wrote:
Re !
J'ai fait un petit test, à l'automne dernier :
- Cherrypy sous windows-2003-server-web-edition sur une machine reliée
à Internet par une liaison à 100 Mbd.
- tests réalisés à partir de 4 sites utilisant des liaisons ADSL
(128k/512k 1M/8M 1M/10M) et SDSL (2M/2M)
- chaque sites lançait 2 ou 3 connexions simultanées
- le test consistait à effectuer une requête sur les code postaux d'un
département, dans une table (de 56000 enregistrements) gérée par le BDE
(Borland), piloté par le même script Python qui utilise Cherrypy.
- le résultat consistait en une page Html, contenant un tableau limité
à 1000 lignes.
Performances : le temps de réponse (2 secondes, mais 3 pour la liaison
128/512) a toujours été stable, quelque soit le nombre de connexions.
Donc, pour moi, Cherrypy tient vraiment la route. En plus, la dernière
version est donnée pour être 2 ou 3 fois plus rapide.
Merci pour ces infos. Ceci confirme la bonne opinion que j'ai sur ce produit.
J'ai fait un petit test, à l'automne dernier : - Cherrypy sous windows-2003-server-web-edition sur une machine reliée à Internet par une liaison à 100 Mbd. - tests réalisés à partir de 4 sites utilisant des liaisons ADSL (128k/512k 1M/8M 1M/10M) et SDSL (2M/2M) - chaque sites lançait 2 ou 3 connexions simultanées - le test consistait à effectuer une requête sur les code postaux d'un département, dans une table (de 56000 enregistrements) gérée par le BDE (Borland), piloté par le même script Python qui utilise Cherrypy. - le résultat consistait en une page Html, contenant un tableau limité à 1000 lignes.
Performances : le temps de réponse (2 secondes, mais 3 pour la liaison 128/512) a toujours été stable, quelque soit le nombre de connexions.
Donc, pour moi, Cherrypy tient vraiment la route. En plus, la dernière version est donnée pour être 2 ou 3 fois plus rapide.
Merci pour ces infos. Ceci confirme la bonne opinion que j'ai sur ce produit.
Mihamina (R12y) Rakotomandimby
Pensee - :
Bonjour,
Bonjour,
J'aimerais tester la capacite de monte en charge de mon application en python.
Je me souviens que S Fermigier de chez Nuxeo en avait fait un pour benchmarker CPS il y a 2 ans. En demandant sur la ML user-fr de CPS, tu devrait avoir plus de précisions.
J'aimerais tester la capacite de monte en charge de mon application en
python.
Je me souviens que S Fermigier de chez Nuxeo en avait fait un pour
benchmarker CPS il y a 2 ans.
En demandant sur la ML user-fr de CPS, tu devrait avoir plus de précisions.
J'aimerais tester la capacite de monte en charge de mon application en python.
Je me souviens que S Fermigier de chez Nuxeo en avait fait un pour benchmarker CPS il y a 2 ans. En demandant sur la ML user-fr de CPS, tu devrait avoir plus de précisions.
Bruno Desthuilliers
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 ?
Pour du test "boite noire", il y a apache bench et pas mal d'autres
outils - le fait que ton appli soit en Python n'a pas d'incidence de ce point de vue.
Pour du test "boite blanche", tu peux toujours faire les mêmes tests qu'en boite noire en faisant tourner ton appli sous contrôle d'un profiler (modules profile, cProfile ou hotshot). Cela aura bien sûr une incidence sur les perfs absolues (comparativement aux mêmes tests sans le profiler), mais permettra de savoir où ça coince le plus.
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 ?
Pour du test "boite noire", il y a apache bench et pas mal d'autres
outils - le fait que ton appli soit en Python n'a pas d'incidence de ce
point de vue.
Pour du test "boite blanche", tu peux toujours faire les mêmes tests
qu'en boite noire en faisant tourner ton appli sous contrôle d'un
profiler (modules profile, cProfile ou hotshot). Cela aura bien sûr une
incidence sur les perfs absolues (comparativement aux mêmes tests sans
le profiler), mais permettra de savoir où ça coince le plus.
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 ?
Pour du test "boite noire", il y a apache bench et pas mal d'autres
outils - le fait que ton appli soit en Python n'a pas d'incidence de ce point de vue.
Pour du test "boite blanche", tu peux toujours faire les mêmes tests qu'en boite noire en faisant tourner ton appli sous contrôle d'un profiler (modules profile, cProfile ou hotshot). Cela aura bien sûr une incidence sur les perfs absolues (comparativement aux mêmes tests sans le profiler), mais permettra de savoir où ça coince le plus.
Bruno Desthuilliers
Bonjour !
La question est intéressante.
Mais, je m'interroge, sur plusieurs points : - si le test a lieu sur la même machine que le serveur Web, ne risque-t'on pas de tomber sur les limites de l'OS, pour les sockets ?
Pas seulement. Le processus de test requiert également des ressources mémoires ou CPU qui ne sont par conséquent plus disponibles pour le processus à tester... Sur des appli gourmandes en ressources (je pense notamment aux usines à gaz comme Plone ou feu CPS), ça peut faire une différence notable (expérience personnelle).
Certains OS limitent volontairement le nombre de connexions simultanées. - si le test utilise une autre machine (en réseau local, par exemple), ne risque-t'on, pas de tomber sur les mêmes limites ? D'où impossibilité de tester plus d'un certain nombre de connexions "externes". - si l'on utilise des machines "extérieures", à partir d'un seul lieu, ne risque-t'on pas de buter sur des contraintes des routeurs ? (et, éventuellement, d'un parefeu sortant) ; les limites des connexions Internet utilisées ne risquent-elles pas de "brider" le test, le rendant ainsi non fiable ?
En fait, je m'étais posé la question, et n'avais rien trouvé de mieux que de demander à plusieurs participants d'un (autre) newsgroup de lancer un script de test à une heure précise. Mais le résultat est peu convainquant (même si rassurant).
Il est de toutes façons irréaliste d'espérer simuler crédiblement le comportement effectif des internautes. L'avantage du test automatisé est sa répétabilité. Cela permet d'une part de répérer les requêtes les plus coûteuses (après quoi on peut sortir le profileur), et d'autre part de vérifier les effets d'une modification de code, de paramétrage ou d'environnement. Dans tous les cas, il s'agit surtout d'avoir d'une part un ordre de grandeur concernant les capacités à tenir la montée en charge et d'autre part une connaissance un tant soit peu fiable des paramètres influant ces capacités.
Bonjour !
La question est intéressante.
Mais, je m'interroge, sur plusieurs points :
- si le test a lieu sur la même machine que le serveur Web, ne
risque-t'on pas de tomber sur les limites de l'OS, pour les sockets ?
Pas seulement. Le processus de test requiert également des ressources
mémoires ou CPU qui ne sont par conséquent plus disponibles pour le
processus à tester... Sur des appli gourmandes en ressources (je pense
notamment aux usines à gaz comme Plone ou feu CPS), ça peut faire une
différence notable (expérience personnelle).
Certains OS limitent volontairement le nombre de connexions simultanées.
- si le test utilise une autre machine (en réseau local, par exemple),
ne risque-t'on, pas de tomber sur les mêmes limites ? D'où
impossibilité de tester plus d'un certain nombre de connexions "externes".
- si l'on utilise des machines "extérieures", à partir d'un seul lieu,
ne risque-t'on pas de buter sur des contraintes des routeurs ? (et,
éventuellement, d'un parefeu sortant) ; les limites des connexions
Internet utilisées ne risquent-elles pas de "brider" le test, le rendant
ainsi non fiable ?
En fait, je m'étais posé la question, et n'avais rien trouvé de mieux
que de demander à plusieurs participants d'un (autre) newsgroup de
lancer un script de test à une heure précise. Mais le résultat est peu
convainquant (même si rassurant).
Il est de toutes façons irréaliste d'espérer simuler crédiblement le
comportement effectif des internautes. L'avantage du test automatisé est
sa répétabilité. Cela permet d'une part de répérer les requêtes les plus
coûteuses (après quoi on peut sortir le profileur), et d'autre part de
vérifier les effets d'une modification de code, de paramétrage ou
d'environnement. Dans tous les cas, il s'agit surtout d'avoir d'une part
un ordre de grandeur concernant les capacités à tenir la montée en
charge et d'autre part une connaissance un tant soit peu fiable des
paramètres influant ces capacités.
Mais, je m'interroge, sur plusieurs points : - si le test a lieu sur la même machine que le serveur Web, ne risque-t'on pas de tomber sur les limites de l'OS, pour les sockets ?
Pas seulement. Le processus de test requiert également des ressources mémoires ou CPU qui ne sont par conséquent plus disponibles pour le processus à tester... Sur des appli gourmandes en ressources (je pense notamment aux usines à gaz comme Plone ou feu CPS), ça peut faire une différence notable (expérience personnelle).
Certains OS limitent volontairement le nombre de connexions simultanées. - si le test utilise une autre machine (en réseau local, par exemple), ne risque-t'on, pas de tomber sur les mêmes limites ? D'où impossibilité de tester plus d'un certain nombre de connexions "externes". - si l'on utilise des machines "extérieures", à partir d'un seul lieu, ne risque-t'on pas de buter sur des contraintes des routeurs ? (et, éventuellement, d'un parefeu sortant) ; les limites des connexions Internet utilisées ne risquent-elles pas de "brider" le test, le rendant ainsi non fiable ?
En fait, je m'étais posé la question, et n'avais rien trouvé de mieux que de demander à plusieurs participants d'un (autre) newsgroup de lancer un script de test à une heure précise. Mais le résultat est peu convainquant (même si rassurant).
Il est de toutes façons irréaliste d'espérer simuler crédiblement le comportement effectif des internautes. L'avantage du test automatisé est sa répétabilité. Cela permet d'une part de répérer les requêtes les plus coûteuses (après quoi on peut sortir le profileur), et d'autre part de vérifier les effets d'une modification de code, de paramétrage ou d'environnement. Dans tous les cas, il s'agit surtout d'avoir d'une part un ordre de grandeur concernant les capacités à tenir la montée en charge et d'autre part une connaissance un tant soit peu fiable des paramètres influant ces capacités.
