Pas simple cette histoire !
Je m’explique : il arrive de temps en temps que le serveur Dotclear, ou DotAddict d’ailleurs, rame un peu, en général quand le serveur Web (Apache ou Nginx) est un peu trop sollicité par des crawlers — c’est ce que j’ai constaté comme cause le plus fréquemment.
Ça a un impact direct sur Dotclear, ou plutôt sur l’administration de votre blog, parce que l’application utilise des services sur ces deux domaines pour un certain nombre de tâches :
- Récupération des nouvelles de Dotclear, avec un timeout[1] de 2 secondes, uniquement sur le tableau de bord.
- Récupération de la dernière mise à jour de Dotclear, s’il en existe une, avec un timeout de 4 secondes, uniquement sur le tableau de bord ou sur la page de mise à jour.
- Récupération de la liste des langues disponibles pour Dotclear, avec un timeout de 5 secondes, uniquement sur la page de gestion des langues.
Ça c’est côté Dotclear, et pour DotAddict :
- Récupération des mises à jour des plugins et/ou des thèmes, avec un timeout de 5 secondes, uniquement sur le tableau de bord, si l’icône de gestion des plugins y est présente et/ou si l’icône de gestion de l’apparence du blog y est présente, et sur les deux pages correspondantes.
- Récupération de la liste des plugins et/ou des thèmes, avec un timeout de 5 secondes, uniquement sur la page de gestion des plugins (pour les plugins) ou de l’apparence du blog (pour les thèmes).
Si on considère qu’une page d’administration un peu chargée, entre autre le tableau de bord, met environ 2 secondes à récupérer toutes les ressources (code HTML, CSS, Js, images, …), on peut donc imaginer qu’il ne faudra, au pire, que 7 à 8 secondes à celle-ci pour s’afficher complètement si aucun des deux serveurs de la galaxie Dotclear ne répond.
En réalité c’est un peu plus complexe que ça, parce que ce n’est pas votre navigateur qui va interroger les deux serveurs en question, mais le serveur sur lequel vous avez installé Dotclear. Du coup ça devient une sorte de coup de billard à trois bandes, entre votre navigateur (le client), votre administration Dotclear (sur votre serveur), et les deux serveurs Dotclear et DotAddict.
Donc, à part permettre de désactiver temporairement ces requêtes en cas de souci, éventuellement réservé au seul super-admin de l’installation, je vois mal ce qu’on peut faire de mieux en l’état actuel des choses.
Z’avez des idées la dessus vous ?
PS : En attendant mieux, vous pouvez toujours ne pas afficher les news de Dotclear sur votre tableau de bord, pas plus d’ailleurs que l’icône de gestion des plugins et celle de l’apparence du blog, ça sera toujours ça de requêtes en moins entre votre serveurs et ceux de Dotclear et DotAddict.
PPS : J’aime bien fouiller dans le code et décortiquer un peu le fonctionnement de ce monstrueux bordayle qu’est une application web !
Note
[1] Un timeout est la durée maximum qu’attendra une réponse l’application après un envoi d’une requête, comme par exemple le flux RSS ou Atom des nouvelles de Dotclear, avant de considérer qu’il y a un problème. Dans ce cas là, les nouvelles ne seront simplement pas affichées.
1 De mume -
Tu causes comme Dom ,je n’y comprends RIEN !!!
2 De Franck -
C’est pourtant
simplebien compliqué :-)3 De Otir -
C’est donc ça qui m’arrive depuis deux ou trois jours ? Bien plus de 7 secondes et m’y reprendre à plusieurs reprises pour accéder à l’administration !
4 De Franck -
Tout à fait Otir, mais ça devrait être rentré dans l’ordre maintenant, non ?
5 De Philippe -
Suggestion : on pourrait avoir, sur l’écran de connexion, un mode standalone. Un peu comme on a un mode sans échec pour désactiver tous les plugins, mais qui lui ne vérifierait pas les mises à jour (avec peut-être un rappel sur le tableau de bord pour les étourdis) ? Ou bien plus radicalement une vérification en ajax seulement une fois que la connexion est établie ?
6 De mirovinben -
En plus du mode sans échec, je suggère un ajout dans l’URL pour accéder à l’admin sans devoir passer par auth.php (car on peut, comme je le fais, cocher la case “Se souvenir de mon identifiant sur cet ordinateur”) ni par l’étape “voyons s’il y a des mises à jours”…
Un ajout du genre
Ou un truc du style (car j’ignore tout des bonnes pratiques)… Vous voyez l’idée ?
7 De Franck -
Philippe le système Ajax signifie qu’il tournerait dans ton navigateur, or c’est entre le serveur (où est ton installation) et les serveurs DC/DA que ça coince, donc je vois mal comment faire ça.
L’idée d’un mode standalone rejoins celle que j’ai émise, en effet, reste à voir ce que ça implique question modifs de code (faut que j’optimise les maigres ressources disponibles, et ce n’est clairement une priorité).
8 De Dsls -
Hello,
Je pense que la méthode la plus saine serait de déporter ces vérifications/récupérations dans un script à part, récupéré coté browser en ajax. Cela ne pénaliserait pas le chargement de la page principale…
—
Bruno
9 De Dsls -
Bon … ça m’apprendra à ne pas lire les commentaires d’avant… une page type “reverse proxy” qui requêterait les sites DC/DA, appelée en Ajax.
En fait, dans une page php, dépendre d’un autre site, c’est toujours problématique. Il vaut mieux déporter le problème, et isoler ces dépendances dans une autre page (qui sert du REST), récupérée par le navigateur, et qui n’est pas dans la page principale affichée par le php.
10 De Franck -
Ou bien (quoi que le ou peut tout à fait être un et) déconnecter la récupération de la vérification. En gros, avoir une récupération régulière avec mise en cache pour la récup, et tant pis si les serveurs en face ne répondent pas, et d’autre part, la vérification qui s’appuierait exclusivement sur le cache.
11 De mirovinben -
Si mes idées vous paraissent inintéressantes, plutôt que de me prendre un
ventsilence glacé, ce serait bien de me dire en quoi ce que je propose est con.. Histoire de me permettre de continuer à alimenter mes neurones et de me re-donner envie de dotclearer.J’dis ça , j’dis rin.
Pour moi, si retard à l’allumage lors d’une connexion à l’admin ou si envie de ne pas voir systématiquement ailleurs (= dotclear.org/dotaddict.org), le fit d’avoir un signet avec une URL du genre (amélioré)
et un index.php qui sait quoi faire de cette URL, ce serait simple à mettre en place et facilement utilisable.
Non ?
12 De Franck -
mirovinben pas la peine de monter sur tes grands chevaux ! Relis plutôt ce que j’indiquais dans mon commentaire plus haut (n° 7) et tu verras que vu les ressources dispos pour coder, je n’en fais pas une priorité, surtout pour un événement qui arrive une ou deux fois par an.
Parce qu’avoir un système qui débranche ce genre de vérif, ok, mais faut coder tout ça, côté news, côté update de DC, côté update de DA (thèmes et plugins), c’est loin d’être faisable en deux minutes.
Donc ton « … et un index.php qui sait quoi faire de cette URL, ce serait simple à mettre en place et facilement utilisable. Non ? », c’est plutôt non, c’est pas simple.
13 De mirovinben -
Justement, je ne comprends rien à ce que vous dites (Ajax ? standalone ? reverse proxy ? serveurs machins ou trucs ?)…
Ma proposition consiste uniquement à court-circuiter dans l’admin de l’utilisateur tout ce qui peut faire appel aux fonctions qui vont voir ailleurs. Ni plus ni moins. Juste (!?) le positionnement d’une constante/variable et les tests kivonbien aux bons endroits… Si je savais où, je mettrais en place.
Sinon, merci de m’avoir répondu alors que je suis plutôt à cran ces temps-ci.
Bisous…
…qui piquent (forcément).
14 De Dsls -
Pour moi, l’idée c’est que chaque page affichée dans l’admin ne doit pas dépendre de pages issues de sites externes. Toutes les pages de sites externes doivent être récupérées après le chargement de la page affichée, de manière asynchrone, et par le navigateur. Ainsi la page affichée n’est pas pénalisée par des timeouts.
15 De Franck -
mirovinben, ton « Ma proposition consiste uniquement… » est facile à exprimer, mais prendra du temps (pas mal) à être mise en place, même si ce ne sont qu’une variable, des tests, etc, parce qu’il faut aussi s’assurer que ça ne casse rien par ailleurs.
D’ailleurs mettre simplement une variable et des tests ça fait plus verrue qu’autre chose, alors je préfère de loin prendre le temps de réfléchir à tout ça et trouver un système plus élégant.
Dsls on est d’accord sur ce point, l’admin (dans le navigateur) ne devrait dépendre que de son serveur et du cache qui s’y trouve.
16 De Philippe -
Moi je dis que c’est Dsls qui s’y colle : ça lui apprendra à sortir le nez dehors en plein hiver.
Dsls c’est seulement si tu es d’accord pour le passage de patate chaude, hein :)
Et comme ça, mirovinben et moi pouvons reprendre notre sieste tranquillement, comme il se doit