Les battements de l'API WordPress Heartbeat sont-ils échelonnés ou se produisent-ils simultanément pour tous les utilisateurs?

L'API WordPress Heartbeat utilise admin-ajax.php pour exécuter les appels AJAX. Si l'utilisateur X laisse son navigateur ouvert, de nombreux appels seront effectués vers le serveur, chaque appel se produisant lorsqu'il y a un «battement». Maintenant, si l'utilisateur Y laisse son navigateur ouvert, de nombreux autres appels seront effectués vers le serveur, chacun de ces appels se produisant lorsqu'il y a un «battement». Il est possible qu'un grand site Web ait également l'utilisateur A, l'utilisateur B et l'utilisateur C faire la même chose.

Ma question:

Étant donné que de nombreux utilisateurs peuvent accéder simultanément à un site Web, les battements de l'API WordPress Heartbeat sont-ils échelonnés (le battement pour l'utilisateur X se produit quelques secondes avant le battement pour l'utilisateur Y) ou un battement se produit-il exactement de la même manière? temps pour tous les utilisateurs?

Si les «battements» ne sont pas échelonnés, ma préoccupation est une charge très lourde sur le serveur au moment où un «battement» se produit.

php server-load heartbeat-api

— Henrywright
source

Je ne connais pas la réponse à cela, mais c'est intéressant. J'imagine que vous pourriez faire un test de base en vous connectant à la zone d'administration à partir de plusieurs navigateurs / ordinateurs et en examinant de plus près les demandes de pulsation et les exécutions de script PHP correspondantes, un peu comme mentionné dans cet article .

— Nicolai

@ialocin J'ai activé un enregistreur de tiques il y a quelques jours pour vérifier cela, mais j'ai ensuite oublié de l'éteindre alors quand je l'ai vérifié aujourd'hui, la quantité de tiques était assez effrayante ;-)

— birgire

Je peux imaginer qu'ils s'accumulent rapidement. L'exemple de votre réponse donne une bonne idée, je suppose .. @birgire

— Nicolai

Je pense que les battements sont décalés par nature, car la prochaine coche est déterminée par le temps du navigateur time()dans la scheduleNextTick()méthode du /wp-includes/js/heartbeat.jsfichier:

 var delta = time() - settings.lastTick,
     interval = settings.mainInterval;

où il est utilisé pour planifier le prochain tick avec la setTimeoutfonction:

if ( delta < interval ) {
    settings.beatTimer = window.setTimeout(
        function() {
            connect();
        },
        interval - delta
     );
} else {
    connect();
}

L'heure du navigateur est définie comme suit:

function time() {
   return (new Date()).getTime();
}

La connect()méthode contient l'appel ajax et utilisealways()

.always( function() {
    settings.connecting = false;
    scheduleNextTick();
})

pour planifier le prochain tick.

Les intervalles de ticks disponibles sont 5s, 15s, 30s et 60s.

Pour un grand nombre d'utilisateurs très actifs, avec un intervalle de tick court, les battements peuvent sembler se produire simultanément.

Il est toujours bon d'avoir des données, vous pouvez donc enregistrer les ticks des utilisateurs connectés, avec le heartbeat_tickcrochet:

add_action( 'heartbeat_tick', 
    function(  $response, $screen_id  )
    {
        $file =  WP_CONTENT_DIR . '/ticks.log'; // Edit this filepath to your needs.

        if( file_exists( $file ) && is_writeable( $file ) ) 
        {
            file_put_contents( 
                $file, 
                sprintf( "%s - Tick from user_id : %d - from screen_id : %s" . PHP_EOL,
                    date( 'c' ),
                    get_current_user_id(),
                    $screen_id
                ), 
                FILE_APPEND | LOCK_EX 
            );
        }
    }
, 11, 2 );

Voici un exemple tiré du ticks.logfichier:

2014-09-01T12:41:04+00:00 - Tick from user_id : 1 - from screen_id : edit-post
2014-09-01T12:41:19+00:00 - Tick from user_id : 1 - from screen_id : edit-post
2014-09-01T12:41:34+00:00 - Tick from user_id : 1 - from screen_id : edit-post
2014-09-01T12:41:56+00:00 - Tick from user_id : 1 - from screen_id : post
2014-09-01T12:42:11+00:00 - Tick from user_id : 1 - from screen_id : post
2014-09-01T12:42:20+00:00 - Tick from user_id : 3 - from screen_id : upload
2014-09-01T12:42:38+00:00 - Tick from user_id : 1 - from screen_id : post
2014-09-01T12:43:05+00:00 - Tick from user_id : 1 - from screen_id : post
2014-09-01T12:43:08+00:00 - Tick from user_id : 3 - from screen_id : attachment
2014-09-01T12:43:20+00:00 - Tick from user_id : 1 - from screen_id : post
2014-09-01T12:43:36+00:00 - Tick from user_id : 1 - from screen_id : post
2014-09-01T12:44:17+00:00 - Tick from user_id : 3 - from screen_id : profile

— Birgire
source

Merci pour cette réponse si détaillée. Ma compréhension est qu'il y a deux temps dans un cycle. Le battement initial qui est déterminé par le navigateur puis un battement de retour . Il ressort clairement de votre réponse que le rythme initial est décalé. Le rythme de retour (qui renvoie les données du serveur au navigateur) est-il également décalé?

— henrywright