Configuration de mise en commun de connexion avancée de base de données¶

Examen des instructions préparées¶

Instructions préparées servent de bases de données afin d’éviter la re-planification de l’accès aux données chaque fois, le plan est fait qu’une seule fois dès le départ, et tant que l’instruction est mise en cache, le plan n’a pas besoin d’être re-calculé.

Dans les applications d’affaires extraire une petite quantité de données à la fois ce qui est bénéfique pour la performance, toutefois, dans ceux de nature spatiale, où nous récupérons typiquement des milliers de lignes, l’avantage est limité, et parfois, se transforme en un problème de performance. Ceci est le cas avec PostGIS, qui est en mesure de régler le plan d’accès en inspectant le BBOX demandé, et de décider si une analyse séquentielle est préférable (le BBOX accède vraiment la plupart des données) ou en utilisant l’index spatial est meilleure place. Donc, en règle générale, lorsque vous travaillez avec PostGis, il est préférable de ne pas activer les requêtes préparées.

Autres bases de données, il n’y a pas de choix, Oracle actuellement fonctionne uniquement avec les commandes préparées, SQL server uniquement sans eux (cela est souvent lié aux limitations de la mise en œuvre que des questions spécifiques de base de données).

Il ya une hausse d’utiliser l’instruction préparée cependant : aucune attaque d’injection sql n’est possibles lors de leur utilisation. Code de GeoServer s’efforce d’éviter ce genre d’attaque lorsque vous travaillez sans instructions préparées, mais leur permettant fondamentalement empêche l’attaque via les paramètres de filtre.

Conclusions¶

En résumé, lors de la création d’entrepôts de données standard pour servir les données vectorielles de SGBD dans GeoServer vous devez vous rappeler qu’en interne un pool de connexion sera créé. Cette approche est la plus simple à mettre en œuvre, mais peut conduire à une répartition inefficace des connexions entre différents magasins dans les cas suivants :

• Si nous avons tendance à séparer les tables dans des schémas différents, cela conduira à la nécessité pour la création de plusieurs banques pour les servir puisque GeoServer fonctionne encore mieux si le paramètre « schéma » est spécifié, cette attaque à la création de pools de connexions (pour la plupart inutiles)

• Si nous voulons créer des magasins dans les différents espaces de travail à la base de données même ceci mènera à nouveau à une duplication inutile des pools de connexions en magasin différent, conduisant à une utilisation inefficace des connexions

Longue histoire courte du fait que la piscine est interne à l’égard des magasins peut conduire à une utilisation inefficace des connexions aux SGBD sous-jacent, car ils seront scindés entre plusieurs magasins limitant l’extensibilité de chacun d’eux: en effet avoir 100 connexions partagée entre N DataStore normal imposer des limites au nombre maximal que chacun peut utiliser, sinon, si nous avons réussi à maintenir les connexions en une seule piscine partagée, à son tour, avec les différents DataStore nous parvenir à un partage plus efficace entre le magasin que, comme un Ainsi, un seul magasin sous haute charge pourrait évoluer pour utiliser toutes les connexions disponibles.

Installation de Tomcat¶

La première étape à effectuer pour la création d’une DataSource JNDI (pool de connexion) est d’éditer le fichier context.xml à l’intérieur du répertoire ‘’ $TOMCAT_HOME/conf ‘’. Ce fichier contient les différentes ressources JNDI configurés pour Tomcat. Dans ce cas, nous allons configurer une DataSource JNDI pour une base de données PostgreSQL. Si le fichier n’est pas présent, vous devez créer et ajouter un contenu semblable à la suivante:

<Context>
        <Resource
         name="jdbc/postgres" auth="Container" type="javax.sql.DataSource"
         driverClassName="org.postgresql.Driver"
         url="jdbc:postgresql://localhost:5432/testdb"
         username="admin"
         password="admin"
         maxActive="20"
         maxIdle="10"
         maxWait="10000"
         minEvictableIdleTimeMillis="300000"
         timeBetweenEvictionRunsMillis="300000"
         validationQuery="SELECT 1"/>
</Context>

Dans l’extrait de code XML précédent, nous avons configuré une connexion à une base de données de PostrgreSQL appelé ** testdb ** qui ont le nom d’hôte comme * localhost * et numéro de port égales à * 5432 *.

Certains des paramètres qui peuvent être configurés pour le pool de connexion JNDI sont comme suit :

