Normalement, les chiffres que vous indiquez ne sont pas problématiques.
Des tests de performances ont été réalisés avec plus de données, sans montrer de problème générale.

La V3.1 apporte des améliorations en terme de temps de réponses pour les utilisateurs qui doivent afficher beaucoup de projets, avec des hiérarchies complexes.
Ceci améliore largement les temps de connexion.

Par contre, 2 éléments sont, et resteront, délicats :
- l'affichage du planning : de par sa complexité, le planning est long à calculer et ensuite à restituer par le navigateur.
- l'affichage de l'écran des imputations : de par le nombre de zones de saisie à afficher (et de zones masquées à gérer), cet écran peut être long à afficher et enregistrer au delà de 50 lignes.

Dans les deux cas, on distingue bien deux phases :
- le calcule des données, effectuées coté serveur : le "sablier" tourne
- le navigateur reçoit les données et les met en forme : le "sablier " s'arrête alors de tourner, le navigateur n'a plus le temps de faire "tourner" le gif animé.
Dans le premier cas, ce sont les serveurs (données / traitement) qui sont impliqués.
La performance de cette phase dépend uniquement des performances de ces machines.
Dans la seconde phase, c'est la capacité du poste utilisateur et du navigateur qui sont impliqués. Sur ce point, tous les navigateurs ne se valent pas :
- Chrome donne les meilleures performances
- FireFox donne de bonnes performances, mais peut avoir des comportement bizarres en fonction des extensions et plugins installés, et certaines nouvelles version apportent des régressions.
- IE9 est pas mal
- IE8 (et inférieur) est excecrable en terme de performances

Je vais vérifier de mon coté avec vos données les temps de réponse sur une machine de référence, correctement dimensionnée.
Pour quelles ressources constatez-vous des ralentissements forts ?
Quel est l'ordre de grandeur des temps de réponse ?

Bonjour,

merci pour ce retour rapide.

Ci-dessous copie du message que m'a adressé Yves BATEL, responsable du bureau ASUP (il est donc en visibilité du projet chapeau ASUP et des l'ensemble des ses sous-projets :

Je me suis livré ce matin avant 9H à quelques mesure de temps de réponse de Projector sur mon poste de travail :

- Ouverture de l'application (jusqu'à ce qu'on ait la main) : 25 secondes
- affichage du planning global (avec tous les projets du bureau) 30 secondes
- affichage du planning en filtrant sur 1 chapeau (5 projets) 5 secondes
- affichage imputation 5 secondes
- changement de semaine dans le menu imputation 5 secondes
- enregistrement des imputations 2 secondes
- menu activité 1 seconde
- menu projet 1 seconde
- ouverture d'un projet 1 seconde

Au final rien de véritablement rédhibitoire mais une impression qui subsiste de manque de fluidité notamment sur le module imputation qui sera le plus souvent utilisé.

Bien entendu, l'affichage du planning global de l'ensemble des projets n'a pas de véritable justification et je conseille plutôt de passer par l'état Planning (ce qui renvoie à une autre anomalie remontée sur l'impossibilité d'éditer l'état). Ceci dit, j'aurias besoin de métriques de votre côté pour challenger mon infigéreur car notre architecture est assez complexe (notamment avec la présence systématiques de reverse-proxy entre les serveurs) et je souhaite savoir si nous avons à gagner dans une démarche de simplification, les données de PROJECTOR n'étant pas jugées sensibles à notre niveau.

Cordialement,

Bonsoir,

Les temps de réponse ne me paraissent pas abérents, encore faut-il savoir face à quelle volumétrie...

Pour l'ouverture de l'application, la V3.1 apporte des amélioration notable.

J'ai quelques métriques, issues de tests de perfs, je vous les transmettrai ce week-end.

Sur les reverse-proxy, ça a globalement peu d'important tant qu'il n'y en a pas entre le serveur de traitement (PHP) et le serveur de données (PostgreSql). La liaison entre les deux doit être la plus direct possible.
Sinon, ce n'est pas quelques dizaines de millisecondes sur un requête PHP qui va changer grand chose.