Veillez à ce que votre serveur de sauvegarde fonctionne de manière optimale

Avec 4D 21 R4, vous bénéficiez d’un contrôle encore accru sur les ressources de votre serveur REST grâce à un nouveau mécanisme de gestion des quotas.À mesure que vos applications se développent, vos données peuvent être utilisées par une grande variété de clients : applications web, applications mobiles, services tiers, intégrations personnalisées et désormais même des outils basés sur l’IA via les serveurs MCP.

Chaque client interagit avec vos API REST à sa manière, générant des requêtes dont la complexité et la fréquence varient.Pour garantir des performances optimales en toutes circonstances, il est important de contrôler l’utilisation des ressources du serveur.

HDI_REST_Server_quotas

Pourquoi des quotas ?

Sur le serveur REST 4D, les données demandées peuvent être stockées en mémoire sous forme d’ensembles d’entités afin d’améliorer l’efficacité et la navigation.

Dans les applications bien conçues, ces ensembles d’entités sont libérés lorsqu’ils ne sont plus nécessaires. Cependant, dans des écosystèmes vastes et diversifiés, il n’est pas toujours possible de prédire le comportement des clients ni de savoir si toutes les ressources allouées seront correctement libérées.

Sans quotas, une gestion inefficace des ensembles d’entités au cours d’une même session peut affecter les performances perçues par les autres utilisateurs.

C’est pourquoi 4D 21 R4 introduit des quotas de session pour les ensembles d’entités. En quelques lignes de code seulement, vous pouvez définir des limites de ressources qui permettent de maîtriser l’utilisation de la mémoire, de protéger votre serveur contre une consommation excessive et de garantir une disponibilité constante pour tous les utilisateurs.

Il en résulte un serveur REST plus résilient, une administration simplifiée et une plus grande confiance lorsque vous exposez vos données à un nombre toujours croissant d’utilisateurs.

Configurer les quotas pour la session REST en cours

La commande Session renvoie un objet représentant la session REST. Cet objet comprend une quotas propriété d’objet (une instance de la classe ` 4D.QuotaManager `). 

Exemple

Voici l’ Session.quotas . 

{
        "nbEntitySets": 100,
        "maxEntitySetTimeout": 420,
        "defaultEntitySetTimeout": 300,
        "currentValues": {}
}

Il expose les propriétés suivantes, qui peuvent être utilisées pour configurer les quotas de la session en cours:

– nbEntitySets: nombre maximal d’ensembles d’entités autorisés en mémoire

–> Un nombre trop élevé d’ensembles d’entités peut entraîner une consommation excessive de mémoire et nuire aux performances du serveur REST. Cette propriété vous permet de limiter le nombre d’ensembles d’entités pouvant être stockés simultanément en mémoire pour la session en cours.

– defaultEntitySetTimeout: le délai d’inactivité par défaut autorisé pour les ensembles d’entités.

–> Le réglage de cette propriété permet d’éviter une utilisation excessive de la mémoire, car les ensembles d’entités sont automatiquement libérés lorsqu’ils restent inutilisés pendant une durée supérieure à celle spécifiée.

– maxEntitySetTimeout: le délai d’inactivité maximal pour les ensembles d’entités

–>Le réglage de cette propriété empêche la création d’ensembles d’entités dont le délai d’inactivité est excessivement long.

De plus, la currentValues propriété fournit également un nbEntitySetsattribut indiquant le nombre d’ensembles d’entités actuellement conservés en mémoire pour la session.

Remarque : une valeur « Undefined » signifie qu’aucun quota n’est appliqué et que le serveur REST utilise son comportement par défaut.

Limiter le nombre d’ensembles d’entités

Pour ce faire, modifiez la nbEntitySets propriété.

Session.quotas.nbEntitySets:=100

Dans l’exemple ci-dessous, la session est limitée à un maximum de 100 ensembles d’entités en mémoire, et 100 ensembles d’entités ont déjà été créés :

{
  "nbEntitySets": 100,
  "currentValues": {
    "nbEntitySets": 100
  }
}

Lors de la prochaine tentative de création d’un ensemble d’entités, une erreur est renvoyée tant que 100 ensembles d’entités restent en mémoire :

{
    "__ERROR": [
        {
            "message": "Max number of entitysets has been reached for this session.",
            "componentSignature": "dbmg",
            "errCode": 2017
        }
    ]
}

un exemple plus concret

Le mode forceLogin offre une première couche de protection en empêchant la création d’ensembles d’entités dans les sessions non authentifiées. Cependant, même après l’authentification, vous pouvez souhaiter restreindre davantage le nombre d’ensembles d’entités pouvant être créés par des rôles d’utilisateurs spécifiques.

Dans l’exemple ci-dessous, le mode forceLogin est activé.

Un utilisateur disposant du rôle «Guest » est limité à un maximum de 100 ensembles d’entités.

exposed Function authentify($credentials : Object) : Boolean
	
	var $result:=False
	
	Session.clearPrivileges()
	
	If ($credentials.identifier="Guest")
		Session.setPrivileges("")
		Session.quotas.nbEntitySets:=100
		$result:=True
	Else 
		// Authenticate other users
		// ... 
                Session.quotas.nbEntitySets:=200
                $result:=True
	End if 
	
	return $result

Bien entendu, si vous n’utilisez pas le mode « forceLogin », des quotas peuvent également être appliqués de la même manière à l’aide de la commande « Session ».

Configurer le délai d’inactivité par défaut pour les ensembles d’entités

Par défaut, le délai d’inactivité des ensembles d’entités est de deux heures. Vous pouvez le modifier en mettant à jour la defaultEntitySetTimeout propriété (en secondes).

Session.quotas.defaultEntitySetTimeout:=300  // 5 minutes

Les ensembles d’entités créés par une requête telle que :

/rest/People?$filter='ID>=1'&$method=entityset

seront automatiquement libérés au bout de cinq minutes s’ils ne sont pas utilisés pendant cette période (c’est-à-dire lorsqu’aucun délai d’inactivité n’est explicitement spécifié dans la requête).

Configurer le délai d’inactivité maximal pour les ensembles d’entités

Vous pouvez définir le délai d’inactivité maximal autorisé pour les ensembles d’entités en mettant à jour la maxEntitySetTimeout propriété (en secondes).

Session.quotas.maxEntitySetTimeout:=420  // 7 minutes

Si un ensemble d’entités est créé avec un délai d’inactivité dépassant cette limite, il sera automatiquement plafonné à 420 secondes.

Par exemple, pour la requête suivante :

/rest/People?$filter=ID>=4&$method=entityset&$timeout=600

l’ensemble d’entités sera libéré au bout de 420 secondes, car le délai de 600 secondes demandé est ignoré.

Essayez le fichier HDI ci-joint et améliorez dès maintenant la robustesse de vos applications !