Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ludo06
Hello,
jeje900ss wrote:
Bonjour tous,
j'espère être sur le bon forum.
Ici ca doit etre OK (non?), tu devrais aussi t'abonner a bugtraq (cf recents bugs sur JavaMail) et suivre fr.comp.securite si tu veux etre un peu au courant d'autres aspects aussi importants que les performances ;-)
Je vais bientôt devoir passer en production un application WEB (Tomcat + Postgresql ).
Le problème c'est que je ne sais pas comment évaluer le matériel qui serait nécessaire pour que ça tienne la route. (mémoire, nbr de pc, etc..)
Je suis à la recherche de documents ou pistes qui me permettraient de faire un choix.
Je te conseille d'utiliser l'excellent logiciel libre JMeter
(http://jakarta.apache.org/jmeter/) pour tester l'application et de faire un benchmarking de ton application. J'espere que d'autres sauront t'indiquer aussi d'autres pistes, je serais ravi d'etoffer mes connaissances ou de corriger ma vision des choses.
Si tout s'est bien passe tu as normalement du modeliser des cas d'utilisation, il faudrait que tu les valides, par exemple en les executant une fois avec un Proxy JMeter puis en les rejouant automatiquement : c'est ce que l'on appelle un plan de test, cf http://jakarta.apache.org/jmeter/usermanual/index.html
Une fois cette etape faite, tu peux commencer a mesurer les performances, en utilisant des utilisateurs virtuels (thread Jmeter) qui jouent simultanement tes differents scenarios de tests et en regardant si c'est conforme aux exigences des clients (3s par page...). Tu peux faire des variantes distribuees mais je n'ai pas eu le temps de tester.
Pour dimensionner ton serveur, il faut que tu surveilles son fonctionnement, et que tu vois ou sont les points de congestion: reseau, memoire, bdd, disque, processeur,... Un tomcat lance en mode debug peut t'apporter des indications utiles sur les endroits ou ca rame (mais bon a pleine charge (20/50 users,+) ca fait beaucoup d'infos a lire :-).
Tu peux ensuite influer sur de nombreux parametres en fonction des causes identifiees: pool de connection a la base de donnees, memoire allouee a la JVM, precompilation des JSPs,... j'en passe et des meilleures.
si tu lis l'anglais les liens de la page http://wiki.apache.org/jakarta-jmeter/JMeterLinks et notamment http://jakarta.apache.org/tomcat/articles/performance.pdf sont tres interessants.
Merci
JS
-- Cordialement, Ludo - http://www.ubik-products.com --- "L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
Hello,
jeje900ss wrote:
Bonjour tous,
j'espère être sur le bon forum.
Ici ca doit etre OK (non?), tu devrais aussi t'abonner a bugtraq (cf
recents bugs sur JavaMail) et suivre fr.comp.securite si tu veux etre un
peu au courant d'autres aspects aussi importants que les performances ;-)
Je vais bientôt devoir passer en production un application WEB (Tomcat +
Postgresql ).
Le problème c'est que je ne sais pas comment évaluer le matériel qui
serait nécessaire pour que ça tienne la route. (mémoire, nbr de pc, etc..)
Je suis à la recherche de documents ou pistes qui me permettraient de
faire un choix.
Je te conseille d'utiliser l'excellent logiciel libre JMeter
(http://jakarta.apache.org/jmeter/) pour tester l'application et de
faire un benchmarking de ton application. J'espere que d'autres sauront
t'indiquer aussi d'autres pistes, je serais ravi d'etoffer mes
connaissances ou de corriger ma vision des choses.
Si tout s'est bien passe tu as normalement du modeliser des cas
d'utilisation, il faudrait que tu les valides, par exemple en les
executant une fois avec un Proxy JMeter puis en les rejouant
automatiquement : c'est ce que l'on appelle un plan de test,
cf http://jakarta.apache.org/jmeter/usermanual/index.html
Une fois cette etape faite, tu peux commencer a mesurer les
performances, en utilisant des utilisateurs virtuels (thread Jmeter) qui
jouent simultanement tes differents scenarios de tests et en regardant
si c'est conforme aux exigences des clients (3s par page...). Tu peux
faire des variantes distribuees mais je n'ai pas eu le temps de tester.
Pour dimensionner ton serveur, il faut que tu surveilles son
fonctionnement, et que tu vois ou sont les points de congestion: reseau,
memoire, bdd, disque, processeur,... Un tomcat lance en mode debug peut
t'apporter des indications utiles sur les endroits ou ca rame (mais bon
a pleine charge (20/50 users,+) ca fait beaucoup d'infos a lire :-).
Tu peux ensuite influer sur de nombreux parametres en fonction des
causes identifiees: pool de connection a la base de donnees, memoire
allouee a la JVM, precompilation des JSPs,... j'en passe et des meilleures.
si tu lis l'anglais les liens de la page
http://wiki.apache.org/jakarta-jmeter/JMeterLinks
et notamment http://jakarta.apache.org/tomcat/articles/performance.pdf
sont tres interessants.
Merci
JS
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
Ici ca doit etre OK (non?), tu devrais aussi t'abonner a bugtraq (cf recents bugs sur JavaMail) et suivre fr.comp.securite si tu veux etre un peu au courant d'autres aspects aussi importants que les performances ;-)
Je vais bientôt devoir passer en production un application WEB (Tomcat + Postgresql ).
Le problème c'est que je ne sais pas comment évaluer le matériel qui serait nécessaire pour que ça tienne la route. (mémoire, nbr de pc, etc..)
Je suis à la recherche de documents ou pistes qui me permettraient de faire un choix.
Je te conseille d'utiliser l'excellent logiciel libre JMeter
(http://jakarta.apache.org/jmeter/) pour tester l'application et de faire un benchmarking de ton application. J'espere que d'autres sauront t'indiquer aussi d'autres pistes, je serais ravi d'etoffer mes connaissances ou de corriger ma vision des choses.
Si tout s'est bien passe tu as normalement du modeliser des cas d'utilisation, il faudrait que tu les valides, par exemple en les executant une fois avec un Proxy JMeter puis en les rejouant automatiquement : c'est ce que l'on appelle un plan de test, cf http://jakarta.apache.org/jmeter/usermanual/index.html
Une fois cette etape faite, tu peux commencer a mesurer les performances, en utilisant des utilisateurs virtuels (thread Jmeter) qui jouent simultanement tes differents scenarios de tests et en regardant si c'est conforme aux exigences des clients (3s par page...). Tu peux faire des variantes distribuees mais je n'ai pas eu le temps de tester.
Pour dimensionner ton serveur, il faut que tu surveilles son fonctionnement, et que tu vois ou sont les points de congestion: reseau, memoire, bdd, disque, processeur,... Un tomcat lance en mode debug peut t'apporter des indications utiles sur les endroits ou ca rame (mais bon a pleine charge (20/50 users,+) ca fait beaucoup d'infos a lire :-).
Tu peux ensuite influer sur de nombreux parametres en fonction des causes identifiees: pool de connection a la base de donnees, memoire allouee a la JVM, precompilation des JSPs,... j'en passe et des meilleures.
si tu lis l'anglais les liens de la page http://wiki.apache.org/jakarta-jmeter/JMeterLinks et notamment http://jakarta.apache.org/tomcat/articles/performance.pdf sont tres interessants.
Merci
JS
-- Cordialement, Ludo - http://www.ubik-products.com --- "L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
jeje900ss
Salut
Je te conseille d'utiliser l'excellent logiciel libre JMeter (http://jakarta.apache.org/jmeter/) pour tester l'application et de faire un benchmarking de ton application. J'espere que d'autres sauront t'indiquer aussi d'autres pistes, je serais ravi d'etoffer mes connaissances ou de corriger ma vision des choses.
Merci, je viens de me mettre à JMeter, qui est vraiment un bel outil. Ca m'a déjà permis de voir qu'au bout d'un nombre trop important de requêtes, mon connexion pool ne suivait plus.
Si tout s'est bien passe tu as normalement du modeliser des cas d'utilisation, il faudrait que tu les valides, par exemple en les executant une fois avec un Proxy JMeter puis en les rejouant automatiquement : c'est ce que l'on appelle un plan de test, cf http://jakarta.apache.org/jmeter/usermanual/index.html
Je vais faire ça.
[...]
si tu lis l'anglais les liens de la page http://wiki.apache.org/jakarta-jmeter/JMeterLinks et notamment http://jakarta.apache.org/tomcat/articles/performance.pdf sont tres interessants.
Effectivement, j'ai lu le pdf sur performance. C'est interessant. Je vais continuer mes tests. Mais mon problème c'est que je dois fournir une réponse sur le matériel avant d'avoir le temps de finir mes tests... Pas facile.
En tout cas merci, ta réponse m'a permis d'avancer.
Jérôme
Salut
Je te conseille d'utiliser l'excellent logiciel libre JMeter
(http://jakarta.apache.org/jmeter/) pour tester l'application et de
faire un benchmarking de ton application. J'espere que d'autres sauront
t'indiquer aussi d'autres pistes, je serais ravi d'etoffer mes
connaissances ou de corriger ma vision des choses.
Merci, je viens de me mettre à JMeter, qui est vraiment un bel outil.
Ca m'a déjà permis de voir qu'au bout d'un nombre trop important de
requêtes, mon connexion pool ne suivait plus.
Si tout s'est bien passe tu as normalement du modeliser des cas
d'utilisation, il faudrait que tu les valides, par exemple en les
executant une fois avec un Proxy JMeter puis en les rejouant
automatiquement : c'est ce que l'on appelle un plan de test,
cf http://jakarta.apache.org/jmeter/usermanual/index.html
Je vais faire ça.
[...]
si tu lis l'anglais les liens de la page
http://wiki.apache.org/jakarta-jmeter/JMeterLinks
et notamment http://jakarta.apache.org/tomcat/articles/performance.pdf
sont tres interessants.
Effectivement, j'ai lu le pdf sur performance. C'est interessant.
Je vais continuer mes tests. Mais mon problème c'est que je dois fournir
une réponse sur le matériel avant d'avoir le temps de finir mes tests...
Pas facile.
En tout cas merci, ta réponse m'a permis d'avancer.
Je te conseille d'utiliser l'excellent logiciel libre JMeter (http://jakarta.apache.org/jmeter/) pour tester l'application et de faire un benchmarking de ton application. J'espere que d'autres sauront t'indiquer aussi d'autres pistes, je serais ravi d'etoffer mes connaissances ou de corriger ma vision des choses.
Merci, je viens de me mettre à JMeter, qui est vraiment un bel outil. Ca m'a déjà permis de voir qu'au bout d'un nombre trop important de requêtes, mon connexion pool ne suivait plus.
Si tout s'est bien passe tu as normalement du modeliser des cas d'utilisation, il faudrait que tu les valides, par exemple en les executant une fois avec un Proxy JMeter puis en les rejouant automatiquement : c'est ce que l'on appelle un plan de test, cf http://jakarta.apache.org/jmeter/usermanual/index.html
Je vais faire ça.
[...]
si tu lis l'anglais les liens de la page http://wiki.apache.org/jakarta-jmeter/JMeterLinks et notamment http://jakarta.apache.org/tomcat/articles/performance.pdf sont tres interessants.
Effectivement, j'ai lu le pdf sur performance. C'est interessant. Je vais continuer mes tests. Mais mon problème c'est que je dois fournir une réponse sur le matériel avant d'avoir le temps de finir mes tests... Pas facile.
En tout cas merci, ta réponse m'a permis d'avancer.
Jérôme
jerome moliere
On Fri, 27 May 2005 10:44:07 +0200, jeje900ss wrote:
Bonjour tous,
j'espère être sur le bon forum. t'es en plein dedans :)
Je vais bientôt devoir passer en production un application WEB (Tomcat + Postgresql ).
Postgresql rulez!! :)
Le problème c'est que je ne sais pas comment évaluer le matériel qui serait nécessaire pour que ça tienne la route. (mémoire, nbr de pc, etc..)
difficile a dire ce qu'il faut retenir:
* utilises tu de la transformation XSLt avec des feuilles xsl de la mort qui tue (genre xsl fo ) ? * nombre de connexions en //, en pics et en moyenne ? * volume d'une session ? * quid du cache sur le sgbd ?
Je suis à la recherche de documents ou pistes qui me permettraient de faire un choix.
la piste JMeter est excellente pour degrossir le terrain meme si d'autres
injecteurs sont envisageables (tsunami ou autre) monte en charge et surveille la'evolution du process Java (avec des top frequents) n'hesites pas aussi a balancer des signaux -3 a ta JVM cela ne fera pas de mal..
a la louche maintenant 1Go RAM c'est du standard voire 2 sur un serveur n'espere pas monter a plus de 2Gb pour ta JVM si t'es en 32 bits..:)
Jerome
-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Fri, 27 May 2005 10:44:07 +0200, jeje900ss <motte900@ifrance.com> wrote:
Bonjour tous,
j'espère être sur le bon forum.
t'es en plein dedans :)
Je vais bientôt devoir passer en production un application WEB (Tomcat +
Postgresql ).
Postgresql rulez!! :)
Le problème c'est que je ne sais pas comment évaluer le matériel qui
serait nécessaire pour que ça tienne la route. (mémoire, nbr de pc,
etc..)
difficile a dire ce qu'il faut retenir:
* utilises tu de la transformation XSLt avec des feuilles xsl de la mort
qui tue (genre xsl fo ) ?
* nombre de connexions en //, en pics et en moyenne ?
* volume d'une session ?
* quid du cache sur le sgbd ?
Je suis à la recherche de documents ou pistes qui me permettraient de
faire un choix.
la piste JMeter est excellente pour degrossir le terrain meme si d'autres
injecteurs sont envisageables (tsunami ou autre)
monte en charge et surveille la'evolution du process Java (avec des top
frequents)
n'hesites pas aussi a balancer des signaux -3 a ta JVM cela ne fera pas de
mal..
a la louche maintenant 1Go RAM c'est du standard voire 2 sur un serveur
n'espere pas monter a plus de 2Gb pour ta JVM si t'es en 32 bits..:)
Jerome
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Fri, 27 May 2005 10:44:07 +0200, jeje900ss wrote:
Bonjour tous,
j'espère être sur le bon forum. t'es en plein dedans :)
Je vais bientôt devoir passer en production un application WEB (Tomcat + Postgresql ).
Postgresql rulez!! :)
Le problème c'est que je ne sais pas comment évaluer le matériel qui serait nécessaire pour que ça tienne la route. (mémoire, nbr de pc, etc..)
difficile a dire ce qu'il faut retenir:
* utilises tu de la transformation XSLt avec des feuilles xsl de la mort qui tue (genre xsl fo ) ? * nombre de connexions en //, en pics et en moyenne ? * volume d'une session ? * quid du cache sur le sgbd ?
Je suis à la recherche de documents ou pistes qui me permettraient de faire un choix.
la piste JMeter est excellente pour degrossir le terrain meme si d'autres
injecteurs sont envisageables (tsunami ou autre) monte en charge et surveille la'evolution du process Java (avec des top frequents) n'hesites pas aussi a balancer des signaux -3 a ta JVM cela ne fera pas de mal..
a la louche maintenant 1Go RAM c'est du standard voire 2 sur un serveur n'espere pas monter a plus de 2Gb pour ta JVM si t'es en 32 bits..:)
Jerome
-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
