Optimisation de 4D Server et 4D Web Server. Résumé. 4D Notes techniques

Optimisation de 4D Server et 4D Web Server

Par

Chiheb NASR, Ingénieur Contrôle Qualité, 4D SA Note technique 4D-200312-34-FR

Version 1

Date 1 Décembre 2003

Résumé

Dans cette présente note nous passons en revue les points les plus importants à connaître et à vérifier avant de déployer une base avec 4D Server. Nous étudierons à la fois les aspects logiciels et matériels car l’un ne va pas sans l’autre. La majorité des indications données sont également valables pour 4D monoposte.

4D Notes techniques

Copyright © 1985-2004 4D SA - Tous droits réservés

Tous les efforts ont été faits pour que le contenu de cette note technique présente le maximum de fiabilité possible.

Néanmoins, les différents éléments composant cette note technique, et le cas échéant, le code, sont fournis sans garantie d'aucune sorte.

L'auteur et 4D S.A. déclinent donc toute responsabilité quant à l'utilisation qui pourrait être faite de ces éléments, tant à l'égard de leurs utilisateurs que des tiers.

Les informations contenues dans ce document peuvent faire l'objet de modifications sans préavis et ne sauraient en aucune manière engager 4D SA. La fourniture d u logiciel décrit dans ce document est régie par u n octroi de licence dont les termes sont précisés par ailleurs dans la licence électronique figurant sur le support d u Logiciel et de la Documentation afférente. Le logiciel et sa documentation ne peuvent être utilisés, copiés o u reproduits sur quelque support que ce soit et de quelque manière que ce soit, que conformément aux termes de cette licence.

Aucune partie de ce document ne peut être reproduite o u recopiée de quelque manière que ce soit, électronique o u mécanique, y compris par photocopie, enregistrement, archivage o u tout autre procédé de stockage, de traitement et de récupération d'informations, pour d'autres buts que l'usage personnel de l'acheteur, et ce exclusivement aux conditions contractuelles, sans la permission explicite de 4D SA.

4D, 4D Calc, 4D Draw, 4D Write, 4D Insider, 4ème Dimension ®, 4D Server, 4D Compiler ainsi que les logos 4e Dimension, sont des marques enregistrées de 4D SA.

Windows,Windows NT,Win 32s et Microsoft sont des marques enregistrées de Microsoft Corporation.

Apple, Macintosh, Power Macintosh, LaserWriter, ImageWriter, QuickTime sont des marques enregistrées o u des noms commerciaux de Apple Computer,Inc.

Mac2Win Software Copyright © 1990-2002 est un produit de Altura Software,Inc.

4D Write contient des éléments de "MacLink Plus file translation", un produit de DataViz, Inc,55 Corporate drive,Trumbull,CT,USA.

XTND Copyright 1992-2002 © 4D SA. Tous droits réservés.

XTND Technology Copyright 1989-2002 © Claris Corporation.. Tous droits réservés ACROBAT © Copyright 1987-2002, Secret Commercial Adobe Systems Inc.Tous droits réservés. ACROBAT est une marque enregistrée d'Adobe Systems Inc.

Tous les autres noms de produits o u appellations sont des marques déposées o u des noms commerciaux appartenant à leurs propriétaires respectifs.

Optimisation de 4D Server et 4D Web Server

Dans cette présente note nous passons en revue les points les plus importants à connaître et à vérifier avant de déployer une base avec 4D Server. Nous étudierons à la fois les aspects logiciels et matériels car l’un ne va pas sans l’autre. La majorité des indications données sont également valables pour 4D monoposte.

I. Introduction

Le mode de fonctionnement client-serveur permet un accès simultané à une base de données par plusieurs utilisateurs. Le poste serveur intègre à la fois le fichier de données et l’ensemble des outils qui vont permettre leur traitement. Le poste client héberge un "Frontal" capable d’envoyer au serveur les commandes correspondant aux traitements à exécuter et de recevoir les informations nécessaires au suivi des tâches à effectuer. Dans ce type de fonctionnement, les recherches sont directement effectuées sur le poste serveur ; seuls les résultats de celles-ci sont communiquées au poste client. Le serveur exécute les requêtes reçues du client, stocke en mémoire les sélections correspondantes et n’envoie sur le réseaux que les données nécessaires à l’affichage ou à l’exécution des procédures.

