[spip-dev] séparer la visite du site public et l'exécution du "génie"

JamesRezo · Décembre 7, 2011, 7:38

Hello,

Je repose ma question ici :

Est-ce que quelqu'un sait comment désactiver l'exécution du cron de
SPIP lors de la visite du site public pour l'éxecuter sur le serveur
de manière totalement indépendante (via le cron unix) ?

Une idée ?

cerdic · Décembre 7, 2011, 8:14

Utiliser le plugin Job_queue
+ un define conditionnel dans mes_options :
if (!_request('action')=='super_cron')
define('_DEBUG_BLOCK_QUEUE',true);

+ un hit sur spip.php?action=super_cron dans ton cron unix
(jamais utilisé, mais je crois que kent1 l'utilise sur son serveur)

Cela marchera quasi parfaitement sauf certaines actions comme 'Resyndiquer ce site maintenant' de l'espace privé, qui passe par le cron pour une question de verrou et sera bloqué dans ce cas.

Cédric

cerdic · Décembre 7, 2011, 9:51

Non. Ça n'a jamais empêché le cron de tourner. Au contraire, du coup il est appelé en fin de hit et fait attendre les visiteurs du site car il ne s'execute plus en tache de fond. Mais tout cela est obsolète avec Job_queue (intégré dans SPIP 3)

Cédric

Quentin_Drouet · Décembre 7, 2011, 9:54

Hello,

Je repose ma question ici :

Est-ce que quelqu'un sait comment désactiver l'exécution du cron de
SPIP lors de la visite du site public pour l'éxecuter sur le serveur
de manière totalement indépendante (via le cron unix) ?

Une idée ?

Utiliser le plugin Job_queue
+ un define conditionnel dans mes_options :
if (!_request('action')=='super_cron')
define('_DEBUG_BLOCK_QUEUE',true);

+ un hit sur spip.php?action=super_cron dans ton cron unix
(jamais utilisé, mais je crois que kent1 l'utilise sur son serveur)

Oué le super cron c'est de la boulette ... c'est pour ça qu'il est super...

Il faut avoir accès à fsockopen() aussi comme contrainte...

Pour un cron toute les minutes :

* * * * * curl http://www.tonsite.net/spip.php?action=super_cron >
/dev/null 2>&1

et hop...

Je l'utilise pour les encodages de spipmotion qui fonctionnent via cron :

et je l'utilise également pour mon plugin de gestion de mutu (à
publier d'ailleurs) qui lui va pinger les crons de toutes les
instances de mutu régulièrement :

Si tu as des remarques...

Cela marchera quasi parfaitement sauf certaines actions comme 'Resyndiquer ce site maintenant' de l'espace privé, qui passe par le cron pour une question de verrou et sera bloqué dans ce cas.

Ah ça je savais pas...

rastapopoulos · Décembre 7, 2011, 9:55

Je confirme que ça marche très très bien.

Par exemple, toutes les minutes (c'est le plus court possible) :
* * * * * curl monsite.fr/spip.php?action=super_cron

cerdic · Décembre 7, 2011, 9:59

En fait je me demande quel est l'intéret d'appeler le super_con plutôt que directement le cron ?

Cédric

Eric.C · Décembre 7, 2011, 10:12

C'est intéressant de connaitre le fonctionnement du CRON, j'ai lu cela : http://www.spip-
contrib.net/SpipCron et fait des recherches dans /ecrire/ (version 2.1.12).

Si je met dans "mes_options.php" :

define('_DIRECT_CRON_INHIBE',1);

cela désactive le cron naturel de SPIP au moment du calcul de la page ?

Ou si je met toujours dans "mes_options.php" :

function balise_SPIP_CRON ($p) {
  $p->code = '""';
  $p->interdire_scripts = false;
  return $p;
}

tout en plaçant dans chaque squelette la balise #SPIP_CRON cela revient au même : soit désactiver le
CRON non ?

D'autre part : en réouvrant mes squelette je me rend compte que j'ai mis la ligne suivante :
<div class="invisible"><img src="spip.php?action=cron" width="1" height="1" alt="-" /></div>
(cetainement une sombre histoire de validation W3C par rapport au code de la balise, ça fait
longtemps que je l'ai écrit...).

Sans balise #SPIP_CRON, cela veut dire que comme SPIP ne la trouve pas, il se peut qu'il soit lancer
deux fois, une avant de servir la page et une avec l'image dans la page ?

Question subsidiaire : SPIP active le CRON sur le calcul d'une noisette ? ou quand on appele la
fonction "recuperer_fond" ?

cerdic · Décembre 7, 2011, 10:23

C'est intéressant de connaitre le fonctionnement du CRON, j'ai lu cela : http://www.spip-
contrib.net/SpipCron et fait des recherches dans /ecrire/ (version 2.1.12).

Si je met dans "mes_options.php" :

define('_DIRECT_CRON_INHIBE',1);

cela désactive le cron naturel de SPIP au moment du calcul de la page ?

Ah exact, cette constante a été introduite en 2.1.x pour le pilotage par job_queue

Ou si je met toujours dans "mes_options.php" :

function balise_SPIP_CRON ($p) {
  $p->code = '""';
  $p->interdire_scripts = false;
  return $p;
}

tout en plaçant dans chaque squelette la balise #SPIP_CRON cela revient au même : soit désactiver le
CRON non ?

Il semblerait, oui, en relisant le code exact. Mais je me demande si il n'y a pas un AND qui devrait etre un OR car le commentaire et le code ne sont pas cohérent ici http://core.spip.org/projects/spip/repository/entry/branches/spip-2.1/ecrire/public.php#L240

D'autre part : en réouvrant mes squelette je me rend compte que j'ai mis la ligne suivante :
<div class="invisible"><img src="spip.php?action=cron" width="1" height="1" alt="-" /></div>
(cetainement une sombre histoire de validation W3C par rapport au code de la balise, ça fait
longtemps que je l'ai écrit...).

Sans balise #SPIP_CRON, cela veut dire que comme SPIP ne la trouve pas, il se peut qu'il soit lancer
deux fois, une avant de servir la page et une avec l'image dans la page ?

Oui

Question subsidiaire : SPIP active le CRON sur le calcul d'une noisette ? ou quand on appele la
fonction "recuperer_fond" ?

Non, uniquement sur en fin de calcul de la page complète
Cédric

JamesRezo · Décembre 7, 2011, 10:24

super_cRon, cédric...

Ne dévalorise pas votre travail ...

Quentin_Drouet · Décembre 7, 2011, 10:35

+ un hit sur spip.php?action=super_cron dans ton cron unix
(jamais utilisé, mais je crois que kent1 l'utilise sur son serveur)

Je confirme que ça marche très très bien.

Par exemple, toutes les minutes (c'est le plus court possible) :
* * * * * curl monsite.fr/spip.php?action=super_cron

En fait je me demande quel est l'intéret d'appeler le super_con plutôt que directement le cron ?

super_cron est en fsockopen ... Il ne bloque pas l'appel si je me
souviens bien ... alors que d'appeler le cron ne libère le hit qu'à la
fin de l'exécution ...

Mais bon mes compétences en la matière ... sont vachement reconnues

Cédric

kent1

cerdic · Décembre 7, 2011, 10:56

oui mais comme justement le hit est lancé par le cron système, on s'en fout un peut que ça libère ou pas le hit.
Parce que du coup on génère deux hits apache au lieu d'un, ce qui est un peu dispendieux.

A verifier, mais je pense que un appel direct sur ?action=cron via le cron OS marcherait aussi bien et coûterait moins cher.

Cédric

JamesRezo · Décembre 7, 2011, 1:35

La première : tu dis " lorsque le site est peu fréquenté et que son
fonctionnement nécessite la réalisation de tâches à intervalle
régulier"

J'envisageai de dissocier les taches de fond de la visite du site
public pour alléger la charge d'un serveur web qui est très fréquenté.
Du coup, est-ce que ça vaut le coup de mettre en place ce sytème dans
mon cas ? (j'aurais du commencer par cette question en fait...)

La deuxième : si le but, c'est de dissocier les taches de fond de la
visite, est-ce que c'est pas dommage de passer par une commande "curl
http://www.monsite.xxx/spip.php?action=super_cron" qui du coup,
provoque une visite ? (c'est peut-être ce qu'explique Cédric, mais je
ne suis pas sûr)

Et 3 : spip.php?action=super_cron accessible via internet, c'est pas
dangereux pour les sites (attaque de type DOS) ?

cerdic · Décembre 7, 2011, 1:46

Si tu as des remarques...

La première : tu dis " lorsque le site est peu fréquenté et que son
fonctionnement nécessite la réalisation de tâches à intervalle
régulier"

J'envisageai de dissocier les taches de fond de la visite du site
public pour alléger la charge d'un serveur web qui est très fréquenté.

En pratique le cron n'est executé qu'a periodes fixes, la charge qu'il provoque est donc à peu près fixe
et ne dépend pas du nombre de visites (sauf si aucune visite, car aucun cron dans ce cas).

Du coup, est-ce que ça vaut le coup de mettre en place ce sytème dans
mon cas ? (j'aurais du commencer par cette question en fait...)

Pas certain que tu y vois quelque chose en effet...

Cédric

Quentin_Drouet · Décembre 7, 2011, 2:39

Si tu as des remarques...

La première : tu dis " lorsque le site est peu fréquenté et que son
fonctionnement nécessite la réalisation de tâches à intervalle
régulier"

J'envisageai de dissocier les taches de fond de la visite du site
public pour alléger la charge d'un serveur web qui est très fréquenté.
Du coup, est-ce que ça vaut le coup de mettre en place ce sytème dans
mon cas ? (j'aurais du commencer par cette question en fait...)

En gros je ne pense pas ... Moi je l'utilise particulièrement car les
encodages sons et vidéos de spipmotion sont lancés en cron ...

Si pas de visite / pas d'encodage / pas de vidéos visibles / rien à
voir / pas de visite / pas d'encodage / ... etc

La deuxième : si le but, c'est de dissocier les taches de fond de la
visite, est-ce que c'est pas dommage de passer par une commande "curl
http://www.monsite.xxx/spip.php?action=super_cron" qui du coup,
provoque une visite ? (c'est peut-être ce qu'explique Cédric, mais je
ne suis pas sûr)

En gros je ne pense pas que cela soit arrangeant pour toi
effectivement ... tout dépend des taches à effectuer ...

kent1

Eric.C · Décembre 7, 2011, 2:46

> C'est intéressant de connaitre le fonctionnement du CRON, j'ai lu cela : http://www.spip-
> contrib.net/SpipCron et fait des recherches dans /ecrire/ (version 2.1.12).
>
>
> Si je met dans "mes_options.php" :
>
> define('_DIRECT_CRON_INHIBE',1);
>
> cela désactive le cron naturel de SPIP au moment du calcul de la page ?

Ah exact, cette constante a été introduite en 2.1.x pour le pilotage par job_queue

Je vais l'utiliser en espérant que cela reste dans la version 3 ou que l'on retrouve quelque chose
d'équivalent tout en conservant ma ligne de CRON dans les pages que je veux.

> Ou si je met toujours dans "mes_options.php" :
>
> function balise_SPIP_CRON ($p) {
> $p->code = '""';
> $p->interdire_scripts = false;
> return $p;
> }
>
> tout en plaçant dans chaque squelette la balise #SPIP_CRON cela revient au même : soit désactiver le
> CRON non ?

Il semblerait, oui, en relisant le code exact. Mais je me demande si il n'y a pas un AND qui devrait etre un OR car le commentaire et le code ne sont pas cohérent ici http://core.spip.org/projects/spip/repository/entry/branches/spip-2.1/ecrire/public.php#L240

J'y avais pas porté plus attention mais il y a effectivement un petit bug logique au niveau de
l'équation, ce qui veux dire que actuellement SPIP ne lance le CRON automatiquement que sur une page
web ne contenant pas la balise #SPIP_CRON et si 'navigateur en mode texte'.

Donc la majorité des utilisateurs (navigateur non textuel) ne déclenchent le CRON que si la balise
est présente (ou équivalent).

Il faut bien mettre les deux lignes en OR (et ajouter les parenthèses) comme suit :

247 AND ( !strstr($page['texte'], '')
248 OR !preg_match(',msie|mozilla|opera|konqueror,i', $_SERVER['HTTP_USER_AGENT'])))

>
>
>
> D'autre part : en réouvrant mes squelette je me rend compte que j'ai mis la ligne suivante :
> <div class="invisible"><img src="spip.php?action=cron" width="1" height="1" alt="-" /></div>
> (cetainement une sombre histoire de validation W3C par rapport au code de la balise, ça fait
> longtemps que je l'ai écrit...).
>
> Sans balise #SPIP_CRON, cela veut dire que comme SPIP ne la trouve pas, il se peut qu'il soit lancer
> deux fois, une avant de servir la page et une avec l'image dans la page ?

Oui

Mais finalement non cf ci-dessus !!!!
Ouf pour moi sinon cela ferait 3 ans que je double le CRON, merci le bug !!!!
Présent depuis la version 1.9.2 au moins.

> Question subsidiaire : SPIP active le CRON sur le calcul d'une noisette ? ou quand on appele la
> fonction "recuperer_fond" ?

Non, uniquement sur en fin de calcul de la page complète
Cédric

Merci.