Vous n'êtes pas identifié(e).
13 février 2024 Sortie de Dotclear 2.29
Bonjour,
Pour le site du profil, le fonctionnement de dotclear 2 est tout à fait satisfaisant. Cependant dans l'admin, pour le gestionnaire de médias, je constate un temps d'accès bien long, 4 à 5 s pour afficher le détail du média (images jpg de ±100 ko), et de même pour afficher l'image en taille originale.
L'hébergeur (OVH - perso 25 Go) n'observe pas de délais anormaux après essai. Les navigateurs utilisés sont Chrome ou Firefox sous windows 7. Je ne sais pas qu'en penser et n'imagine pas l'origine du problème.
Merci de votre éclairage.
Cordialement
Geba
Hors ligne
Bonjour,
j'ai aussi développé cette question à côté d'une autre ici >>> http://forum.dotclear.org/viewtopic.php?id=46938
Mais je suis content que tu poses la question dans un fil séparé, car mon autre DC2, celui de voyage, a 3 fois moins d'images que le 1er DC2 et c'est pareil.
Je constate aussi depuis quelques semaines, alors que que je l'avais plus alimenté depuis mi août, un énorme ralentissement et, pire, des plantages très très répétés.
Même si je vide le cache de FF ou si j'éteins et rallume mon PC, rien n'y fait. Si je tente ces opérations chez des amis, rien n'y fait.
OVH m'a aussi répondu qu'il n'y a rien d'anormal dans mon GP90 mutualisé et ils ont même contrôlé mes fichiers dans le répertoire du gestionnaire de médias. Pour OVH il n'y a rien d'anormal chez moi !!!
http://www.renovezmaintenant67.eu avec un blog DC2,
et http://www.hotchkiss.eu avec un blog DC2
Hors ligne
Les forums d'OVH recensent de nombreuses plaintes au sujet des temps d'accès aux bases de données sur certains hébergements mutualisés. Cela dure depuis quelques semaines...
Hors ligne
Avant de poster, j'ai lu le fil que tu cites.
La base de donnée est sur mysql5-14.perso (mutualisé OVH), et son diagramme de latence en temps réel ne présente pas actuellement de délai important.
J'ai pu observer il y a quelques temps des erreurs 500, le serveur était en surcharge (reconnue par OVH). Mais tout semble actuellement rentré dans l'ordre. La question reste entière.
Cordialement
Geba
Hors ligne
Les forums d'OVH recensent de nombreuses plaintes au sujet des temps d'accès aux bases de données sur certains hébergements mutualisés. Cela dure depuis quelques semaines...
Je visite régulièrement le forum en question. Mais pourquoi le gestionnaire de médias seulement, serait affecté ?
Cordialement
Geba
Hors ligne
moi c'est mysql 5-43.
Il est opérationnel et au top
http://www.renovezmaintenant67.eu avec un blog DC2,
et http://www.hotchkiss.eu avec un blog DC2
Hors ligne
Je pense que ça n'a rien à voir avec la base de données, mais plutôt avec le nombre de fichiers dans le répertoire de média. J'ai déjà rencontré des soucis de lenteur avec un compte OVH et un blog DC dans lequel tous les médias (plusieurs milliers) étaient stockés dans un seul et même répertoire.
Est-ce le cas ici ?
Dotclear addicted since 2004
Hors ligne
Mes photos sont réparties dans public en dossiers et sous dossiers : 4752 fichiers dans 65 dossiers. Le plus petit dossier contient 8 images, le plus grand sous dossier contient 681 images.
Le nom des fichiers est difficile à être analysé. Il ne contient ni espace, ni caractères spéciaux, mais peut être considéré comme long (67 caractères pour un des plus longs, mais en moyenne <50 caractères).
Cordialement
Geba
Hors ligne
La longueur du nom des fichiers peut poser un problème, d'autant que c'est le chemin complet qui est pris en compte. Je crois que la limite de ce total est de 260 caractères.
As-tu essayé d'envoyer un fichier au nom très court et de voir ce que donnait le temps d'affichage des détails du média dans le gestionnaire ?
Hors ligne
Avec DC1 il y avait automatiquement création de sous-répertoire par jour des uploads.
C'est bête qu'avec DC2 j'ai tout dans un même sous-répertoire. Nous aurions pu être prévenus au lieu d'aller au mur avec une saturation, si saturation il y a.
Mais avec mes explications ci-dessous je doute que ceci vienne de cela.
Même avec mon sous-répetoire créé il y a deux jours et où il n'y a qu'une seule image,
ça met des plombes à par exemple passer d'un classement par nom à un par date et ça plante très souvent avec ledit message d'erreur.
Il faut alors relancer x-fois l'affichage en haut à droite sur la barre et parfois ça revient.
En fermant la fenêtre de téléchargement d'image et en redemandant son ouverture ça plante, etc, etc, etc
Dernière modification par Thomas Rudolf (2013-01-23 10:45:51)
http://www.renovezmaintenant67.eu avec un blog DC2,
et http://www.hotchkiss.eu avec un blog DC2
Hors ligne
@Thomas Rudolf : as-tu un fichier .htaccess dans ton répertoire public et si oui quel est son contenu ? Ou dans la même idée y a-t-il un fichier de ce type à la racine du site ou dans le répertoire dotclear qui aurait des règles concernant les images ?
Hors ligne
A la racine je l'ai avec ceci comme il se doit >>>
SetEnv PHP_VER 5
Options -Indexes
-----------------
Dans public, je n'en ai pas.
http://www.renovezmaintenant67.eu avec un blog DC2,
et http://www.hotchkiss.eu avec un blog DC2
Hors ligne
Avec DC1 il y avait automatiquement création de sous-répertoire par jour des uploads
Tu devais avoir mis en place un truc spécial car je n'ai jamais eu ce comportement avec dc1.
Quant à être prévenu, j'imagine que sur ton ordi tu ranges et classes tes documents dans des dossiers et sous-dossiers plutôt qu'avoir un fourre-tout qui doit être bien peu commode...
Bref, le bon sens, faut l'écouter ;)
Hors ligne
As-tu essayé d'envoyer un fichier au nom très court et de voir ce que donnait le temps d'affichage des détails du média dans le gestionnaire ?
Je viens de faire l'essai en plaçant une image shortname.jpg de 48ko à la racine de public. Le constat est le même, 4 à 5 s pour ouvrir les détails du média et le même délai pour ouvrir l'image dans sa taille originale. Le temps pour ajouter le fichier n'est pas significatif.
Le mystère reste entier…
Cordialement
Geba
Hors ligne
Thomas Rudolf a écrit :Avec DC1 il y avait automatiquement création de sous-répertoire par jour des uploads
Tu devais avoir mis en place un truc spécial car je n'ai jamais eu ce comportement avec dc1.
Quant à être prévenu, j'imagine que sur ton ordi tu ranges et classes tes documents dans des dossiers et sous-dossiers plutôt qu'avoir un fourre-tout qui doit être bien peu commode...
Bref, le bon sens, faut l'écouter ;)
1) Non, DC1 classait tout seul ses images dans des sous-répertoires portant la date.
2) Je ne comprends pas tes propos et tu détournes toujours du problème.
A chaque rédaction d'un post, je télécharge des images ou des graphiques et tableaux nouveaux lors de la rédaction.
Je ne m'occupe ensuite plus de ces images, ce n'est pas comme sur mon ordi.
Ce n'est pas comme tu me l'écris "un fourre-tout" et il n'a pas lieu d'être commode ou pas.
3) Il y a un problème évident avec ce gestionnaire de médias, et pour l'instant toutes les réponses données sur le fil précédent puis celui-ci, ne font que de répondre à côté.
OVH est formel, et m'a répondu à plusieurs fois qu'il n'y a pas de problème avec mon fichier public ni avec les noms des images, ni avec mon 90GP, etc
Par le passé, si OVH avait dû avoir un problème, l'équipe avait de suite cherché la source et s'était excusée. Ces problèmes n'étaient au fait que de leur ressort.
Dernière modification par Thomas Rudolf (2013-01-23 15:40:57)
http://www.renovezmaintenant67.eu avec un blog DC2,
et http://www.hotchkiss.eu avec un blog DC2
Hors ligne
1/ dc1 ne crée pas de dossier portant la date. Je n'ai jamais eu ce comportement. Jamais. Et j'en ai monté des blogs en dc1 !
2/ que tu ne touches pas aux images par la suite ne t'empêche pas de les classer dès le départ, c'est du simple bon sens selon moi. Que les propositions de correction ne te satisfassent pas car il te faudrait modifier des tas de mauvaises habitudes ne font pas de ces solutions de mauvaises solutions.
Tu refuses de corriger tes erreurs de code, tu refuses de ranger convenablement tes médias, c'est ton droit, ta liberté mais c'est, au final, un bien mauvais calcul. Toujours selon moi, ce n'est pas en accumulant les erreurs qu'on peut créer un truc stable.
3/ il y a peut-être un pb avec le gestionnaire de médias mais il faudrait quand même que tu conviennes que tout le monde n'y est pas sujet. Perso j'ai aucun pb de latence ou de timeout ou d'erreurs avec le gestionnaire de médias, sur aucun des blogs dont je m'occupe.
Mais bon je ne suis pas chez OVH...
Note bien que je n'ai jamais vu un hébergeur reconnaître qu'il y avait un pb avec leurs serveurs, mais c'est un autre débat ;)
Il est connu que les noms en informatique qui comportent des espaces ou signes diacritiques posent soucis avec les navigateurs. C'est bien pour cela que dotclear modifie ces libellés quand on crée un dossier ou uploade une image avec le gestionnaire de média.
Bref, peut-être pourrais-tu essayer les solutions qu'on te propose et voir, à l'usage, si tes pbs se règlent (et faire un unique essai avec une image sachant que tout le reste est accumulé dans un unique répertoire est tout sauf probant) ?
A toi de voir si ton blog mérite cet effort de ta part. Ou pas.
Hors ligne
La longueur du nom des fichiers peut poser un problème, d'autant que c'est le chemin complet qui est pris en compte. Je crois que la limite de ce total est de 260 caractères.
Ce chemin complet commence où ? à partir de public ou depuis le http ?
Merci.
Hors ligne
Il me semble que le chemin complet est celui de l'emplacement du fichier sur le serveur, par exemple :
/home.11.9/plop/www/monsite/../public/mon-dossier/mon-sous-dossier/le-nom-de-mon-image.jpg
Hors ligne
Si la longueur du nom de fichier ou la performance de l'hébergeur peut être à l'origine du délai constaté, comment expliquer que le constat n'est fait qu'au niveau de l'utilisation du gestionnaire de médias – et cela en ouvrant les détails du média ou l'image originale ?
Par exemple, quand on demande de prévisualiser son travail, en cours de rédaction d'un billet, le navigateur va bien chercher l'image dans l'arborescence des dossiers. Et peu importe la longueur de son nom, il affiche immédiatement (quasiment au temps de chargement près) l'image. Je me demande alors pourquoi le serveur répondrait correctement dans un cas et pas dans l'autre.
Mais les détails de ce qui peut se passer me dépassent complètement…
Cordialement
Geba
Hors ligne
Tu as probablement raison, et il y a peut-être quelque chose à faire du côté de la base de données... Tu devrais déposer un ticket sur le Trac de dotclear pour attirer l'attention d'un sorcier ;)
Hors ligne
En attendant, il semblerait aussi que nous ne soyons pas trop nombreux à faire ce constat. Oui, je vais suivre ton conseil et réfléchir à la rédaction concise et précise du ticket.
Cordialement
Geba
Hors ligne
Juste une dernière idée : as-tu procédé à l'importation du contenu d'un blog dans un nouveau pour faire des tests ? Plusieurs fois même ?
Il se pourrait alors que ce soit la raison d'un bug que j'ai déjà rencontré et pour lequel j'ai peut-être une solution, pour peu que tu aies accès à phpMyAdmin.
Hors ligne
Juste une dernière idée : as-tu procédé à l'importation du contenu d'un blog dans un nouveau pour faire des tests ? Plusieurs fois même ?.
Pourrais-tu préciser la manip, je ne comprends pas bien. J'ai bien accès à phpMyAdmin que j’appréhende à utiliser.
Le blog actuel est le résultat d'une migration dc1 > dc2 enrichie de nouveaux contenus depuis (il y a eu des hésitations et des reprises lors de la migration).
Dernière modification par geba (2013-01-23 15:13:33)
Cordialement
Geba
Hors ligne
Le conseil m'avait été donné ici : http://forum.dotclear.org/viewtopic.php?id=37818 en #4 par Olivier Meunier lui-même
Il faut aller dans phpMyAdmin et ouvrir la fenêtre SQL pour y taper la commande. J'avais dû le faire plusieurs fois pour y parvenir complètement, mais j'avais plusieurs importations empilées. Attention, si le préfixe de tes tables n'est pas dc_ il faudra bien entendu changer un peu le code ;)
Hors ligne
Pour moi, cela serait :
DELETE FROM dc2_media WHERE media_id NOT IN (SELECT media_id FROM dc2_post_media)Mais avant de me lancer (je n'ai jamais fait), comment voir l'empilage dont tu parles ? En plus, je ne comprends pas clairement l'action de la requête.
En éditant dc2_media, j'ai bien des chemins de fichier qui n'auraient plus lieu d'exister (correspondants aux blogs de test). C'est ceux là que la requête SQL supprimerait ? Au quel cas le faire pour chaque fichier, ne serai pas un gros travail.
Cordialement
Geba
Hors ligne
Vous n'êtes pas identifié(e).