II. Mise en service du serveur

Choix de la machine

Le niveau de performances du poste serveur conditionnera le résultat global. Généralement la machine doit être dotée :

• d’un disque rapide, afin de minimiser les temps d’accès sur le disque lors des recherches, des chargements et des écritures, monté sur une machine permettant un débit élevé. Par exemple, le débit des périphériques USB est limité à 15 Mo/s, il est donc important de les éviter au profit des disques Firewire ou autres technologies rapides.

• d’une mémoire importante, afin de permettre à 4D d’y maintenir en permanence la plus grande quantité possible de données exploitées et de minimiser ainsi les accès disque. Le temps d’accès d’une barrette mémoire est de l’ordre de nano-secondes alors que celui d’un bon disque est de l’ordre de millisecondes soit 100 000 fois plus lent.

• d’un processeur rapide pour minimiser le temps de traitement des données.

• d’un raccordement à un réseau suffisamment rapide pour ne pas générer de collisions. La notion de vitesse pure du réseau n’est pas un critère essentiel ; les temps d’attente sont généralement dus aux collisions existant sur le réseau et aux répétitions qu’elles entraînent plutôt qu’à sa lenteur intrinsèque. Les routeurs de mauvaise qualité sont souvent la cause d’un réseau "lent" par rapport aux données théoriques. Il peut être utile dans ce cas de réaliser un petit programme qui charge le réseau et dont on connaît les résultats sur un réseau correct.

Lors de l’installation sur un nouveau site, nous testons le réseau et comparons avec nos résultats.

• d’une alimentation électrique sur onduleur : en cas de coupure secteur, dans le meilleur des cas la totalité des

données contenue dans le cache sera perdue et dans le pire, coupure pendant l’écriture du cache, le fichier de données devient inutilisable et l’utilisation des utilitaires de réparation s’imposera.

Cette machine sera autant que possible dédiée à 4D Server et on évitera d’y faire tourner des accessoires consommateurs d’accès réseau ou de cycle processeur (messagerie, horloge…), ainsi que tout service tel que spool d’impression. Par exemple la bonne façon d’économiser l’écran d’un serveur est de l’éteindre.

Paramétrages système Le partage de fichier

Le partage de fichier sera de préférence désactivé sur le serveur afin d’économiser le temps consacré par la machine à l’écoute et à la gestion des éventuels accès externes et d’assurer une meilleure protection des fichiers utilisés par 4D Server qui seront inaccessibles à partir d’un autre poste.

La mémoire virtuelle

En ce qui concerne la mémoire virtuelle, Il est recommandé par Microsoft de la fixer à une taille égale à la taille de la mémoire physique (RAM) augmentée de 10 Mo. Pour un sytème Apple, elle sera activée et égale à la mémoire physique augmentée de 1 Mo. En effet, 4D Server gère son propre système de mémoire virtuelle (via le cache et le dossier temporaire) et il n’est pas utile que les deux systèmes entrent en concurrence.

Paramétrages de Windows NT Server, Windows 2000 Server ou Windows 2003 Server

Dans le cas d’un serveur fonctionnant sous Windows NT Server, 2000 Server ou 2003 Server, on vérifiera les trois paramètres suivants :

• Ces systèmes d’exploitation sont paramétrés par défaut pour favoriser le partage de fichiers ce qui ne convient pas du tout à 4D Server. Cette option doit être remplacée au profit des applications réseau. Ce paramétrage se trouve dans Démarrer/Paramètres/Panneau de configuration

/Réseau/Services/Serveur. Ce chemin peut être différent selon le système.

• Ces systèmes d’exploitation sont multitâches, un réglage permet de déterminer le niveau de priorité accordé à l’application de premier plan. Ce réglage prend la forme d’un "booster de performances" qui doit être réglé sur la position maximum pour optimiser le temps processeur et la gestion de mémoire dédiés à 4D Server. Ce paramétrage se trouve aussi dans le panneau de configuration du système.

