Attention, la page ici prise pour analyser le temps de réponse est « reassort.php ».
Cette page ne doit pas être utilisée pour faire des tests de performance car contient naturellement des défaut de conception sur les versions non récentes amenant un nombre très très élevé d’IO. Il suffit d’activer la log dolibarr, de faire 1 accès à cette page, et de consulter la taille de la log pour s’en rendre compte. Il est inutile de chercher à résoudre des problèmes de performance en se basant sur les temps de réponses de cette page car, selon la nature de votre base, mais aussi du choix des colonne affichées, du nombre de ligne et des options prise sur le calcul de stock, elle sera longue par conception (la faute au calcul dynamique du stock théorique).
Cette page a été optimisée pour réduire les IO sur des versions récentes de Dolibarr (v11) mais restera toujours beaucoup plus longue que les autres, et est beaucoup plus pénalisée que les autres sur Windows. Car Windows et beaucoup plus long au niveau IO, compter 30% plus long pour Windows que pour Linux, mais pas plus, et seule cette page est pénalisante car la seule a avoir un usage abusif d’IO (nombre d’accès disque et nombre de requête SQL exécuté très élevé).
En conclusion:
Y a -t-il des lenteurs de 5s sur les autres pages ? Si non, problème terminé, c’est la page reassort.php qui est en cause. Il faut mettre à jour son Dolibarr (cela atténuera le défaut, mais c’est une page qui par nature sera toujours longue).
Si le problème de 5s d’attente se constate aussi sur la vue « Réseau » sur les autres pages (par exemple la page du menu haut « Tiers »), alors il faut analyser les réponses sur cette page du menu Tiers et surtout pas sur « reassort » qui est un cas particulier et qui donne de fausses pistes.
Si PHP 7 et 50% plus rapide que PHP 5, changer de version de PHP aura un effet très peu visible, idem en utilisant une version plus récente de DoliWamp. En effet, sur une appli de gestion, et c’est le cas sur Dolibarr, 90% du temps de réponse est dans les accès IO (disques et accès à la bases). Donc vous gagnerez 50% sur le 10%, soit un gain seulement de 5%.
Si le problème de performance est avéré sur toute page, comme même un PHP 5, mysql 5 et windows 7 et une machine milieu de gamme donnant de très bon résultat (temps de réponse global < 300ms), il faut alors chercher plutôt sur l’infra (pb DNS, firewall, fichier dolibarr ou documents mis sur un filesystem qui n’est pas local, partage réseaux actif vers un serveur non actif qui force windows à retester et attendre à chaque accès, mémoire insuffisante forçant le swapping, etc…)