web-dev-qa-db-fra.com

Quel est le cas contre les transitoires presque tout ce qui est principalement statique?

Supposons que j'ai un menu qui est simplement statique, pour la plupart des sites, ou plutôt, prenons mon exemple, un site de blogging, il ne change presque jamais, jamais.

Pourquoi ne pas l’accrocher à un transitoire qui n’expire jamais à moins d’être changé? Ainsi, si vous jouez avec ce menu, vous réinitialiserez le transitoire et obtiendrez la nouvelle instance, mais sinon, il ne sera jamais récupéré avec la requête complète elle-même.

Même chose pour les commentaires, même pour presque tout.

Est-ce une mauvaise idée?

Je comprends que cela concerne davantage l’architecture mais je pense que c’est une question importante qui a de profondes implications.

optimizationtransient
5
coolpasta

En fait, le faire pour le menu est bon, vous pouvez même stocker la sortie HTML entière et couper non seulement les requêtes, mais le temps de traitement. De plus, vous pouvez utiliser WP_Object_Cache directement en conjonction avec le backend Redis/Memcached et éviter même une seule requête de base de données pour le transitoire lui-même.

En ce qui concerne les commentaires, ils changent. Il est donc inévitable d’exécuter WP_Comment_Query. Cependant, vous pouvez également les mettre en cache, pour un court laps de temps. Dis, 5 minutes. Dans ce cas, vous devez trouver un équilibre entre le gain de vitesse que vous gagnez et le délai nécessaire pour que les utilisateurs voient leurs nouveaux commentaires.

La règle de base est de mettre en cache si nécessaire, quand cela vous donne un impact positif et n’introduit pas d’impact négatif.

WordPress fait déjà du bon travail en mettant en cache la plupart des choses importantes (y compris les éléments de menu) - il suffit de mettre la classe de cache d’objets dans le contenu WP et d’ajouter un backend de cache d’objets sur votre serveur.

3
Ihor Vorotnov

Après quelques mois de cela, je pense que ma question initiale est très bien fondée et bien que cette technique ne soit sûrement pas nouvelle, voici ce que je fais pour optimiser considérablement beaucoup de choses dans mon système:

(C'est plus philosophique, mais je fournirai du code)

Je ne parlerai pas du fait, espérons-le, compris que vous ne devriez pas avoir d'éléments transitoires/des requêtes qui vont affecter votre flux de travail, ni que vous devriez tout faire de travers, car cela surchargerait la base de données, en particulier avec beaucoup de gros requêtes - un exemple serait, sur un hôte pas très bon, faire la transition entre les messages de chaque utilisateur (en supposant que vous ayez une grande communauté) en throves est un gros no-no. Vous avez peut-être des utilisateurs inactifs ayant chacun 10 à 15 publications, mais personne ne se rend sur leur page; leurs données resteront donc inactives dans la base de données, attendant simplement que quelqu'un y accède se réinitialise. (Ceci est résolu en créant simplement le transitoire sur la page de cet utilisateur, ce que, espérons-le, vous faites déjà!)

Quoi qu’il en soit, c’est exactement ce que nous devons faire: au lieu de penser aux transitoires en termes de délai d’expiration, nous devrions les approcher de la même manière.

Donc, au lieu de:

set_transient( 'name', 'value', 3600 );

Nous devrions simplement définir le transitoire sans heure et laisser un "objet plus propre" le gérer. Entrez les choix architecturaux. Nous devons regarder ce que ce transitoire enregistre/de quelle manière et décider quand exactement il est préférable de le supprimer. Supposons donc que nous traitons des publications d'un utilisateur et que nous ne réactualisons pas son transitoire avec une minuterie. Ce que nous pouvons faire, c'est accrocher à save_post et recréer ce transitoire chaque fois que l'utilisateur poste un article. Ainsi, notre transitoire ne se mettra jamais à jour que lorsque l'utilisateur créera lui-même un nouveau message:

add_action( 'save_post', function( $post_id, $post, $update ) {
    $author = get_post_field( 'post_author', $post_id );
    /**
     * But if he is, then we'll delete his posts' transient.
     */
    delete_transient( 'user_posts_' . $author->ID );
});

Ce que nous avons réalisé ici n’est jamais de supprimer un transitoire, sauf s’il doit être supprimé.

Maintenant, ce transitoire sera recréé quand quelqu'un va sur la page de cet utilisateur et ne sera pas sur une minuterie.

Le seul problème est que la base de données grossit maintenant. Nous avons donc besoin d'un mécanisme de collecte des déchets qui ne garde pas les transitoires qui ne sont pas "populaires" dans la base de données, nous ne l'encombrons donc pas.

J'ai réussi à l'appliquer aux transitoires liés aux images de la bibliothèque multimédia, où j'aurais besoin d'un transitoire, mais j'aimerais également un déclencheur pour le mettre à jour.

En terminant, plus je regarde cela, plus je pense que cela devrait s'appeler "savoir quand vous devez mettre à jour un transitoire".

Jusqu'à présent, il a résolu beaucoup plus de problèmes qu'il n'en a provoqué, mais je conviens qu'il n'est pas certain que cela fonctionne correctement ou non. Dans le même temps, la nécessité de l’échelle est un problème important et que, si vous codez le système de cette manière, il vous suffit de déconnecter ces mécanismes de suppression pour que celui-ci fonctionne de manière traditionnelle.

Alors, qu'est-ce que cela m'a aidé à atteindre exactement? Quels sont les bénéfices?

Les transitoires sans se sentir réellement transitoires. Maintenant, chaque fois que vous effectuez une action, vous voyez son résultat. Dans ce cas, il vous faudra attendre un moment pour voir l’effet (une fois le transitoire expiré). Il suffit d'actualiser et les nouvelles données sont là, pas besoin d'attendre, pas besoin de perdre les avantages.

En fait, il est plus logique de supprimer les transitoires sur un déclencheur plutôt que sur une minuterie.

1
coolpasta