• Il est également important d’optimiser dans le panneau de configuration Réseau la position du protocole le plus utilisé, généralement TCP/IP. Si plusieurs protocoles sont installés, ce dernier doit être le plus haut au sein de la liste.

III. Gestion de la mémoire sur le serveur

Il n’existe pas de formule unique et universelle permettant de calculer la mémoire à allouer à 4D Server. Afin de faire une bonne estimation de celle-ci, il est essentiel de bien comprendre les mécanismes de gestion de la mémoire par 4^èmeDimension. En effet, 4^èmeDimension découpe la mémoire qui lui a été allouée en trois parties :

la première sera réservée au moteur, la deuxième contient le cache (les données) et enfin une troisième partie que l’on appelle la mémoire principale.

La mémoire moteur

Au moment du lancement de 4^èmeDimension, cette partie est occupée par le moteur de 4^ème Dimension (512 Ko + 2,5 M o pour 4D Server). Les objets chargés en mémoire (4^ème Dimension et certains ressources) ne sont pas purgeables et restent présents pendant toute la durée d'utilisation de 4^ème Dimension. Ce qui revient à dire que cet emplacement ne peut être alloué à une autre application pendant que 4^ème Dimension est lancé.

La mémoire principale

Cette partie gère différents objets qui sont utilisés par l'application et qui sont chargés ou déchargés du disque selon leur utilisation. Cette zone contient :

• Une copie de l'enregistrement courant de chacune des tables de chaque process. Elle permet, lorsque vous utilisez les fonctionsANCIENet Modifie,de faire la comparaison pour détecter les modifications apportées.

Celle-ci ne contient pas les champs : Texte, Image et Blob.

• Tous les objets de structure (formulaires, méthodes, énumérations) ainsi que les sélections temporaires et les ensembles.

• Toutes les variables interprocess et process, ainsi que les variables locales de tailles non fixes (Blob, Texte, Image) et les tableaux.

• Le code des plug-ins.

• Une copie de la fenêtre de 4D qui sera utilisée, quand l'option "rafraîchissement plus rapide" des propriétés de la base sera cochée, pour améliorer les performances de l’affichage.

• La pile associée (STACK) à chaque process qui stocke les variables locales (en mode compilé seulement), le contexte du process qui assure le lien entre les différentes méthodes, certaines variables internes à 4D.

NOTE : Pour de plus amples informations sur la gestion de la mémoire par 4D, il est vivement recommandé de consulter les notes techniques 4D-200007-21-FR et 4D-200012-32-FR réalisées par Tim Tonooka, technicien support Clients 4D US.

La mémoire cache

Au démarrage de 4^ème Dimension, celui-ci s'alloue un bloc de mémoire, insécable et contigu, appelé cache. Il permet de sauvegarder les données de la base de données avant que celles-ci ne soient écrites sur le disque dur. Il joue le rôle d’un tampon entre l’application et la mémoire de masse. Pour estimer la taille à allouer à la mémoire cache on doit connaître le contenu de celle-ci et estimer la quantité de données normalement en service dans l’application :

• La table des bits (Bit-Table)

La Bit-Table est une table de gestion du fichier physique de données. C’est une représentation binaire du fichier de données en terme de blocs. En effet, le fichier de données est une succession de petits blocs, contenant chacun une information unique. Chaque bloc a une taille fixe de 128 octets. Cette taille est figée ; nous ne pouvons pas la paramétrer. Lors de la création du fichier de données, une table d’allocation est automatiquement créée et mémorisée dans 4 premiers blocs contigus. Chaque bit de ces 4 blocs est associé à un bloc du fichier de données. Le bit est à 0 si le bloc est libre et à 1 lorsqu’il est occupé.

• Les tables d'adresses des enregistrements (primaires et secondaires)