• ** maxActive **: le nombre de connexions actives maximales à utiliser.

• ** maxIdle **: le nombre de nombre maximal de connexions inutilisé.

• ** maxWait **: le nombre maximal de ** millisecondes ** qui attendra la piscine.

• ** poolPreparedStatements **: activez l’instruction préparée, mise en commun (très important pour un meilleur rendement).

• ** maxOpenPreparedStatements **: le nombre maximal de requêtes préparées dans la piscine.

• ** validationQuery **: (valeur par défaut null) A validation requête que double vérifie la connexion est encore en vie avant de l’utiliser réellement.

• ** timeBetweenEvictionRunsMillis **: (par défaut -1) le nombre de ** millisecondes ** dormir entre les exécutions du thread inactif objet expulse. Lorsque non positive, aucun thread n’expulse objet inactif ne sera exécutée.

• ** numTestsPerEvictionRun **: (par défaut 3) le nombre d’objets à examiner au cours de chaque exécution du thread inactif objet expulse (le cas échéant).

• ** minEvictableIdleTimeMillis **:: (par défaut de 1000 * 60 * 30) le minimum de temps, in ** millisecondes **, un objet peut siéger ralenti dans la piscine avant qu’il soit admissible à l’éviction de l’expulse de l’objet inactif (le cas échéant).

• ** removeAbandoned **: (false par défaut) drapeau pour supprimer les connexions abandonnées si elles dépassent le removeAbandonedTimout. Si la valeur true, une connexion est considérée comme abandonnée et admissibles pour le retrait s’il a été ralenti plus longtemps que le removeAbandonedTimeout. Ceci affectant la valeur true peut récupérer db connexions provenant d’applications mal écrites qui ne parviennent pas à fermer une connexion.

• ** removeAbandonedTimeout **: (par défaut 300) Timeout en ** secondes ** avant une connexion abandonnée peut être retirée.

• ** logAbandoned **: (false par défaut) drapeau pour enregistrer les traces de la pile pour le code d’application qui abandonne une instruction ou une connexion.

• ** testWhileIdle **: (false par défaut) drapeau utilisé pour tester les connexions en cas d’inactivité.

Plus d’informations sur les paramètres se trouvent à la » documentation DBCP <http: commons.apache.org/proper/commons-dbcp/configuration.html=”“>’ _.</http:>

Installation de GeoServer¶

Lancer GeoServer et accédez à la : menuselection : section « Magasins–> Add new Store ».

Tout d’abord, choisissez le * PostGIS (JNDI) * datastore et donnez-lui un nom :

Configuration du magasin de JNDI de PostGIS

Et puis, vous pouvez configurer le pool de connexions :

Configuration du magasin de JNDI de PostGIS

Lorsque vous faites cela, assurez-vous que le schéma est configuré correctement, ou le magasin de données répertorie toutes les tables, à Qu’on peut trouver dans le schéma, qu’il est donné accès.

Installation de Tomcat¶

Dans ce cas, nous allons configurer une DataSource JNDI pour une base de données SQL Server. Vous doit créer/modifier le fichier context.xml à l’intérieur de $TOMCAT_HOME/conf répertoire contenant les lignes suivantes:

<Context>
         <Resource
                name="jdbc/sqlserver"
                auth="Container"
                type="javax.sql.DataSource"
                url="jdbc:sqlserver://localhost:1433;databaseName=test;user=admin;password=admin;"
                driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"
                username="admin"
                password="admin"
                maxActive="20"
                maxIdle="10"
                maxWait="10000"
                minEvictableIdleTimeMillis="300000"
                timeBetweenEvictionRunsMillis="300000"
                validationQuery="SELECT 1"/>
</Context>

Installation de GeoServer¶

Lancer GeoServer et accédez à la : menuselection : section « Magasins–> Add new Store ».

Puis choisissez le * Microsoft SQL Server (JNDI) * datastore et donnez-lui un nom :

Configuration de Microsoft SQLServer JNDI magasin

Après, vous pouvez configurer le pool de connexions :

Configuration de Microsoft SQLServer JNDI magasin

Installation de Tomcat¶

Tout d’abord vous devez créer/modifier le fichier context.xml à l’intérieur de ‘’ $TOMCAT_HOME/conf ‘’ répertoire contenant les lignes suivantes:

