qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
Un utilisateur pour l'injecteur est un utilisateur dans l'application : préférences + contexte.
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
En effet, il y en avait trois. De toutes façons, je pense que je n'étais pas loin de la limitation physique du réseau (10 Mb/s). Il faudrait que je regarde plus en détail les résultats ...
de plus 1 requete != 1 utilisateur:
En effet, il s'agit d'un serveur de documentation. Je suis parti de l'hypothèse qu'un utilisateur actif charge une page environ toutes les 30 secondes. Je pense d'ailleurs que c'est assez large ... mais comme je suis au début du développement du projet, c'était juste pour voir si la solution était viable.
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
Il y a en fait très peu d'images dans mon cas, et la plupart d'entre elles sont sur toutes les pages (logo de l'application, pictogrammes de sections ...) et résident donc dans le cache du navigateur. Sinon, il doit y avoir une dizaine d'images non récurrentes. La probabilité de tomber sur une page ayant une image doit être inférieure à 0.1%. Mais bon, ce que je voulais tester était la réponse applicative (J2EE + BDD), pas le serveur ...
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
Dans mon application, les actions d'un utilisateur n'impactent pas les autres. Je n'ai à aucun endroit de système de verrou sur les données globales par un utilisateur. Les seules saisies possibles concernent les préférences de l'utilisateur (ne peut potentiellement bloquer que cet utilisateur) et l'administration de l'application (un bloquage des sessions est alors voulu). J'ai considéré que ces saisies étaient marginales dans l'utilisation de l'aplication, je les ai donc exclues de mon test.
En fait, les chargements de données dans la base ne sont possible que depuis une application indépendante qui va directement taper dans les EJB. Il serait beaucoup trop complexe d'essayer de faire ça depuis l'application HTTP à cause de la très grande quantité d'informations à lire sur le disque ... Il est également prévu d'automatiser ces mises à jour, qui peuvent alors avoir lieu pendant les heures creuses d'utilisation.
bref prenons des pincettes pour manipuler ces chiffres.
C'est vrai que j'aurais dû préciser dès le début, mais les frustrés qui ne connaissent pas Java m'ont trop énervé pour que j'y pense de prime abord ...
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par François B. . En réponse à la dépêche Comparatif jsp/php. Évalué à 1.
humm ... comment a tu fait tes tests ?
avec quel injecteur ??
Deluge ( http://deluge.sourceforge.net(...) ) et Hammerhead ( http://hammerhead.sourceforge.net(...) ). Tous deux sont en GPL ...
qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
Un utilisateur pour l'injecteur est un utilisateur dans l'application : préférences + contexte.
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
En effet, il y en avait trois. De toutes façons, je pense que je n'étais pas loin de la limitation physique du réseau (10 Mb/s). Il faudrait que je regarde plus en détail les résultats ...
de plus 1 requete != 1 utilisateur:
En effet, il s'agit d'un serveur de documentation. Je suis parti de l'hypothèse qu'un utilisateur actif charge une page environ toutes les 30 secondes. Je pense d'ailleurs que c'est assez large ... mais comme je suis au début du développement du projet, c'était juste pour voir si la solution était viable.
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
Il y a en fait très peu d'images dans mon cas, et la plupart d'entre elles sont sur toutes les pages (logo de l'application, pictogrammes de sections ...) et résident donc dans le cache du navigateur. Sinon, il doit y avoir une dizaine d'images non récurrentes. La probabilité de tomber sur une page ayant une image doit être inférieure à 0.1%. Mais bon, ce que je voulais tester était la réponse applicative (J2EE + BDD), pas le serveur ...
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
Dans mon application, les actions d'un utilisateur n'impactent pas les autres. Je n'ai à aucun endroit de système de verrou sur les données globales par un utilisateur. Les seules saisies possibles concernent les préférences de l'utilisateur (ne peut potentiellement bloquer que cet utilisateur) et l'administration de l'application (un bloquage des sessions est alors voulu). J'ai considéré que ces saisies étaient marginales dans l'utilisation de l'aplication, je les ai donc exclues de mon test.
En fait, les chargements de données dans la base ne sont possible que depuis une application indépendante qui va directement taper dans les EJB. Il serait beaucoup trop complexe d'essayer de faire ça depuis l'application HTTP à cause de la très grande quantité d'informations à lire sur le disque ... Il est également prévu d'automatiser ces mises à jour, qui peuvent alors avoir lieu pendant les heures creuses d'utilisation.
bref prenons des pincettes pour manipuler ces chiffres.
C'est vrai que j'aurais dû préciser dès le début, mais les frustrés qui ne connaissent pas Java m'ont trop énervé pour que j'y pense de prime abord ...