Les tables d’adresses, une pour chaque table 4^ème Dimension de la base, contiennent les adresses physiques de chacun des enregistrements de la table. Chaque entrée dans la table d’adresse est codée sur 8 octets : 4 pour l’adresse et 4 pour la taille de l’enregistrement. La table d’adresses est paginée via une page primaire et n pages secondaires . Chaque page peut contenir 4 096 adresses. Pour mémoriser les 16 777 216 enregistrements potentiels (depuis la version 6.7) il faudra 4 096 pages d’adresses (16 777 216 = 4 096 * 4 096). La formule suivante permet de calculer la taille (TTADR) occupée par l’ensemble des tables d’adresses d’une table 4^ème Dimension :

TTADR (octets) = 60 + (Nombre maximum d’enregistrements de la table 4D * (4 + 4)) octets

Les 60 octets servent à gérer la table d’adresses elle-même.

• Les pages d'index (primaires et secondaires)

Pour chaque enregistrement, la valeur du champ est mémorisé au sein de l’index et mise en correspondance avec l’adresse de l’enregistrement dans le fichier de données. Un index peut être comparé à un tableau à deux colonnes : une pour les valeurs de chaque enregistrement, et l’autre pour les adresses des enregistrements correspondants. Ce tableau est maintenu constamment trié en fonction des valeurs de la première colonne. La table d’adresses d’un index est également paginée et chaque page d’index contient 4 096 adresses. Le calcul de la taille de pages d’index est par contre beaucoup plus complexe car il dépend de plusieurs paramètres (le mode utilisé pour construire l’index, les mécanismes d’optimisation et de compression des index par le moteur 4^ème Dimension et enfin du contenu même des valeurs des champs indexés…). Toutefois on peut faire un calcul approché. Le nombre de clefs à un moment donné dans une page d’index varie en fonction de la version de 4^ème Dimension. Pour la version 6.0, ce nombre varie entre 16 et 32, pour la version 6.5 il varie entre 32 et 64. Par contre, depuis la version 6.7 jusqu’à la version courante 2003, ce nombre varie entre 128 et 256.

Soient N le nombre maximum d’enregistrements d’une table et βmin la plus petite valeur du nombre de clefs d'index. Le nombre maximal de pages d’indexNPIDXest égal à ((N/βmin )+1). Or, il y a 512 valeurs dans une page d’index, ce qui nous fait un nombre maximum de pages de tables d’adresses d’index NTAPIDX égal à

((NPIDX/512)+1). La gestion des pages d’adresses des pages index utilise 40 octets et chaque adresse de la table d’adresses des pages d’index pèse 4 octets. Finalement, le poids approximatif d’une table d’adresses d’un index POIDSTAIDX est donné par la formule suivante :

POIDSTAIDX= 40 + (NTAPIDX * 512 * 4) octets

• Les enregistrements qui proviennent ou partent du disque dur

Lorsque vous utilisez des commandes qui vont charger des enregistrements, 4^ème Dimension examine s’il a la place nécessaire disponible en fonction de la place mémoire qui lui a été allouée. Si 4^ème Dimension ne possède

pas assez de mémoire pour charger un enregistrement, il ne tentera pas de le charger et donc ne provoquera pas d’erreur. Dans certain cas, et par le biais de mécanisme d’évaluation de la place disponible, 4^ème Dimension peut estimer qu’il est possible de charger l’enregistrement alors qu’en le chargeant vous obtenez un message d’erreur

"Mémoire saturée" ou "Mémoire insuffisante". Si vous faites varier la quantité de la mémoire alloué à 4^ème Dimension en l’augmentant, vous ne rencontrerez plus de problèmes de chargement de vos enregistrements, mais un phénomène de swapping (transfert des données de la RAM vers le disque) peut s'installer (lié à la mémoire virtuelle), et il fera tomber les performances de 4D.

• Les sélections courantes

Une sélection est une table d’adresses qui contient la liste des numéros des enregistrements sélectionnés. La taille d’une sélection est égale au nombre des enregistrements sélectionnés multiplié par 4 octets à laquelle on doit rajouter 4 octets pour l’élément zéro qui va contenir l’adresse de l’enregistrement courant. La règle de 4 octets par enregistrement est valable pour tout type de sélection à l’exception de celle créée par la commande TOUT SELECTIONNERcar cette commande est optimisée dans 4^ème Dimension. En effet, lorsqu’on exécute TOUT SELECTIONNER([Table]), 4^ème Dimension crée une table exceptionnelle contenant les adresses des enregistrements qui ont été supprimés. L’optimisation se base sur le fait que 4^ème Dimension suppose que le nombre des enregistrements supprimés de la table est de beaucoup inférieur au nombre d’enregistrements actifs.

