[spip-dev] Cache, POST et co

Dev
1

Bonjour,

j'ai une question concernant la gestion du cache.

## Contexte

recherche d'amélioration des perfs de formidable table sorter

## Explication du processus

Formidable tablesorter envoie une requete AJAX pour récupérer un fichier JSON contenant les données à afficher. Cette requete est un peu longue, car elle contient des infos sur les filtres, tri, etc. Par conséquent impossible de l'envoyer en GET, mais uniquement en POST, bien que cela n'influence nullement le contenu de la base, mais uniquement le résultat du fichier json.

Ce fichier JSON est généré via différentes fonctions, qui, ultimement, appellent `calculer_voir_reponse`, une fonction de formidable.

Cette dernière se base sur les squelettes saisies-vues./*.html pour montrer les résultats pour afficher la valeur correctement formaét, champ par champ et réponse par réponse.

## Problème

Comme j'envoie ma requete en POST (car paramètres potentiellement très long), je n'ai pas de cache (c'est prévu explicitement dans SPIP).

J'ai testé pour voir avec GET, sur un formulaire avec pas mal de réponse, on passe de 4 s à 100ms de temps d'attente avant que le serveur renvoie sa réponse.

## Question

Quelle est la solution la plups propre pour éviter ce problème ?

Merci d'avance pour vos éclairages

## Remarque

J'ai n'ai aucun souci de cache obsolète car

1. Si on modifie une réponse de formulaire via le tableau, bah il y une invalidation générale du cache
2. Comme dit, ma requete AJAX en elle même n'implique pas de modification en base

Maïeul

2

j'ai bien songé à mettre

if ($_SERVER['REQUEST_METHOD'] == 'POST' and $_REQUEST['page'] === 'formidable_ts.json') {
  $_SERVER['REQUEST_METHOD'] = 'GET';
}

dans mes_options.

Cela marche, mais c'est un peu moche.

3

Hello,

Je pense qu’il faut éviter le cache sur les POSTS

Quelle est la solution la plus propre pour éviter ce problème ?

  • Optimiser les filtres et s’appuyer le plus possible sur sql…
  • Tu peux également essayer de découper ta liste en faisant un inclure d’item pour que chaque item ai son propre cache contrairement à la liste.
    La chute des performance est souvent liée a une fonction récursive dans chaque item.
4

Hello,

Je pense qu'il faut éviter le cache sur les POSTS

Quelle est la solution la plus propre pour éviter ce problème ?

- Optimiser les filtres et s'appuyer le plus possible sur sql..

Malheureusement si je fais cela, cela veut dire que je renonce à m'appuyer sur la présentation des saisies tels que dféinies dans saisies-vues

- Tu peux également essayer de découper ta liste en faisant un inclure d'item pour que chaque item ai son propre cache contrairement à la liste.
La chute des performance est souvent liée a une fonction récursive dans chaque item.

Heu, je ne vois pas ce que cela changerait, puisque de toute facon à partir du moment où il y a un POST, et ben on ne prend rien du tout en cache cf

De plus en fait chaque item à deja son propre cache : précisement le cache SPIP calculé à partir du squelette :slight_smile:

5

Pour un fonctionnement un peu identique, j'ai opté par faire une requete ajax sur un squelette qui renvoie un json. Comme cela, le squelette est mis en cache.

6

Bah moi aussi c'est une requete AJAX. Simplement cela l'empeche pas d'être en POST et pas en GET. Si je faisais en GET, j'aurais des problèmes d'URL trop longue. Si je fais en POST, j'ai le problème de non mise en cache (c'est ce que j'expliquais dans mon message au début !)

7

Pas de solution si ce n’est de réfléchir à revoir ton api et le format de tes URLs pour les simplifier et pouvoir rester en GET.

C’est pas juste SPIP hein, c’est une convention liée à HTTP même :
GET c’est pour collecter des données
POST c’est pour envoyer une modification de données

A partir du moment où tu prends des libertés avec ça, il y a des soucis...

8

oui, je me doutais que j'allais avoir ca comme réponse. Evidement le
problème c'est que je suis engagé avec une librairie prévu au départ,
je ne sais pas pourquoi, pour POST.

Je vais voir à trouver exactement ce qui rallonge l'url, et si je peux
encoder cela autrement.