Salut à tous !

J'ai pas un parcours conventionnel, ce qui m'amène après de nombreuse années à me pencher aux tests de charges !

J'ai pour obligation de réaliser un test de charge sur une apli que je suis en train de monter. Et n'en ai même jamais vu ^^

j'ai fait un rapide tour de ce qui se fait : par ici ... seulement ^^ ... mais ne trouve pas un produit qui corresponde à mes souhaits ! ...

j'ai mis en place une navigation full Ajax (non-intrusif) qui me permet de proposer un allègement important des charges,
mais il y a aussi plusieurs requêtes récurrentes liées au type d'utilisateur, et évidemment les intervalles leurs sont propre !...

ce qui fait que de ce que l'ai vu, rien ne serait suffisamment paramétrable pour me permettre une anticipation concrète des futurs charges !
j'ai besoin de paramétrer 3 types de profils qui interviendront sur trois types de connexion (http / http=> robots / FullAjax) et pour ses trois types, paramétrer les requêtes récurrentes liées !...


donc je songeais en monter un ... (vite fait, dans un premier temps puis affiné et mis à dispo) ... et pour ce faire, je voudrais savoir si je suis dans le vrai dans la proposition fonctionnelle que j'en fait :

- analyse de l'ensemble des scripts et extractions de l'ensemble des urls
- rangement des urls en fonction de leur types(ajax/http) et accès (visiteur/admin/robot)
- paramétrage des droits d'accès des profil et de la répartition des utilisateurs (ex : 1 robot = 2 admin = 50 visiteurs sachant que l'on ne va jamais dépassé 10 robots simultanés et que en faible charge nous avons un admin pour 25 visiteurs alors qu'en forte charge, on peux avoir un admin pour 50 utilisateurs donc les taux devront être variables et paramétrables ...)

=> lancement de la phase de test en montée progressive :
- je partirais sur une base de 50 utilisateurs qui effectuerons les requêtes cURL en simultanées et à chaque boucle je multiplierais le chiffre par 2 ...
- je stocke l'utilisateur, l'heure de lancement de la requête et l'heure de fin (ce qui va surcharger le serveur lançant les test :s)

=> dépouillement et analyse :
- je sort un tableau avec courbes représentant les connexions simultanées (barre 3 couleurs représentant les utilisateurs) et les moyennes de temps de réponses (couleurs par utilisateurs)

le test sera poussé au crash !... puis affiné sur les phases suivantes pour extraire la stabilité du serveur http distant sur des charges constantes +/- lourdes ...


Quand pensez vous !??
Pensez vous que le serveur en charge de faire les test va tenir le cout ^^ ??
Quel données me manquera t ils ?
Que fais-je d'inutile ?

Merci beaucoup par avance et bonne nuit !

N'oublie pas de prévenir :
1) l'hébergeur du serveur cible
2) l'hébergeur du serveur qui lance le test
3) l'opérateur réseau de l'un et de l'autre (par exemple ton FAI si tu lance le test de chez toi)

Par ailleurs, pousser une machine au crash peut entrainer une casse matériel de ton serveur cible si celui ci est mal configuré donc il faut que tu sois sûr de ta config.

Ouch !...

merci @rthur !! t'as un peu des données là dessus, histoire que je puisse voir comment anticiper le point de "non retour" !... il vaut mieux éviter que j'éclate mon serveur, sinon, mon hébergeur va me faire la tête durant un petit moment ...

sinon, dans l'approche fonctionnelle ... ? c'est bon, ce que j'ai envisagé ?

Je suis loin d'être un expert en la matière donc je préfère m'abstenir de dire des bétises concernant la meilleure procédure de test.

Plutôt que de pousser la machine jusqu'au crash, le mieux serait peut être que tu fasses une estimation du nombre d'utilisateurs qui devraient utiliser ton service, tu ajoutes X% de marge en plus et tu essayes sur cette base.
Ensuite en production, la montée en charge de ton service sera probablement progressive, donc en suivant régulièrement l'évolution et la tenue de ton serveur tu sauras à peu près quand il ta faudra investir dans un second serveur ou remplacer ton serveur actuel par un plus puissant.

Si la montée en charge n'est pas progressive mais dans un laps de temps très court alors c'est extrêmement difficile (quasiment impossible) d'évaluer les machines à mettre en place... à moins d'être très riche et d'avoir les moyens de surdimensionner énormément sa plateforme "au-cas-où"...

Exemple avec le service des impôts : des milliers (millions?) de gens se connectent le jour de la date limite, et bien il a fallu quelques années pour que les services informatiques réussissent à avoir une plateforme qui tient le choc. De la même façon lorsque Google lance un nouveau service (Gmail, Wave, etc...), il le lance déjà en version béta privée pour voir, entre autre, comment la plateforme réagit à la montée en charge.
L'expérience pour la montée en charge d'un service est indispensable pour voir les points de blocage, les optimisations serveurs à apporter, les optimisations possible dans l'application, la stabilité de l'application, la bande passante nécessaire, etc...

Les services "cloud" qui commencent à arriver (ex: Gandi Flex mais que je ne peux pas conseiller car je ne sais pas si ça marche vraiment bien) peuvent être un début de solution...



Mon propos concernant la nécessité de prévenir FAI et hébergeur est aussi très important car si tu lances un test depuis chez toi vers un serveur hébergé chez un fournisseur sérieux sans que personne ne soit averti, tu risques:
1) que ton test soit bloqué par le firewall de ton hébergeur (si il est sérieux, il a forcément un firewall bien configuré qui bloquera tous tes tests car il considèrera que c'est une attaque)
2) de retrouver ton IP blacklistée de ton hébergeur et donc tu ne pourras plus accéder ni à ton serveur ni au site de ton hébergeur (ce qui peut être gènant pour ouvrir un ticket demandant le déblacklistage)
3) que ton FAI coupes ta ligne ADSL car cela ressemblera à une attaque ciblée ou au mieux à une "utilisation anormale des ressources fournies" (cf clauses de ton contrat pour connaitre le terme exact)

Tout ça pour dire qu'il ne faut pas prendre à la légère un test de charge, c'est compliqué à mettre en oeuvre si on veut bien le réaliser et cela demande beaucoup d'autorisations à obtenir si tu ne le fais pas sur un réseau local.

Merci @rthur !...

Bon, pour le comment, j'ai demander à mon hébergeur la mise en place d'un serveur pré-configuré comme le mutualisé qui sera sensé héberger le prog (dans un premier temps), la mise en place de virtuel correspondant à son offre pour le second hébergement, le tout accompagné d'un hébergement indépendant pour accueillir la plateforme en charge "d'attaquer" le prog ... j'espère que ça va le faire !... en plus si on passe directement en réseau, on ne devrait pas être limité par une quelconque bande passante se qui pourra surement facilité la concentration des données recueillies !...

maintenant, reste plus qu'à m'assurer de la méthodologie ... histoire de ne pas prendre un hébergement durant 48h pour au final des données inexploitables ^^

Si quelqu'un en fait de temps e temps ou a des rapports sous le coude, ça m'intéresserait bien de voir ce que ça donne habituellement !.. qui à recréer la roue, autant lui mettre de bon pneu ^^

Bonne nuit