Par conséquent, la taille de la sélection des enregistrements supprimés est beaucoup plus économe en terme d’occupation mémoire. 4^ème Dimension maintient une sélection courante par table, par process et par utilisateur. Par exemple, si un utilisateur a quatre process simultanés et dix tables, alors il possède à lui seul 40 sélections courantes. En client-serveur cette sélection est maintenue sur le serveur. Au démarrage de 4^ème Dimension, la sélection courante de chaque table est vide. A chaque fois que l’utilisateur exécute une commande ou une action qui construit une sélection courante, 4^ème Dimension créé une nouvelle table de sélection qui réserve 4 octets pour chaque enregistrement sélectionné. Si 4^ème Dimension ne dispose pas d’assez de mémoire pour maintenir la totalité de la sélection, il stocke une partie de celle-ci dans un fichier temporaire sur disque.

Ecriture du cache sur le disque

Lorsque le cache de données est plein ou quand 4^ème Dimension souhaite y charger de nouveaux objets, il provoque l’écriture sur le disque (le flush) d’une quantité de données présentes dans le cache correspondant au pourcentage de mémoire cache fixé dans la rubrique “minimum flushé“ de la ressource "Cache" de l’application.

Ce pourcentage est par défaut 15%. Si vous le diminuez vous générez des écritures de plus courte durée mais plus fréquentes. Dans le cas contraire, le pourcentage du cache “flushé“ sur le disque étant plus important, chaque écriture durera plus longtemps mais l’intervalle de temps entre deux écritures sera plus important. Ce paramètre est important dans le mesure où l’écriture du cache provoque un ralentissement de l’accès des utilisateurs aux données de la base.

Différentes stratégies peuvent être adoptées en contrôlant l’écriture du cache par programmation avec la commandeECRIRE CACHE.

• Ecriture chaque fois qu’une table considérée comme significative aura vu son volume augmenter d’un nombre relativement important d’enregistrements ;

• Ecriture déclenchée par un process dédié lors d’une pause d’activité (aucun autre process actif depuis plus de x secondes) ;

• Ecriture lors de chaque action d’ajout ou de modification "stratégique" afin de lui apporter plus de sécurité.

La compression des index dans le cache

4^èmeDimension favorise le maintien des pages d’index dans le cache par rapport aux autres objets. En revanche, les pages d’index contiennent souvent des données constituées de nombreuses valeurs répétitives (index booléens, champs associés à des énumérations, …etc). 4^ème Dimension propose une compression des pages d’index dans le cache, afin qu’elles y soient présentes sans prendre trop de place inutilement car elles risqueraient d’être enlevées au profit d’autres objets. Il est évident que 4^ème Dimension ne réalise cette compression que lorsque le cache tend à être plein. Le temps de compression et décompression est négligeable par rapport au temps de chargement et de réécriture des pages sur le disque mais dans certains cas peut être source de ralentissement d’un 4D Server. Il convient donc d’étudier l’impact de cette option sur les performances de votre application. Par défaut, 4^èmeDimension active la compression qui peut être contrôlée par la commande FIXER PARAMETRE BASE utilisée avec le sélecteur Compression index.

Note : La commande Lire parametre base utilisée avec le sélecteur Taille cache données (numéro 9) nous permet de connaître précisément la taille courante exprimée en octets de la mémoire allouée au cache par 4D. La taille du cache ne peut pas être fixée par programmation. Autrement dit, il n'est pas possible d'utiliser le sélecteur Taille cache données avec la commande FIXER PARAMETRE BASE.

Contrôler la taille de mémoire utilisée

Plusieurs approches permettent de contrôler la taille de mémoire utilisée :

