Mon sujet de mémoire va sûrement porter sur l’analyse des performances d’un programme java (un site web).
Seuleument, ce sujet ne m’inspire pas encore grand chose.
Donc voilà un concept de post : le brainstorming!!
Pour les spécialistes, ou pas, de cette sciences, j’aimerais savoir ce que la notion de “performance” vous inspire, vos idées, documentations, impressions, conseils, outils, programmes, notions, sites web, sujets connexes… tout ce qui vous passe par la tête.
Bien sûr, je ne vous demande pas de faire mon mémoire, mais juste d’avoir un maximum de pistes avant de valider le sujet et commencer.
merci d’avance pour vos réponses… à vous les studios!
[quote=“the_webrunner, post:1, topic: 44485”]Bonjour à tous,
Mon sujet de mémoire va sûrement porter sur l’analyse des performances d’un programme java (un site web).
Seuleument, ce sujet ne m’inspire pas encore grand chose.[/quote]
P’têt aussi que c’est pas le sujet de mémoire idéal?
J’dis ca, j’dis rien… C’est pas moi qui vait bosser dessus pendant X mois…
C’est juste que j’ai jamais fait ça en cours et que je sais pas trop par où commencer pour me renseigner.
En fait, je compte sur ce que vous allez marquer pour faire plus de recherche dessus…
Au contraire, je pense que c’est un sujet intéressant, et les pistes de réflexion sont multiples.
Tu peux parler de ce qui impact les performances dans un projet logiciel, et plus précisément dans le cas d’application WEB, des processus qui permettent d’analyser ces performances et mettre en évidence les points à améliorer (profiling, analyse de flux d’info, utilisation de caches à plusieurs niveaux…), donner des solutions génériques à certains problèmes récurrents, aborder des problèmes comme l’équilibrage entre “maintenabilité / extensibilité” et “performances” du systèmes etc.
Je pense que le sujet des performances (surtout dans le cas des applis WEB) est relativement délaissé, et qu’il y a pleins de problématiques auxquelles peu de développeurs pensent, ou en tout cas, pas au démarrage du projet, au moment crucial de la création de l’architecture globale du système. Le simple fait de lire les réponses précédentes me conforte dans ce constat.
Maintenant, j’espère les développeurs habitués aux (très) gros projets avec whatmilles utilisateurs seront de mon avis B)
Pour moi, apriori, je ne me soucie pas de la perf (mais je n’ai jamais eu affaire à d’applis ou la perf est un enjeu majeur, du genre il faut pouvoir traiter 10to de données en 3 sec).
Mais vu que tu parles d’applis web, on est dans le même cas. Donc apriori, je ne fais rien de spécial, je fais surtout en sorte de faire une architecture scalable (je peux approndir sur ce sujet si tu veux
A posteriori, je vérifie que les perfs obtenues me conviennent (de manière globale avec un outil tests de perf en boite noire). Et si problème il y a, j’enquête avec des outils de type profiling pour identifier les éventuels points de contension … et savoir comment résoudre le problème (et là je vois 3 cas : problème de code ou d’archi, scalabilité horizontale : on ajoute des machines, scalabilité verticale : on booste la machine RAM/CPU/IO)
Quand je dis aposteriori, c’est pas forcément tout à la fin du projet, ca peut être fait au fur et à mesure (tous les mois, tous les 2 mois …).
Niveau outils, je vois les outils de type boite noire pour vérifier le temps de réponse de l’appli de manière globale (Mercury LoadRunner qui est tres cher, ou OpenSta gratos, et il yen a plein d’autres).
Il y a les outils boite blanche (profiling) comme JProfiler (Borland ?) mais j’y connais pas grand chose
Et entre les deux (boite grise ?) : un outil de perf boite noire + des sondes installées dans le serveur d’app, la base de données, l’OS … pour identifier les points de contension
Pour revenir à ton mémoire, je pense qu’il faut autant de méthodo (qd faire mes études de perfs ? quel type d’analyse ?) que de techno (familles d’outils, solutions types pour problèmes types (i.e. ca sert à rien de rajouter 4go de ram à tout bout de champ)). Et si tu te rends compte que finalement la perf c’est chiant, tu peux étendre ton mémoire à la qualité logicielle en générale (et là yen a des choses à dire !)
[quote=“girafologue, post:5, topic: 44485”]Le simple fait de lire les réponses précédentes me conforte dans ce constat.
Maintenant, j’espère les développeurs habitués aux (très) gros projets avec whatmilles utilisateurs seront de mon avis B)[/quote]
Comme cette tentative de disqualification d’avis est joliment ammenée.
Penser que “analyse des performances d’un programme Java” n’est pas forcément un sujet de mémoire passionnant ne signifie pas que l’on ne connaisse rien au sujet.
En l’occurence c’est bien parce que j’ai du me frotter plus souvent qu’à mon tour à ce genre de problématique que je ne souhaite à personne d’y passer des mois…
C’est un peu borderline, mais tu peux aussi envisager les perfs du point de vue des utilisateurs, les influences que peuvent avoir les perfs sur le comportement d’un type qui utilise une webapp, etc…
Ou alors essayer de situer les goulots les plus fréquents dans leswebapps.
Ou alors essayer d’évaluer le point d’équilibre entre fonctionnalités offertes par un framework / lourdeur et pertes de perfs induites. Ou alors temps de dév économisé grace à un framework / perfs… etc.
+1, l’analyse de l’ergonomie me semble pertinente niveau performance: par exemple si tu réduit les erreurs utilisateurs, tu réduit les traitements coté système (genre reremplir un formulaire, affichage d’une aide contextuelle, etc.), d’où le gain de performance si ton interface est accessible et si tes processus sont pertinents (chaines d’actions pour effectuer une tache). Grattes du coté des critères de Bastien & Scapin, Nielsen et W3C, tu devrais réussir à identifier les problèmes les plus gros (s’il y a lieu).
Je ne vois pas en quoi ce sujet ne serait pas viable et avec peu d’intérêt…
C’est justement un sujet assez large pour permettre plusieurs pistes de réflexions, sur les différents aspects de la performance, les moyens d’analyses, les différents types de problèmes, leur contournement… Bref, beaucoup de réflexion.
Je trouve ce sujet beaucoup plus intéressant (parce que moins “en vogue” et donc moins “documenté” que d’autres) et plus enrichissant pour la communauté qu’un éniemme “Pourquoi Ajax ca poutre sa maman, surtout en Java” ou “Pourquoi Ajax ca poutre sa maman, surtout en C#”, ou ce genre de sujets clonés x fois.
Après il est certain que c’est plus austère, et sûrement plus compliqué, mais comme je l’ai dit, je trouve ca bien plus intéressant, et en phase avec les problématiques de notre métier.
(Je suis actuellement formateur dans une Ecole d’ingé, l’année dernière, la majorité des thèses orienté développement que j’ai corrigé n’était que ramassi de banalités sur Ajax, voilà le pourquoi des exemples de sujets que j’ai cités ^^).
En fait, c’est la première chose qui m’était passé par la tête sachant que c’était plus ou moins le sujet de mon stage précédent. J’avais déjà prévu de négocier une partie sur ça B)
[quote=« girafologue, post:11, topic: 44485 »]Je ne vois pas en quoi ce sujet ne serait pas viable et avec peu d’intérêt…
C’est justement un sujet assez large pour permettre plusieurs pistes de réflexions, sur les différents aspects de la performance, les moyens d’analyses, les différents types de problèmes, leur contournement… Bref, beaucoup de réflexion.[/quote]
C’est très bien dit B)
C’est en fait pour ça que le sujet « me branche » sachant que j’ai déjà fait un stage avec que de la prog, si je pouvais utiliser mes autres neurones ce serait bien Humour 3e degré hin
Rhaaa mais comment je demonterais le pauvre gars qui fait ca si c’etait moi. Les nieme platitude sur AJAX rhaaaaa die die die. Bon apres y a de quoi faire du top sur le sujet mais je vois d’ici le mec qui t’explique ce qu’est ajax sur les 3/4 de son doc…
Dans ma boîte, ils sont confrontés au problème : l’appli est tellement lourde qu’avec l’augmentation du nombre de clients ça devient critique. Du coup, on cherche à réécrire des parties et à aller à la chasse aux fuites de mémoires.
TPTP a été utilisé sous Eclipse en combinaison avec le plugin JBoss pour cherche les fuites.
Dans la réécriture, on essaie également de minimiser certains paramètres qui alourdissent les applications Java : pas trop d’instanciations de String qui comme elles sont immutable sont très rarement partagées, pas trop d’appels de méthode.
Il y a aussi des test de charge réalisés avec Apache JMeter.
De manière générale, on essaie de trouver un compromis entre utilisation mémoire et utilisation processeur, quitte à stocker des tonnes de truc en RAM pour pas avoir à les recalculer. Mais, après c’est selon les cas.
Enfin, du côté client, il faut penser aux trucs classique : poids des pages, temps de génération, etc.
Humour 3e degré hin