J'ai récemment découvert l'API Transients dans Wordpress dans l'espoir d'améliorer les performances du plugin que j'essaie d'écrire.
En gros, le plug-in stocke les détails du produit de l'API de publicité du produit Amazon dans la base de données. Les détails du produit sont stockés en utilisant la représentation codée JSON du tableau.
Maintenant, j'essaie d'utiliser l'API transitoires afin que, chaque fois que l'administrateur purge les enregistrements de la base de données, il se mette également à jour à l'aide de l'API transitoires.
Ce que je suis en train de faire, c'est de stocker la valeur encodée JSON en utilisant la méthode set_transient
. Quelque chose comme ça:
$data = array(
'123' => "{'title' : '', 'price' : '', 'brand' : ''}"
'456' => ...
);
$value = json_encode($data);
set_transient('Amazon_items', $value, 60 * 60);
Et puis je l’obtiens à partir de là en utilisant get_transient
$asin = '123';
$data = json_decode(get_transient('Amazon_items'), true);
print_r($data[$asin]);
Est-ce correct ou dois-je simplement le stocker dans un tableau pour pouvoir y accéder directement sans utiliser json_decode
? Mon cas d'utilisation est-il acceptable ou est-il excessif? Puis-je encore améliorer celui-ci? Existe-t-il une limite spécifique au nombre de données que je peux stocker à l'aide de l'API transitoires? Dans ce cas d'utilisation particulier, je m'attends à plus de 50 Mo de données.
Est-ce correct ou dois-je simplement le stocker dans un tableau pour pouvoir y accéder directement sans utiliser json_decode?
Dans votre cas, stockez-le directement signifie stockez-le sérialisé . Parce que $data
est un tableau et ne peut pas être stocké tel quel, mais converti en chaîne.
Même si vous y accédez directement comme:
$data = get_transient('Amazon_items');
print_r( $data[0] );
la fonction get_transient
unserialize la valeur en coulisse (tout comme le set_transient
serialize en coulisse), à l'aide de la fonction WP maybe_unserialze
qui utilise la fonction serialize
php.
Donc, en utilisant json_encode
/json_decode
ou en utilisant la méthode standard php-serialize, il existe quelques différences, mais les performances sont presque les mêmes. Les personnes qui ont fait des tests disent que json_encode
est un peu plus rapide.
La méthode que vous devez choisir dépend de ce que vous avez à faire avec les données: si vous envisagez de les manipuler avec js (ou même avec des langages autres que php), le bon choix est très probablement json.
Si vous devez sérialiser un objet php, en conservant la classe d'origine, vous devez utiliser la sérialisation php:
$a = new MyClass;
$b = json_encode($a);
$c = json_decode($b);
$test = is_a($c, 'MyClass'); // false
$a = new MyClass;
$b = serialize($a);
$c = unserialize($b);
$test = is_a($c, 'MyClass'); // true
Existe-t-il une limite spécifique au nombre de données que je peux stocker à l'aide de l'API transitoires?
L'API transitoire utilise {$wpdb->prefix}_options
pour enregistrer les données. Dans cette table, la colonne option_value
où les données sont stockées est une colonne longtext
qui peut contient théoriquement 4 Go de données . Même si l’espace réel est réduit, 50 Mo ne devrait pas poser de problèmes (bien sûr, si l’espace disque dans le serveur est suffisamment grand).
LIKE %..%
...Je ne stockerais pas plus de 50 mégaoctets en transitoire. Je chercherais à le stocker dans le système de fichiers d'une manière ou d'une autre, ou à créer ma propre table de base de données spécifique pour stocker les données.
Considérez que si vous stockez le transitoire dans la base de données, chaque fois que vous le récupérerez, ce seront 50 Mo de données à envoyer de la base de données au serveur Web pour traitement. Et c’est 50 Mo de mémoire que PHP doit allouer pour le contenir. Et ainsi de suite. Utilisez-vous les 50 mégawatts à chaque fois? Non? Alors c'est inutile et idiot.
Séparez vos données. Ne le traitez pas comme un gros problème, mais stockez-le dans sa propre table, ou comme son propre type de message, ou autre chose. Utilisez les touches pour y accéder et accédez uniquement aux pièces dont vous avez besoin. Vous constaterez des avantages en termes de rapidité et une meilleure base de code pour travailler de cette manière.