• Utiliser des liens manuels afin que la mise en ligne de l’enregistrement de votre plus gros client dont vous cherchez le numéro de téléphone ne provoque pas le chargement de la table d’adresses correspondant à ses 20 000 factures. Les liens manuels seront activés par programmation lorsque l’affichage des factures liées sera utile.

• Utiliser la commandeREDUIRE SELECTION et LIBERER ENREGISTREMENT qui permettent de libérer la mémoire à l’intérieur d’un process lorsque respectivement la sélection ou l’enregistrement n’est plus utilisé.

• Reporter les champs de taille variable dans des tables annexes gérées par des liens manuels, pour éviter de charger en mémoire des champs lourds de type blob, image ou texte lors de la sélection d’un enregistrement dans une liste.

• Utiliser la commande FIXER DESTINATION RECHERCHE qui vous permet d'indiquer à 4^ème Dimension où placer les résultats de toutes les recherches qui suivent l'appel de cette commande dans le process courant.

Vous pouvez spécifier l’un des types de destination suivants : Vers sélection courante, Vers ensemble, Vers sélection temporaire ou Vers variable. Par exemple pour vérifier l'unicité de la valeur d’un champ, la commande vous permet de dire à 4^ème Dimension de mettre le résultat de la recherche dans une variable (utilisation de la constante Vers variable), c'est à dire d'indiquer uniquement le nombre d'enregistrements trouvés sans modifier la sélection courante.

• Utiliser la commande FIXER LIMITE RECHERCHE qui vous permet d'indiquer à 4^ème Dimension d'arrêter toutes les recherches suivant l'appel de cette commande dans le process courant dès que le nombre d'enregistrements défini danslimitea été atteint. Si, par exemple, limite est égal à 1, les recherches s'arrêteront dès qu'un enregistrement sera trouvé selon les critères de la recherche.

• Penser à déclarer comme process locaux en préfixant leur nom par $ les process n’ayant pas besoin d’accéder aux données du serveur (palettes de commande pilotant les autres process, affichage d’horloge, thermomètres de progression). Ce type de process n’a pas de représentation sur le serveur.

• Etudier l’option de base de données réparties. Si certaines tables "lourdes", c’est-à-dire contenant un très grand nombre d’enregistrements et générant des tables d’adresses importantes, ne sont utilisées que de façon occasionnelle et/ou par un pourcentage réduit d’utilisateurs, on pourra envisager de les placer dans une seconde base de données qui sera accédée de façon transparente par les utilisateurs via une API 4D OPEN.

IV. Optimiser le 4D WEB Server

La qualité de service offerte par votre serveur Web peut dépendre de plusieurs facteurs :

• la qualité du réseau et de la bande passante ;

• la performance du matériel ;

• la performance des logiciels ;

• la qualité de conception des pages.

Dans cette partie de notre note technique nous vous proposons des conseils et des préconisations relatifs au deux derniers points. Les deux premiers ont étés abordés plus haut.

Le cache web

Le serveur Web de 4D maintient dans son propre cache les pages web statiques et les images. Ce cache permet d’éviter le chargement de ces documents à partir du disque dur pour chaque nouvelle requête et augmenter ainsi les performances du serveur Web en terme de temps de réponse. Cette propriété ne peut pas être modifiée ni par programmation ni par l’utilitaire 4D Customizer Plus. Pour activer la mise en cache, il faut définir une valeur ajustée en fonction du besoin de votre site dans le dialogue de propriétés de la base .

Le bouton "Vider cache" (Clear Cache) qui se trouve au même endroit sur le dialogue sert à vider le cache web de son contenu. Cette possibilité de vider le cache est de grande utilité surtout pendant la phase de développement lorsque l’on essaie d’afficher les changements apportés à nos pages HTML ou à nos images. Le cache doit être vidé à chaque fois que ces documents sont modifiés ou déplacés. Dans le cas contraire, une requête du navigateur affichera l’ancienne version, correspondant à celle qui a été mise en mémoire cache.

Il est également possible de vider le cache web à distance à partir d’un navigateur grâce à la balise spéciale

/4DCACHECLEAR. Cette balise est à utiliser de la manière suivante :

http://www.exemple.fr/4DCACHECLEAR

