Bonjour,
Dans ce sujet on va essayer de voir ensemble les différents paramètres du connection pool et essayer d'expliquer l'utilité de chacun .
Bloque d'initialisation / Variables de Session
Un point à vérifier, est si les bloques d'initialisation utilisent le même connection pool que celui des requêtes .Si c'est le cas , il est recommandé de créer un connection pool propre aux bloques d'initialisation( spécialement les authentifications) . dans le cas contraire vous pouvez faire face a des situations ou les utilisateurs auront du mal a se loguer vu que les bloques d'initialisation partagent le même connection pool avec les requêtes .
Calcul du paramètre maximum connexion
la règle de calcul du nombre d'utilisateurs sur les dashboard est important aussi que le nombre de connection supportés par la base de données .Ce dernier est spécifique a chaque système de base de données .
La valeur par défaut qui vaut 10 est trop lente(peut causer des files d'attente) , dans l'autre sens mettre une valeur trop grande consommera en mémoire et peut même empêcher le démarrage du serveur BI.
La règle d'or consiste à :
*a tout moment , 10% a 20% des utilisateurs seront connectés
*sur ces utilisateur connectés , 10% à 20% seulement exécuteront des rapports .
*Il existe un maximum W de rapports pour chaque dashboard
Donc si vous avez 1000 utilisateur en total et au max 4 rapports par dashboard :
maximum connections =1000*0.2*0.2*4=160
pour info chaque connexion consomme 1024kb de mémoire serveur
Call interface
le call interface représente le driver utilisée pour la connexion avec la base de données , il existe trois méthodes :
*ODBC
*OCI
*XML
Execute Queries Asynchronously
Ce paramètre définie la façon de communiquer avec la base de données .si cette option est mise sur "run asynchronously" elle peut être annulée sur analytics a tout moment , dans le cas contraire l'annulation est impossible .
Isolation level
* Commited Read
Permet une lecture et écriture sécurisée en évitant l'accès aux data .
* Dirty Read
Aucune restriction sur les données . elle permet la lecture des données non commutées (la moins restrictive sur les quartes types)
* Repeatable Read
sécurise l'accès aux données utilisés dans une requête en interdisant la mise a jour des données .Cependant les nouvelles lignes insérées par les autres utilisateurs peuvent être lu dans une autre session.
* Sérialisation
sécurise l'accès aux données aux autres utilisateurs jusqu'à la fin de la transaction
Dans ce sujet on va essayer de voir ensemble les différents paramètres du connection pool et essayer d'expliquer l'utilité de chacun .
Bloque d'initialisation / Variables de Session
Un point à vérifier, est si les bloques d'initialisation utilisent le même connection pool que celui des requêtes .Si c'est le cas , il est recommandé de créer un connection pool propre aux bloques d'initialisation( spécialement les authentifications) . dans le cas contraire vous pouvez faire face a des situations ou les utilisateurs auront du mal a se loguer vu que les bloques d'initialisation partagent le même connection pool avec les requêtes .
Calcul du paramètre maximum connexion
la règle de calcul du nombre d'utilisateurs sur les dashboard est important aussi que le nombre de connection supportés par la base de données .Ce dernier est spécifique a chaque système de base de données .
La valeur par défaut qui vaut 10 est trop lente(peut causer des files d'attente) , dans l'autre sens mettre une valeur trop grande consommera en mémoire et peut même empêcher le démarrage du serveur BI.
La règle d'or consiste à :
*a tout moment , 10% a 20% des utilisateurs seront connectés
*sur ces utilisateur connectés , 10% à 20% seulement exécuteront des rapports .
*Il existe un maximum W de rapports pour chaque dashboard
Donc si vous avez 1000 utilisateur en total et au max 4 rapports par dashboard :
maximum connections =1000*0.2*0.2*4=160
pour info chaque connexion consomme 1024kb de mémoire serveur
Call interface
le call interface représente le driver utilisée pour la connexion avec la base de données , il existe trois méthodes :
*ODBC
*OCI
*XML
Execute Queries Asynchronously
Ce paramètre définie la façon de communiquer avec la base de données .si cette option est mise sur "run asynchronously" elle peut être annulée sur analytics a tout moment , dans le cas contraire l'annulation est impossible .
Isolation level
* Commited Read
Permet une lecture et écriture sécurisée en évitant l'accès aux data .
* Dirty Read
Aucune restriction sur les données . elle permet la lecture des données non commutées (la moins restrictive sur les quartes types)
* Repeatable Read
sécurise l'accès aux données utilisés dans une requête en interdisant la mise a jour des données .Cependant les nouvelles lignes insérées par les autres utilisateurs peuvent être lu dans une autre session.
* Sérialisation
sécurise l'accès aux données aux autres utilisateurs jusqu'à la fin de la transaction
Aucun commentaire:
Enregistrer un commentaire