Le 12/06/2019 à 07:55, Cerdic a écrit :
Tu as aussi define(‘_HTML_BG_CRON_FORCE’,true) qui permet d’insérer l’appel au CRON dans le HTML de toutes les pages, à l'ancienne

Est-ce déprécié, pourquoi écris tu "à l'ancienne" ?

Je vois que ça insère l'XMLHttpRequest que j'évoquais au début
et donc ça convient bien derrière un varnish agressif.
Merci pour cette découverte.

D'ailleurs je vois que dans queue_affichage_cron qui utilise cette constante,
fsockopen se fait bien sur le port 80 ou 443 selon que http ou https
comme dans le fix proposé pour le super_cron.

Par contre dans les 2 cas il faudrait utiliser les constantes
_PORT_HTTP_STANDARD et _PORT_HTTPS_STANDARD si définies
plutôt que 80 et 443

JLuc




--
Cédric
Le 11 juin 2019 à 18:31 +0200, JLuc <j...@no-log.org>, a écrit :
Le 11/06/2019 à 11:10, Cerdic a écrit :
Pour être précis, il faudrait écrire « Avec un varnish mal configuré » ou « pas 
du tout configuré pour SPIP »

La configuration au niveau du serveur n'est pas faite spécialement pour SPIP,
mais d'autres configurations sont faites dans le htaccess du site.

Car dans sa proposition de configuration Fil tenait compte du cron,
Il ne fait pas grand chose : que limiter
et je connais un hébergeur qui utilise Varnish sans
aucun problème avec l’execution des crons en utilisant un réglage comparable…

C'est super cet hébergeur :-)
Vive les hébergements douillets pour SPIP !

À défaut de ce confort, pour l'instant j'ai inséré un appel au super_cron 
(aprés fix) en php dans le footer de chaque
page. Ce code n'est appelé que pour les pages qui ne sortent pas du varnish 
donc pas souvent, mais justement, notamment,
quand il y a besoin : aprés la validation d'un formulaire. Ça semble bien 
marcher.
Ouf !

JLuc


Le 11 juin 2019 à 08:53 +0200, JLuc <j...@no-log.org>, a écrit :
Hello

Sur un site derrière un varnish, les jobs ne sont plus exécutés que très 
épisodiquement,
semble t il.

Le problème se pose notamment
pour les mails d'authentification d'une inscription ou de rappel de mot de 
passe,
qui mettent tellement longtemps à partir que l'internaute s'inquiète et 
recommence
et contacte le support finalement...
C'est un site avec un millier de visite par jours environ

j'ai proposé le plugin "accelerer_job" qui permet de forcer l'exécution
d'un certain nombre de jobs filtrés par l'action, notamment via un bouton 
interactif.
https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/accelerer_jobs/trunk

Ça marche très bien dans l'extranet qui n'est pas varnishé,
et ce serait parfait par exemple pour forcer la synchronisation des 
mailsubscribinglist automatiques
dans le plugin mailsubscriber (todo ?)

C'est toutefois un peu rustre de proposer ce bouton dans le public (encore que 
ça aide à patienter !)
et de plus dans le public le texte du bouton y est aussi caché par varnish donc 
pas à jour.

Je pense qu'il faudrait insérer un code javascript dans le html
pour appeler en asynchrone une page qui envoie les mails arrivés à échéance.

C'est le même problème que pour les statistiques, ce pour quoi il existe
https://plugins.spip.net/statsjs.html
et qui utilise affichage_final pour insérer le code javascript.
Sur un site dont on construit le squelette, il vaut probablement mieux insérer 
dans le footer qu'utiliser
affichage_final mais ça semble une bonne inspiration.

Est-ce que je loupe qqchose ?
Y a til une autre piste ?

JL

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone



----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone



----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à