Lorsque le serveur web reçoit cette balise, il n’exécute aucune méthode base ou projet mais exécute du code en interne et renvoie une réponse comme le montre l’exemple suivant :

Il est important de noter que ce comportement sera différent lorsqu’un mot de passe est associé au Super- Utilisateur. Dans ce cas, une demande d’authentification est envoyée à l’utilisateur web puis la méthode base Sur Authentification Web est appelée.

Le serveur web propose également d’autres balises spéciales très utiles telles que 4DSTATS et4DHTMLSTATS. La balise 4DSTATS permet d’obtenir des informations sur l’activité du serveur Web sous forme d’un fichier texte. La balise4DHTMLSTATSretourne les mêmes informations que 4DSTATS mais en omettant celles sur les images. Vous pouvez également utiliser la commande STATISTIQUES DU CACHE WEB pour connaître les pages les plus souvent consultées.

Ci-dessous un exemple de réponse renvoyée suite à une requête utilisant la balise 4DSTATS :

Contrôler les process web

Le serveur HTTP de 4D Server ou 4^èmeDimension peut fonctionner selon deux modes : le mode contextuel et le mode hors contexte. Dans le premier mode, un navigateur se comporte exactement comme un 4D client. En revanche, le mode hors contexte ignore tout de l'utilisateur connecté et fonctionne de la façon suivante : 4D reçoit une requête, le process "Serveur Web" crée un process pour gérer la requête. Une fois cette requête exécutée, le process est endormi pour 5 secondes et ensuite il est tué. Cette requête peut être un 4DACTION, un 4DCGI ou autre. Un serveur Web 4D qui reçoit plusieurs centaines de requêtes par jour, voire plusieurs milliers pour les sites très fréquentés, ont intérêt à être paramétrés pour maintenir en vie des process créés par le "Serveur Web". Ceci est possible en utilisant la commande FIXER PARAMETRE BASE avec les sélecteurs Minimum process web et Maximum process web. Voici un exemple d’utilisation de cette commande :

FIXER PARAMETRE BASE(Minimum process Web;20) FIXER PARAMETRE BASE(Maximum process Web;60)

Cette syntaxe permet de fixer le nombre minimum de process web que 4D Server va conserver en vie. Les process créés lors d'une requête sont suspendus jusqu'à ce qu'une nouvelle requête arrive. On économise le temps de la création qui est systématique dans le fonctionnement par défaut. Mais on fixe aussi le nombre de process maximum que le serveur va conserver en vie. Au-delà de cette limite, les process supplémentaires seront tués après 5 secondes d'inactivité. D’ailleurs, il est important de noter que pour empêcher la saturation du serveur Web suite à des requêtes entrantes de trop grande taille, une nouvelle fonctionnalité de sécurité a été introduite depuis la version 2003 et qui consiste à refuser les requêtes dépassant une limite donnée. Cette limite ne peut être fixée que par programmation à l’aide de la commande FIXER PARAMETRE BASE et le nouveau sélecteur Taille maximum requêtes Web (27). Le deuxième paramètre correspond à la Taille maximale en octets (500 000 à 2 147 483 648) des requêtes HTTP entrantes (POST) que le serveur Web est autorisé à traiter. Par défaut, la valeur est de 2 M o et la valeur maximale (2 147 483 648) signifie qu’en pratique aucune limite n'est fixée.

Revenons à notre sujet de recyclage des process web …

Puisque les process Web sont réutilisés, les valeurs des variables process sont conservées. Il ne suffit donc pas de déclarer les variables process, il faut aussi les initialiser à leur valeur par défaut lors du recyclage du process.

Un tel problème peut se poser, par exemple, lors de l'utilisation de variables invisibles dans les formulaires Web. De telles variables permettent de connaître le contexte de la connexion, donc d'identifier un utilisateur parmi plusieurs connectés. Il est donc conseillé d'utiliser toujours un 4DCGI ou une URL virtuelle à la place de

4DACTION. Ainsi la méthode base Sur connexion Web sera exécutée à chaque requête. Y seront alors écrites toutes les initialisations des variables requises.

