L’arrivée du web a mis à mal ce que l’on appelait à juste titre les clients lourds, dans tous les sens du mot : lourds à charger sur les machines, lourds à installer, lourds à maintenir.
Mais l’on s’est vite aperçu que le web, tout client léger qu’il était, s’appuyait fortement sur le serveur (Web forcément) pour lui faire faire le travail auparavant traité par les clients lourds.
Certes c’était l’idée, qui permettait tout autant une mise en œuvre instantanée de l’application sur des clients, que d’accepter des supports matériels de puissance limitée, tels les clients légers et les smartphones, mais les conséquences étaient telles que les premières applications de ce type avaient toutes les difficultés du monde à monter en charge.
Le prix à payer
Concrètement, cette idée obligeait la mise en œuvre d’un serveur web dont la puissance devait être la somme de celles requises par les anciens clients lourds.
La tâche de ce serveur était tout autant d’accéder à la base de données, que de traiter les processus déclenchés et leurs conséquences sur les données, pour finalement les mettre en forme sous la forme de flux html, bien connus pour représenter dix fois le volume des données réelles.
Le client riche
Une des facettes de la charge du serveur web est le traitement du client comme un simple afficheur de page web construites et gérées de A à Z par le serveur.
La réponse pour soulager le serveur a été de passer d’un client html simpliste, à un client riche, capable de manipuler de façon autonome la mise en forme finale et l’intelligence de l’interface utilisateur.
Pour le premier point, l’exploitation de flux xml ou json plutôt que html a réduit tout autant le volume de données à transférer que le travail de mise en forme par le serveur.
Pour le second, le développement de Java coté client et surtout Javascript a fortement diminué le nombre d’aller-retours client serveur et donc de fait le travail du serveur
Les architectures multi-tiers
Mais cela ne suffit pas pour protéger le serveur des demandes complexes du client.
Pour parler simplement si une action qui coûte 1 seconde au client déclenche un traitement de 20 secondes sur le serveur, non seulement il suffira de peu de clients pour saturer le serveur, mais de plus un utilisateur ne recevant pas de résultat immédiat sera tout à fait capable de resoumettre sa demande et de charger encore plus le serveur.
Une première ligne de défense consiste à rendre le serveur capable d’évaluer les demandes illégitimes ou abusives, soit en limitant le nombre de demandes d’un client, soit en rejetant les requêtes trop coûteuses vers la base des données. Cette technique anti DOS (Denial Of Service) requiert que le serveur soit plus évolué qu’un simple passe plat pour des requêtes SQL et qu’il maîtrise l’identité de ses différents clients.
On n’est donc déjà plus dans le cadre s’un simple serveur Web mais d’un serveur applicatif.
Le serveur applicatif
Mais la vraie défense aussi bien en termes d’expérience utilisateur que de performance est de créer un réel serveur applicatif, indépendant du serveur Web et de la base SQL, capable de prendre en charge, d’ordonner et de dédoublonner les traitements.
Voici quelques exemples des tâches qu’il pourra gérer : l’action du client génère un envoi de mails à des nombreux acteurs, c’est le serveur qui établi le dialogue avec chacune des cibles et se contente d’informer le client du lancement de son traitement, la durée réelle dépendant de facteurs externes.
Mais cela peut aussi concerner une action qui aura un impact sur de multiples objets dans la base de données ou déclenchera un re-calcul massif. Le serveur applicatif mutualisera aussi les demandes pour éviter des calculs trop répétitifs.
La dernière des possibilités d’un serveur applicatif, certes déjà ancienne, est d’héberger les traitements batch, ou la surveillance des autres composants.
Olivier Piochaud, PDG d’Apsynet
