NPDS : Gestion de contenu et de communauté

Sujet
longs tableaux et dégradation performances 

Votre Système d'Exploitation -: Linux  
Votre Package Web -: Apache + Php + MySql  
Votre version de PHP -: Php 8.x  
Version NPDS (voir statistiques du site)-: NPDS RÉvolution 16.8  

Type de problème -: Utilisation  
Votre hébergeur -: Autre(s)  
Votre Priorité OK, j'attends  
Description du problème
Ici sur le site quand supercache est activé il génère logiquement un très grand nombre de fichiers (actuellement plus de 12000 ...). La consultation du dossier cache dans l'interface du filemanager pose donc un problème de fonctionnement. (le navigateur s'épuise et la machine chauffe !...) plusieurs minutes avant un affichage complet et dysfonctionnement de la page ...

il faudrait peut être réfléchir à une pagination/traitement du tableau en (js/ajax) pour un chargement plus progressif et moins gourmand en ressources ? ...

nb : ce type de problème se pose aussi pour le tableau des messages privés et geoloc pour le tableau des ip (entre autre) quand y'a trop de données.... 
Inclure la signature Oui 
Notification par Email

Hello JPB,
J'espère que tu va bien.

Donc le soucis c'est pas le cache mais la gestion de l'affichage des tableaux avec filemanager, les MP et géoloc.

Voici mes réponses sans se pencher sur le code et juste au niveau fonctionnel.

1) filemanager / supercache :

• Je ne comprends pas pourquoi il y a autant de fichier 12000


• Pourquoi consulté les fichiers du supercache à part au niveau développement, pour moi il ne devrait pas être accessible


• Effectivement, il devrait y avoir une pagination

2) Les MPs
La gestion des MP est des plus simples, c'est une messagerie et c'est la gestion de messagerie qu'il faut gérér.
Pour moi, il faut juste pourvoir paramétrer l'épuration "automatique" des messages. donc 2 choses a prendre en compte.
1) L'action de suppression des messages dès que le message est plus vieux de [ X jours ou Y mois ]
2) l'action d'archiver un message afin de pouvoir garder un message important.

2 choses sur le 2eme point :
L'archivage étant juste un 1 ou 0 dans la ligne message. il faut que lui aussi soit limité afin que les membres ne soit pas dans l'archivage systématique.
L'archivage doit être en UI et UX une action voulu.
La limite de l'archivage doit proposer un DL des messages dans un seul et unique fichier html et suppression ensuite.

3) Géoloc :
Le soucis est à quel niveau ?
Grand grand table DNS ? ou je sais ..??

Prêt à échanger et à se pencher sur une analyse fonctionnel et technique.

Au plaisir de te lire

Jireck

se problème et simillaire de ce que deja évoqué ce sujet en 2023 sur le labo
https://www.labo.infocapagde.com/viewtopic.php?topic=1693&forum=18

non ... je parle d'un problème relatif aux capacité du navigateur et la complexité et longueur du DOM que php lui envoi ... et donc ce problème n'est pas relatif à celui que tu invoques (même si il existe pour le cas du filemanager)
- l'idée c'est simplement de fixer une limite (pagination ou autre) aux données envoyées pour ne pas avoir ce type de problème ...
à noter aussi que ce problème existe quelques soient les balises html utilisées (div pour geoloc, td pour filemanager et msg private ...)

Citation : Jireck
Hello JPB,
J'espère que tu va bien.

Donc le soucis c'est pas le cache mais la gestion de l'affichage des tableaux avec filemanager, les MP et géoloc.
<= oui le soucis ce n'est pas le cache mais la capacité du navigateur et la complexité et longueur du DOM que php lui envoi
Voici mes réponses sans se pencher sur le code et juste au niveau fonctionnel.

1) filemanager / supercache :

• Je ne comprends pas pourquoi il y a autant de fichier 12000

<== il pourrait y en avoir encore plus lol ...

• Pourquoi consulté les fichiers du supercache à part au niveau développement, pour moi il ne devrait pas être accessible


• Effectivement, il devrait y avoir une pagination

<== oui une pagination ou autre (à réfléchir)...

2) Les MPs
La gestion des MP est des plus simples, c'est une messagerie et c'est la gestion de messagerie qu'il faut gérér.
Pour moi, il faut juste pourvoir paramétrer l'épuration "automatique" des messages. donc 2 choses a prendre en compte.
1) L'action de suppression des messages dès que le message est plus vieux de [ X jours ou Y mois ]
<== oui ce serait une bonne idée
2) l'action d'archiver un message afin de pouvoir garder un message important.
<== ça c'est déjà possible non ?

2 choses sur le 2eme point :
L'archivage étant juste un 1 ou 0 dans la ligne message. il faut que lui aussi soit limité afin que les membres ne soit pas dans l'archivage systématique.
L'archivage doit être en UI et UX une action voulu.
La limite de l'archivage doit proposer un DL des messages dans un seul et unique fichier html et suppression ensuite.

3) Géoloc :
Le soucis est à quel niveau ?
<== pour geoloc c'est pour la mise en forme des ip géoréférencées (après 10000 ca commence à grincer ...)
Grand grand table DNS ? ou je sais ..??

Prêt à échanger et à se pencher sur une analyse fonctionnel et technique.

Au plaisir de te lire

Jireck

Bon je sors puisque c'est pas ce que je disais.

Meme si toutes mes interrogations / explications sont bonnes

🙈🙉🙊

discours croisé alors je sors pas

Citation : jpb
non ... je parle d'un problème relatif aux capacité du navigateur et la complexité et longueur du DOM que php lui envoi ... et donc ce problème n'est pas relatif à celui que tu invoques (même si il existe pour le cas du filemanager)
- l'idée c'est simplement de fixer une limite (pagination ou autre) aux données envoyées pour ne pas avoir ce type de problème ...
à noter aussi que ce problème existe quelques soient les balises html utilisées (div pour geoloc, td pour filemanager et geoloc ...)

ok

La pagination sur un file manager me semble assez bizarre comme concept

Pour le reste cela me semble une très bonne idée !

A suivre

Citation : developpeur
La pagination sur un file manager me semble assez bizarre comme concept

<== oui à moi aussi ! c'est la le challenge ...

Pour le reste cela me semble une très bonne idée !

A suivre