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 ?
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
Tu devrais peut-être regarder du côté du super_cron :
Intéressant : en utilisant un cron unix (asynchrone par essence vis a vis des actions utilisateurs)
il vaut mieux appeler le simple cron plutôt que le super cron (re-bis-asynchrone).
Mais sur mon hébergement le délai minimal de cron (anacron en fait) est 1h
donc encore trop pour un mail...
As tu vu dans le développement de ce fil ? L'usage du super_cron avec un cron semble déprécié puisque ça ajoute une asynchronie inutile en plus... et par ailleurs avec une période minimale de 1h pour l'anacron de mon hébergement c'est pas pertinent pour les envois de mails "en direct".
C'est pour cela que j'en viens à envisager l'insertion d'un script js.
As tu vu dans le développement de ce fil ? L'usage du super_cron avec un cron semble déprécié puisque ça ajoute une asynchronie inutile en plus... et par ailleurs avec une période minimale de 1h pour l'anacron de mon hébergement c'est pas pertinent pour les envois de mails "en direct".
Pour être précis, il faudrait écrire « Avec un varnish mal configuré » ou « pas du tout configuré pour SPIP »
Car dans sa proposition de configuration Fil tenait compte du cron, 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édric
Le 11 juin 2019 à 08:53 +0200, JLuc <jluc@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
Ç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 ?
Parce que du coup on génère deux hits apache au lieu d'un, ce qui est un peu dispendieux.
Si tu es à un hit près, oui peut-être
Le super cron ne fait rien d'autre qu'appeler l'action cron en asynchrone
donc c'est surtout de la complication inutile en plus
puisque dans le cron unix on peut appeler l'action cron directement.
Pour info, tu peux très bien lancer des hits sur le super_cron depuis une autre machine qui disposerait d'un cron plus souple d'usage.
Cette exploration se traduit par 2 demandes de modifications du code :
1) Il y a un bug dans l'action super_cron puisqu'elle appelle fsockopen
avec le port 80 par défaut.
Du coup sur un site https le super_cron ne marche PAS.
(sur mon site ça renvoie une 301 mais le fsockopen ne la suite pas)
Le super cron ne fait rien d'autre qu'appeler l'action cron en asynchrone
donc c'est surtout de la complication inutile en plus
puisque dans le cron unix on peut appeler l'action cron directement.
Du coup faudrait il supprimer ces 2 lignes de commentaires :
* Cette fonction est utile pour être appelée depuis un cron UNIX par exemple
* car elle se termine tout de suite
*
* Exemple de tache cron Unix pour un appel toutes les minutes :
* `* * * * * curl http://www.mondomaine.tld/spip.php?action=super_cron\`
ou les remplacer par simplement :
* L'intérêt de cette fonction est qu'elle se termine tout de suite
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 <jluc@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
Ç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 ?
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
--
Cédric
Le 11 juin 2019 à 18:31 +0200, JLuc <jluc@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 <jluc@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
>
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 <jluc@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 <jluc@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
Ç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 ?
