Optimisation distante

Pas vraiment du code à partager, une expérience…

Un base “historique” qui, par la force des choses, doit être utilisée en distant. Comme souvent dans des bases 4D, le démarrage lit des tas de données utilisée dans l’interface pour constituer listes hiérarchiques et autres popups, qui vont être utilisés dans dieu sait combien de formulaires durant la session. Genre ça :

Code :
//sur ouverture
chercher donnees liste 1
constituer liste 1
chercher donnees liste 2
constituer liste 2
etc.

• temps de démarrage ~une minute (adsl = cruel)

on choppe les boules et comme on n’a pas du tout envie de revoir toute l’interface, on refactorise comme ça :

Code :
//sur ouverture
$donneesPrechargées:=methodeExecuteeSurServeur //collecte les données nécessaires, retourne tout un objet $0
constituer liste 1 ($donneesPrechargées)
constituer liste 2 ($donneesPrechargées)
etc.

• plus que 3-4 secondes : yesssss !

Mais grattons encore…

On modifie methodeExecuteeSurServeur, au lieu de $0 objet elle retourne $0 blob :

Code :
//methodeExecuteeSurServeur
… collecter plein de truc en $objet …
VARIABLE VERS BLOB($objet;$blob)
COMPRESSER BLOB($blob)
$0:=$blob

• 1,5 secondes

Comme je le dis souvent, en distant il vaut mieux envoyer une fois le camion que 50 fois la mobylette. Mais, franchement, je ne m’attendais pas à un gain pareil !

En ces temps de confinement, il serait Intéressant de rajouter une option de base pour compresser les paquets directement par 4D (il serait Intéressant de voir les gains obtenus sur des réseaux où le débit est faible).

Mais, l’autre GROS problème actuellement ce n’est pas seulement le débit c’est ÉGALEMENT la stabilité du réseau qui est malheureusement cruciale lorsqu’on utilise 4D en connexion directe à travers internet (ou via un VPN). Dans des situations de connexions non stables, la seule réelle alternative possible est les serveurs de type TSE…

Dans le cas d’un objet retourné par une méthode EoS, clairement ça ne doit pas être compressé, puisqu’on améliore en le compactant (ça passait de 1,5Mo à 500K). C’est une optimisation qui pourrait être faite par 4D, je pense, car je suppose que ces méthodes qui retournent des objets fabriqués par le serveur doivent stringifier $0 sur le serveur, envoyer, déstringifier sur le client.

Cependant il ne faut pas perdre de vue que le principal facteur de ralentissement n’est pas le volume transféré, mais le nombre de transferts. On a obtenu notre principal gain avec la réduction du nombre de requêtes, la réduction du volume transféré n’était que la cerise sur le gateau.

La stabilité du réseau à travers internet et vpn, je pratique depuis des années, ça n’a jamais été un souci. J’exclue de travailler avec un poste qui se promène dans 18 étages avec wifi ou dans le TGV, par contre.

: Arnaud DE MONTARD

La stabilité du réseau à travers internet et vpn, je pratique depuis
des années, ça n’a jamais été un souci. J’exclue de travailler avec
un poste qui se promène dans 18 étages avec wifi ou dans le TGV, par
contre.

Ça se voit que tu ne fais pas de support :roll: Depuis le début de ce confinement on passe notre temps à expliquer le principe du télétravail la différence entre les connexions directes, à travers en VPN, ou via des serveurs TSE.

Le wifi défaillant, le réseau 4G, etc. tu serais surpris de la réalité ; tout le monde ne dispose pas de la fibre loin de là. Et un débit performant ne va pas de pair avec une bonne stabilité de la ligne malheureusement… :frowning:

Et ton optimisation, c’est bien beau, mais dans une application préexistante ce n’est pas seulement à l’ouverture que tu as à optimiser ton code mais partout !!!

Si tu développes aujourd’hui ben tu peux y réfléchir (et encore), cela demande une sacrée réflexion pour tout, et malgré tes optimisations sur un réseau non stable cela ne servira à rien car le client sera régulièrement déconnecté. (perte de donnée, etc.).

Salut Arnaud,

Je confirme que même en local c’est beaucoup plus rapide !

Initialiser sur le serveur et récupérer par des transferts de variables évite de toute façon toutes les sélections et autres chargements que peuvent faire les postes clients… surtout qu’ils font en général tous les mêmes au démarrage !

Chez un client il y a au environ 25 ans les temps de démarrage étaient passés comme toi d’environ 1 minute à 3-4 secondes.

La compression dépend en effet du volume de données transmises.

En tout cas c’est une bonne habitude à prendre notamment en période de confinement… C’est la bonne occasion de revoir pas mal de code :smiley: