Trier un jeu de résultat en cache

[LordRhumSifflar]

Bonjour,

Dans un troquet après la réunion CF de novembre (ou décembre:)
Je crois me souvenir avoir aborder, (avec eric si mes souvenirs sont bons) un débat sur l'utilité de la mise en cache de query of query pour trier un jeu de résultat.

Je voulais juste vous donner un exemple qui illustre ces propos :

Line Numbers | Expand Code | Tout sélectionner

1.  
2. <!--- PARAMETRES--->
3. <cfapplication sessionmanagement="true" name="LordRhumSifflar_Application">
4. <cfset listChamps="A,B,C">
5. <!--- NOM DE LA REQUETE DOIT ETRE UNIQUE ENTRE SESSION--->
6. <cfset qCached = "nomDeMaRequete#SESSION.cfid#">
7.  
8. <cftry>
9.     <!--- TENTE LA RECUPERATION DE LA REQUETE EN CACHE--->
10.     <cfquery cachedwithin="#CreateTimeSpan(0, 0, 0, 13)#" name="#qCached#" dbtype="query" >
11.         SELECT * FROM q
12.     </cfquery>
13. <cfcatch >
14.         <!--- SI LA REQUETE N EXISTAIT PAS (timeout) (premier chargement)--->
15.         <!--- CREATION D UNE REQUETE--->
16.     <cfset q = queryNew("#listChamps#","Integer,Integer,Integer")>
17.     <cfloop from="1" to="10" index="index">
18.         <cfset QueryAddRow(q,1)>
19.         <cfloop list="#listChamps#" index="champs">
20.             <cfset querySetCell(q,"#champs#",RandRange(index-5,index),index)>
21.         </cfloop>
22.     </cfloop>
23.     <!--- MISE EN CACHE DU JEU DE RESULTAT (13 sec)--->
24.     <cfquery cachedwithin="#CreateTimeSpan(0, 0, 0, 13)#" name="#qCached#" dbtype="query" >
25.         SELECT * FROM q
26.     </cfquery>
27. </cfcatch>
28. </cftry><!---<cfdump var="#Evaluate(qCached)#" label="jeu de résultat à sauvegarder.">
30.  
31. --->
32.  
33. <cfquery name="qRequeteTrier" dbtype="query" >
34.     SELECT * FROM   #qCached#
35. <cfif IsDefined("url.ChampsATrier") >
36.     ORDER BY #url.ChampsATrier#
37. </cfif>
38. </cfquery>
39.  
40. <!--- SORTIE HTML --->
41. <cfoutput>
42.     <table border="1" cellpadding="10">
43.     <cfloop query="qRequeteTrier">
44.         <cfif qRequeteTrier.currentRow EQ 1>
45.         <tr><th colspan="#ListLen(listChamps)#">RESULTAT :</th></tr>
46.         <tr><td colspan="#ListLen(listChamps)#"><cfif IsDefined("url.ChampsATrier")>Trié par : #url.ChampsATrier#</cfif><br /></td></tr>
47.         <tr>
48.             <cfloop list="#listChamps#" index="champs">
49.             <th><a href='?ChampsATrier=#champs#'>#champs#</a></th>
50.             </cfloop>
51.         </tr>
52.         </cfif>
53.         <tr>
54.             <cfloop list="#listChamps#" index="champs">
55.             <td>#Evaluate("qRequeteTrier.#champs#")#</td>
56.             </cfloop>
57.         </tr>
58.     </cfloop>
59.     </table>
60. </cfoutput>
61.  

A bientôtô

[eric00000007]

Super. L'astuce est dans le nom de la requête relative à chaque session. Je me méfie des variables de sessions. C'est bien sur à utiliser en fonction de la mémoire du serveur et du nombre de sessions crées.

Cela semble être utile pour des tries de tableaux, mais 13 secondes semble peut pour un utilisateur. Pour quelle utilisation ou quel scénario utilises tu ce cache ?

[srappaille]

Bonjour,

Très sympa le troquet. Et en plus, il y avait des bières belges !

En ne touchant à rien d'autre, quelle différence cela donne en terme de performance si on place le résultat final en variable de session comme ceci sans utiliser "cachedwithin" ?

Line Numbers | Expand Code | Tout sélectionner

1. <cfset session.maRequeteEnCache = maRequete>

Bien à tous,

Serge

[LordRhumSifflar]

"Pour quelle utilisation ou quel scénario utilises tu ce cache"
J'utilise essentiellement cette technique pour préparer des tableaux en vue d'une impression (format pdf).
Cela permet par exemple de mettre en valeur différentes situations pour un même jeu de résultat sans pour autant ré-accéder à une base de données.
(Par exemple : Consolidation par date de commande puis par date de facturation)

pourquoi 13 sec? J'aime bien ce chiffre:). Non sans blague, d'une manière générale, je pense que le principe de mise en cache (ici avec cachedWhitin) est sensiblement toujours le même : il faut avant tout l'utiliser si nous connaissons le délai de rafraichissement des données. Au niveau interface un tri s'effectue souvent assez rapidement ,mais cela dépend bien sur du tableau, des habitudes de l'utilisateur etc...
Pour info 2 manières de forcer le rechargement de la requête :
- mettre le cachedwithin="#CreateTimeSpan(0, 0, 0, 0)#"
- <cfobjectcache action="clear" > (s'applique à tous les objets en cache.)


"quelle différence cela donne en terme de performance si on place le résultat final en variable de session comme ceci sans utiliser "cachedwithin" ?"
En terme de performance, je ne sais pas. Néanmoins cela permet d'avoir un timeout différent de celle des sessions. (en gros la requête en cache peut être libérer avant la fin d'une session).

[eric00000007]

La méthode de cache par session me semble séduisante mais il faudrait la tester dans un environnement en production.

Il faut surtout faire attention aux objets en cache et à la mémoire max pour cela, via le monitoring et les paramètre d'administration. Si il y a beaucoup de sessions concurrentes pendant ces 13 secondes et que le seuil de cache de requêtes est dépassé, ce cache n'aura plus d'intérêt.

Pour ma part, juste pour échanger mes pratiques (qui ne sont pas toutes bonnes)

• j'utilise le cahce de Query pour des requêtes sans paramètres redondantes pour différentes sessions.
• Je n'utilise pas de cache de query pour des requête avec des paramètres.
• Pour des requêtes gourmandes en temps j'optimise le SQL.
• Pour réutiliser des résultats de requêtes avec différentes vues, comme par exemple obtenir le résultat d'une requête en HTML, .DOC, .XLS, ... j'utilise toujours le même chemin, choix des paramètres -> la requête -> la vue.
  Je ne suis pas encore a l'aise avec le MVC mais c'est dans la même logique d'organisation du code.