Con 4D 21 R4, avrai un controllo ancora maggiore sulle risorse del tuo server REST grazie a un nuovo meccanismo di gestione delle quote.Man mano che le tue applicazioni crescono, i tuoi dati possono essere utilizzati da un’ampia varietà di client: applicazioni web, app mobili, servizi di terze parti, integrazioni personalizzate e ora anche strumenti basati sull’intelligenza artificiale tramite i server MCP.
Ogni client interagisce con le API REST a modo suo, generando richieste con diversi livelli di complessità e frequenza.Per garantire prestazioni ottimali in ogni situazione, è importante mantenere il controllo sull’utilizzo delle risorse del server.
Quote: perché?
Sul server REST 4D, i dati richiesti possono essere memorizzati in memoria come insiemi di entità per migliorare l’efficienza e la navigazione.
Nelle applicazioni ben progettate, questi insiemi di entità vengono liberati quando non sono più necessari. Tuttavia, in ecosistemi di grandi dimensioni e diversificati, non è sempre possibile prevedere come si comporteranno i client o se ogni risorsa allocata verrà correttamente liberata.
Senza quote, una gestione inefficiente degli insiemi di entità in una singola sessione può influire sulle prestazioni percepite dagli altri utenti.
Ecco perché 4D 21 R4 introduce le quote di sessione per gli insiemi di entità. Con poche righe di codice, è possibile definire limiti di risorse che aiutano a tenere sotto controllo l’utilizzo della memoria, proteggere il server da un consumo eccessivo e garantire una disponibilità costante per tutti gli utenti.
Il risultato è un server REST più resiliente, una gestione più semplice e una maggiore sicurezza nell’esporre i propri dati a un numero sempre crescente di utenti.
Configurare le quote per la sessione REST corrente
Il comando Session restituisce un oggetto che rappresenta la sessione REST. Questo oggetto include una quotas proprietà object (un’istanza della classe 4D.QuotaManager ).
Esempio
Ecco l’ Session.quotas .
{
"nbEntitySets": 100,
"maxEntitySetTimeout": 420,
"defaultEntitySetTimeout": 300,
"currentValues": {}
}
Esso espone le seguenti proprietà, che possono essere utilizzate per configurare le quote per la sessione corrente:
– nbEntitySets: il numero massimo consentito di insiemi di entità in memoria
–> Un numero eccessivo di insiemi di entità può consumare troppa memoria e influire sulle prestazioni del server REST. Questa proprietà consente di limitare il numero di insiemi di entità che possono essere memorizzati contemporaneamente in memoria per la sessione corrente.
– defaultEntitySetTimeout: il timeout di inattività predefinito consentito per i set di entità.
–> La regolazione di questa proprietà aiuta a prevenire un uso eccessivo di memoria, poiché gli insiemi di entità vengono automaticamente liberati quando rimangono inutilizzati per un periodo superiore a quello specificato.
– maxEntitySetTimeout: il timeout massimo di inattività per gli insiemi di entità
–>la regolazione di questa proprietà impedisce la creazione di insiemi di entità con tempi di inattività eccessivamente lunghi.
Inoltre, la currentValues proprietà fornisce anche un nbEntitySetsattributo che indica il numero di insiemi di entità attualmente conservati in memoria per la sessione.
Nota: un valore non definito indica che non viene applicata alcuna quota e che il server REST utilizza il proprio comportamento predefinito.
Limitare il numero di insiemi di entità
Per farlo, aggiornare la nbEntitySets proprietà.
Session.quotas.nbEntitySets:=100
Nell’esempio riportato di seguito, la sessione è limitata a un massimo di 100 insiemi di entità in memoria e sono già stati creati 100 insiemi di entità:
{
"nbEntitySets": 100,
"currentValues": {
"nbEntitySets": 100
}
}
Al successivo tentativo di creare un insieme di entità, verrà restituito un errore fintanto che in memoria rimarranno 100 insiemi di entità:
{
"__ERROR": [
{
"message": "Max number of entitysets has been reached for this session.",
"componentSignature": "dbmg",
"errCode": 2017
}
]
}
un esempio più concreto
La modalità forceLogin fornisce un primo livello di protezione impedendo la creazione di insiemi di entità in sessioni non autenticate. Tuttavia, anche dopo l’autenticazione, potrebbe essere opportuno limitare ulteriormente il numero di insiemi di entità che possono essere creati da specifici ruoli utente.
Nell’esempio riportato di seguito, la modalità forceLogin è abilitata.
Un utente con il ruoloGuest è limitato a un massimo di 100 insiemi di entità.
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
Naturalmente, se non si utilizza la modalità `forceLogin`, è possibile applicare le quote allo stesso modo utilizzando il comando ` Session `.
Configurare il timeout di inattività predefinito per gli insiemi di entità
Per impostazione predefinita, il timeout di inattività per gli insiemi di entità è di due ore. È possibile modificarlo aggiornando la defaultEntitySetTimeout proprietà (in secondi).
Session.quotas.defaultEntitySetTimeout:=300 // 5 minutes
Gli insiemi di entità creati da una richiesta del tipo:
/rest/People?$filter='ID>=1'&$method=entityset
verranno automaticamente rilasciati dopo cinque minuti se non vengono utilizzati durante tale periodo (ovvero quando nella richiesta non è specificato esplicitamente alcun timeout di inattività).
Configurare il timeout massimo di inattività per gli insiemi di entità
È possibile definire il timeout massimo di inattività consentito per gli insiemi di entità aggiornando la maxEntitySetTimeout proprietà (in secondi).
Session.quotas.maxEntitySetTimeout:=420 // 7 minutes
Se un insieme di entità viene creato con un timeout di inattività che supera questo limite, verrà automaticamente limitato a 420 secondi.
Ad esempio, per la seguente richiesta:
/rest/People?$filter=ID>=4&$method=entityset&$timeout=600
il set di entità verrà rilasciato dopo 420 secondi, poiché il timeout richiesto di 600 secondi viene ignorato.
Prova l’HDI allegato e migliora subito la robustezza delle tue applicazioni!
Al momento non è possibile lasciare commenti su questo post.