<Context>
           <Resource
                        name="jdbc/oralocal"
                        auth="Container" type="javax.sql.DataSource"
                        url="jdbc:oracle:thin:@localhost:1521:xe"
                        driverClassName="oracle.jdbc.driver.OracleDriver"
                        username="dbuser"
                        password="dbpasswd"
                        maxActive="20"
                        maxIdle="3"
                        maxWait="10000"
                        minEvictableIdleTimeMillis="300000"
                        timeBetweenEvictionRunsMillis="300000"
                        poolPreparedStatements="true"
                        maxOpenPreparedStatements="100"
                        validationQuery="SELECT SYSDATE FROM DUAL" />
</Context>

Installation de GeoServer¶

Lancer GeoServer et accédez à la : menuselection : section « Magasins–> Add new Store ».

Puis choisissez le * Oracle NG (JNDI) * datastore et donnez-lui un nom :

Configuration d’Oracle JNDI magasin

Après, vous pouvez configurer le pool de connexions :

Configuration d’Oracle JNDI magasin

Temps d’attente de connexion et de la relation avec les autres params¶

En général, il est important de définir le temps de connexion en attente d’une manière que le pool de connexion ne devienne pas un endroit où faire la queue discussions à exécuter les demandes en vertu de grosse charge. Il est en effet possible que sous de grands filets de charge à exécuter les demandes pour une couche vectorielle seront plus nombreux que les connexions disponibles dans la piscine où ces discussions seront bloqués essayer d’acquérir une nouvelle connexion; si le nombre de connexions est beaucoup plus petit que le nombre de demandes reçues et le temps maximum d’attente est assez grand (par exemple 60 secondes), nous allons nous retrouver dans la condition d’avoir de nombreux threads en attente depuis longtemps d’acquérir une connexion après que la plupart des les ressources dont ils ont besoin seront attribuées, en particulier la mémoire tampon d’arrière si ceux-ci sont WMS demandes.

Le max wait time en général doit être réglé en conséquence le délai d’exécution maximal prévu pour un demandes, de bout-en-bout. Cela inclut des choses comme, l’accès au système de fichiers, le chargement des données. Comme exemple, si nous prenons en compte les WMS demandes que nous sommes autorisés à spécifier un temps de réponse maximal, donc si définir ce à N secondes, le temps d’attente maximum devrait être fixé à une valeur inférieure à celle puisque nous ne voulons pas gaspiller des ressources ayant threads bloqués inutilement en attente d’une connexion. Dans ce cas, il est préférable de ne pas rapide pour libérer des ressources qui pourraient être utilisées autrement inutilement.

Maximiser la mise en commun des Pools de connexions¶

Comment les données sont organisées entre la base de données, des schémas et des tableau incidence du degré de flexibilité, que nous avons en essayant de mieux partager des connexions, indépendamment du fait que nous utilisions JNDI avec Betclic ou non. En Résumé :

• Fractionnement des tables dans les schémas nombreux rend difficile pour GeoServer à table access appartenant à différents schémas, à moins que nous basculons vers JNDI, étant donné que le schéma doit être spécifié dans le cadre de la params de connexion lors de l’utilisation des piscines intérieures

• En utilisant différents utilisateurs pour les différents schémas empêchent JNDI de travailler efficacement dans l’ensemble de schémas. Il est préférable d’utiliser lorsque possible un seul dédié compte à travers des schémas

• Ayant en général une combinaison complexe d’utilisateurs et de schéma peut conduire à répartition inefficace des connexions disponibles dans plusieurs pools

Longue histoire courte, chaque fois qu’il est possible s’efforcent de faire usage d’un petit nombre d’utilisateurs et si ne pas utiliser JNDI à un petit nombre de schéma, bien que JNDI est un must pour Organisation désireux de créer un complexe mis en place où les différents espaces de travail (c.-à-d. Services virtuels) servent le même contenu différemment.

Validation de la requête¶

Peu importe comment nous configurer la requête de validation, il est extrêmement important que nous nous souvenions toujours valider les connexions avant de les utiliser dans GeoServer ; ne pas le faire pourrait conduire à des erreurs en raison de connexions rassises assis la piscine. Ceci peut être réalisé avec le pool de connexion interne (via la boîte de connexions validate) ainsi qu’avec les piscines déclarées dans JNDI (via le mécanisme de requête de validation) ; Il est intéressant de rappeler que ce dernier passera à configurabilité de grain plus fine.

Notes