Optimisez les performances ORDA en client/Serveur

Originally published at: https://events.4d.com/summit2020/session/optimisez-les-performances-orda-en-client-serveur/

Depuis 4D v17 R5, l’accès aux tables (contenant potentiellement des données volumineuses) en client / serveur a été considérablement optimisé.

4 Likes

Ce devait assez frustrant, je pense, d’enregistrer cette conférence sans public : ledit public tient à faire part de ses applaudissements virtuels, peut-être même aura t-il des questions - s’il parvient à digérer ce chouette plat de résistance :wink:

:clap: :clap: :clap: :clap:

:clap: :clap: :clap: :clap:

Looking forward to being able to define/save context. Great idea.

Question about object fields - suppose an entity has an object field with several properties defined but only one property is used or referenced. Does the entire object field become part of the context or is 4D able to select only the referenced property?

:clap: :clap: :clap:
Excellent session that really explains what is going on under the covers.

I got bitten by the Classic code not updating the ORDA cache feature a while ago, and it was a real pain to find out what was going on. I wish this session had been around then. :slightly_smiling_face:

One question; Are we able to see the log of what is happening with the queries? Or is that one of the features of the special version of 4D you used for the demo?

Thanks.

Hi Peter,

This blog explain how to enable the ORDA requests log.

https://blog.4d.com/optimize-your-orda-code-with-requests-logging/

Very interesting demo, very clear. :clap: :clap: :clap: :clap:

I learnt many stuff from this session including that 4D uses REST internally for ORDA data transfers.

Merci de ce retour. C’est très motivant :slightly_smiling_face:

1 Like

Hi,

For object fields, the optimization is not set up yet.
Even if you use only some properties of the object, the requests for 80 entity pages get all the object’s properties.

Thanks for the reply. I suspected as much. I think it would be difficult to select out specific properties in the context.

But this suggests grouping relevant data into object fields. Things like addresses and names when they are saved as multiple fields.

Bonjour,
dans une des diapos je vois Form.person.getContextAttributes(). Comme c’est vert (donc bien, d’après Olivier Deschanels), j’ai été voir keskeucéstruc dans la doc mais ne trouve rien : j’ai raté quelque chose ?

Bonjour,

Des member methods internes (telles que getContextAttributes()) ont été développées pour cette démo et ne sont pas exposées.

Par contre, tout ce qui concerne les log de requests est disponible --> https://blog.4d.com/optimize-your-orda-code-with-requests-logging/

J’ai posé cette question car ça me fait repenser à une chose qui me chatouille depuis un moment…

Quand 4D a annoncé la possibilité du stockage externe (hors de l’enregistrement, du data…) je me suis dit chouette, nous n’allons plus avoir besoin de déplacer nos champs volumineux dans une table “satellite” (par exemple [photo] -> [individu]). Puis j’ai compris qu’il n’en était rien, ou du moins pour pas mal de commandes, le serveur envoi l’enregistrement entier (y compris le vilain gros champ dont je sais n’avoir pas besoin). J’avais trouvé dommage qu’on n’ai pas la possibilité de fixer une propriété pour les champs “n’envoyer ce champ dans les requêtes que sur demande explicite” - 4D nous aurait concocté ça facile, par exemple LOAD RECORD([maTable];*), où étoile signifie “y compris les champs que par défaut je ne veux pas” :wink:

De cette conférence sur les contextes ORDA, je retiens que 4D apprend à ne charger que le nécessaire, vraiment très bien… Mais, sauf erreur, je retiens aussi que le" context" où il retient ça est une étiquette que je peux utiliser mais que je ne peux ni lire ni écrire, et qu’il faut au moins une 1ère requête pour amorcer ce processus d’apprentissage, voire quelques aller retours.

On m’a montré récemment un test pas drôle : une table de modèles 4d write pro, moins de 200 enregistrements, en WAN : on fait ds.MODELE.all(), et hop, roue multicolore d’une minute. Avec un get() à la place de all(), ça va mieux, mais je le sens passer tout de même et de toutes façons je vais devoir faire all juste après. Du coup l’idée du “exclure a priori” me revient, je me dis que ce serait bien qu’on puisse signaler à 4D serveur, pour une requête donnée, qu’on sait se contenter de peu.

1 Like

Bonjour,

Oui effectivement, les contexts, pour le moment, ne sont pas accessibles en lecture.
Il faut utiliser des attributs pour qu’ils finissent par figurer dans le context.