De la même manière que les process 4D, les process Web ont eux aussi une mémoire réservée appelée pile.

Dans certain cas et en fonction du traitement effectué par le process web, la taille de cette pile peut s’avérer insuffisante. Cette ressource est accessible grâce au 4D Customizer Plus. Elle existe dans le moteur de 4D Server et 4D Monoposte. Attention, il ne faut pas confondre cette ressource avec celle de la pile d’un process 4D qui est stockée dans la structure de la base de données. En fait, cette dernière n’a aucun effet sur les process web. Voici une copie d’écran de la fenêtre de paramétrage de la taille de la pile des process web (4ème ligne) :

Etant donné que cette ressource est stockée dans la ressource 4STK (ID 8) de 4^ème Dimension lui-même, le développeur est contraint de la transférer dans chaque nouvelle version. La solution consiste à copier cette ressource 4STK dans la structure de la base de données. La seule limitation de cette dernière solution est qu'elle est propre à une base. Lors de la création d'une nouvelle base, il faudra copier cette ressource. Il est important de rappeler que cette technique de "patch" n’est pas documentée donc elle n’est pas garantie par 4D SA qui peut très bien modifier un aspect non documenté de son produit sans préavis.

Mieux gérer les images de votre site Web

La première idée d’optimisation à laquelle on pense est probablement la réduction des tailles des images.

Certains développeurs font l’erreur de modifier les attributsHeightet Width de l’image pour changer la taille de l’image. Or ces attributs ne sont que des informations de présentation dont le navigateur a besoin pour afficher l’image et n’ont aucun effet sur sa taille. Par exemple, une image qui pèse 100 ko dans un rectangle de dimensions Height=50 et Width=100 aura exactement la même taille dans un rectangle ayant les dimensions Height =25 et Width=50.

En revanche, on peut réduire la taille des images en utilisant des logiciels spécialisés comme "PhotoShop" ou bien directement avec 4^ème Dimension en faisant appel à la commande CREER IMAGETTE. Cette commande est de grande utilité car elle permet de prévisualiser les images et d’automatiser leurs traitements avant de les envoyer au navigateur. En diminuant les troisième et quatrième paramètres, on réduit la taille de l’image mais cette réduction n’est pas proportionnelle aux valeurs passées. Le sixième paramètre optionnel permettant de définir le nombre de couleurs c'est-à-dire la profondeur d'écran fait diminuer lui aussi la taille de l’image. Il est utile de rappeler que cette commande ne nécessite pas l’installation de QuickTime.

Par ailleurs, lorsque vous avez des grosses images à afficher sur le Web, vous pouvez vous demander s'il est plus raisonnable de les envoyer en une seule fois ou de les découper en plusieurs petites images. Afin de répondre à cette interrogation, il faut avant tout bien savoir comment cela fonctionne : le navigateur envoie une requête afin de récupérer le fichier HTML de la page web, il "parse" (analyse) ensuite son contenu et recherche les références aux images qu'il reconnaît par la balise <IMG SRC= >. Dès que le navigateur rencontre une référence à une image, il envoie alors une seconde requête au serveur web afin de la récupérer. Chaque requête contient un certain nombre d'informations (comme les en-têtes des requêtes et réponses) accompagnées d'un traitement de la part du serveur et du navigateur qui vont transiter sur le réseau. Tout ceci nécessite donc un trafic important sur le réseau pour chaque image envoyée et le fait de découper votre image en plusieurs images

ne fait donc que multiplier les requêtes et réponses HTTP. Ce qui fait que bien souvent la taille réelle de l'image envoyée est bien inférieure à celle qui transite sur le réseau. Nous vous conseillons donc d'envoyer vos images en une seule fois afin de ne pas multiplier les requêtes et réponses HTML accompagnées de l'en-tête pour chaque image envoyée.

V. Conclusion

Dans cette note technique nous vous avons présenté des conseils et des préconisations permettant l’optimisation de 4D Server et du Server Web afin de leur préserver des bonnes performances en leur conservant une volumétrie et une charge en mémoire confortable. Des configurations de mise en place sont également proposées.