La première idée est de calculer les réponses à la demande, et de faire de son mieux pour le faire vite. Cependant lorsque le nombre d'utilisateurs connectés (en tant que 4D client ou via le web) augmente, ou lorsque les calculs sont très complexes et mettent en oeuvre de nombreuses requêtes, il est parfois difficile d'obtenir des temps de réponse satisfaisants. Nous pouvons aussi nous trouver face à des requêtes qui phagocytent toutes les ressources du serveur, ou perturbent totalement l'usage normal de la base en vidant le cache mémoire pour faire place aux éléments nécessaires à la réponse espérée.

En y regardant de plus près, on peut se rendre compte qu'il est totalement inutile de calculer des résultats soit à la demande, soit totalement exacts, soit les deux à la fois.

Prenons l'exemple d'une société classique ayant des clients, des commerciaux dirigés par un directeur commercial, et des comptables. Chaque matin le directeur commercial regarde le chiffre d'affaires du mois en cours afin de savoir l'état des ventes. Mais que regarde-t-il vraiment ? Le chiffre d'affaires ou le pourcentage que représente ce chiffre d'affaires par rapport à l'objectif mensuel qui lui a été assigné ? Il y a fort à parier que le chiffre qui l'intéresse le plus n'est pas le montant du chiffre d'affaires mais le pourcentage du CA réalisé ! A partir de là nous pouvons éviter nombre de calculs, ou plus exactement les décaler dans le temps.

Effectivement, si c'est le pourcentage qui focalise l'attention de notre directeur commercial chaque matin, nous pouvons lui proposer un chiffre calculé avant l'ouverture des bureaux, c'est-à-dire au moment où l'activité de la base est faible. Au moment de la lecture du chiffre par notre directeur commercial, il y aura peut-être deux ou trois heures que ce chiffre aura été calculé, ce chiffre ne sera donc pas en temps réel, mais est-ce important ? En effet, les quelques factures qui seront rentrées le matin ne feront varier probablement le pourcentage que de quelques dixièmes. Si par bonheur (pour le service commercial), ou par malheur (pour le développeur) il y a une commande qui vient grossir considérablement le chiffre d'affaires, il y a fort à parier que la nouvelle sera connue du directeur commercial qui pourra considérer le chiffre pré-calculé comme obsolète.

Pour bien faire accepter ce genre de pré-calcul, j'utilise à la fois la transparence et la technique du chiffon rouge.

La transparence consiste à ne jamais masquer le fait que le chiffre est pré-calculé. Pour cela, je l'accompagne toujours de la date et l'heure à laquelle il a été réalisé. Je propose de plus, lorsque c'est possible, une fonction permettant le re-calcul immédiat du chiffre, et j'annonce que cela peut prendre un certain temps.

Parallèlement, j'utilise la technique dite du chiffon rouge : cette technique consiste à détourner l'attention (ici du fait que le chiffre est pré-calculé et potentiellement erroné) et attirant l'attention sur autre chose. Dans le cas de notre directeur commercial, je lui propose le chiffre via un e-mail personnalisé. Le chiffre est ainsi disponible directement dans sa boîte de réception sans qu'il ait besoin de se connecter à son serveur. Ce service lui procure le chiffre nécessaire pour le pilotage commercial de l'entreprise, et dans son inconscient il sait qu'une information par e-mail n'est pas une information instantanée, je n'ai donc pas besoin de me justifier sur mon choix trop longtemps !

Comme rien n'est jamais simple dans notre métier, nous pouvons nous trouver, avec les mêmes données de la même base, dans la situation totalement inverse. Effectivement, le service comptable de la société aura de son côté besoin de chiffres rigoureusement exacts au centime près. Cependant, les comptables ne travaillent pratiquement que sur des données figées et surtout écoulées. En effet, l'analyse comptable du premier trimestre ne commence pas en général avant la mi-avril. Pour nous, développeurs, cela peut-être une aubaine à saisir. En effet, nous avons plus d'une semaine pour préparer les données à fournir aux comptables, et nous pouvons donc à loisir préparer des ensembles prêts à l'emploi, des calculs... En d'autres termes, nous pouvons anticiper les demandes des comptables et préparer ce qui coûte cher en terme de ressources sur le serveur à un moment où elles sont peu sollicitées et non au dernier moment.

Le pré-calcul est une arme maîtresse pour l'optimisation de nombreux cas. Prenons par exemple le "top 10" proposé dans le forum 4D qui attribue un palmarès des contributeurs suivant plus d'une dizaine de paramètres. Ce calcul est très long à réaliser et fort heureusement il n'est pas effectué à chaque requête web. En effet ce "top 10" est réalisé une fois par jour avec de nombreuses temporisations afin de ne pas prendre plus de ressources que nécessaire. Pendant toute la durée du calcul, les données de la journée précédente restent disponibles et ce n'est qu'à l'issue du calcul que les nouveaux chiffres quotidiens remplacent ceux de la veille.

De la même manière, la liste des utilisateurs du forum proposée sur le côté droit de chaque page n'est pas calculée en temps réel. En effet, j'ai mis en place dans le forum un manager sous la forme d'une procédure stockée qui est appelée uniquement lorsqu'un nouvel utilisateur se connecte pour recalculer la liste. Ce manager se réveille aussi de son propre chef tous les quarts d'heure pour faire le ménage dans la liste et effacer ceux qui ne sont plus en ligne. La liste proposée est donc fausse si on la considère de manière instantanée, mais donne au contraire une vision des utilisateurs connectés dans le dernier quart d'heure.

Afficher des résultats décalés dans le temps peut-être une stratégie très payante tant que ces résultats sont clairement identifiables comme tels !

Pour conclure je tiens à vous relater une discussion "tendue" que j'ai eu à ce sujet avec un développeur qui me soutenait qu'il ne ferait jamais de calculs faux, son honneur était en jeu ! Je lui ai demandé alors qu'elle était la requête qui prenait le plus de temps et il m'a dit qu'elle ne durait que trois minutes, mais que c'était compréhensible car elle faisait un bilan complet du plateau commercial recevant les commandes par téléphone. Un peu plus tard dans la conversation, j'ai appris que le plateau rentrait environ une commande par minute.. Le bilan du plateau que le développeur croyait absolument exact était en fait faux car les données avaient évolué entre le début et la fin du calcul.

Par moment, nous n'avons pas d'autres choix que de rendre des résultats faux, à moins de figer l'activité de l'application.