dimanche 28 mars 2010
09:58 | 
Publié par
Jean FRANCOIS |
Le pool JDBC ou DataSource permet de déclarer des ressources d’accès à la base prête à l’emploi, sans attendre la phase de connexion et de déconnexion réseau (objectif de performance).
Il a également la responsabilité d’assurer le service d’accès en cas de panne ou dysfonctionnement (détection de panne et reprise de service automatique) et de rendre transparent la mis en place d’une architecture cluster.
C’est donc un connecteur vital pour l’application à paramétrer correctement sous peine de défaillance grave pour la plate-forme.
Prendre le driver JDBC fourni dans la distribution de l’éditeur de base de données afin de s’assurer de la bonne version (sauf préconisation contraire du support Oracle [souvent une version de driver supérieur] ).
Placer les JAR driver dans le CLASSPATH du scripte de démarrage des instances (avant les JAR Weblogic) afin de surcharge les drivers présents dans la distribution Oracle.
(Driver type 4)
ARCHITECTURE
Plusieurs architectures sont possibles pour accéder à la base, le plus simple étant un accès direct à une instance unique. On peut avoir des pools dédiés fonction de l’utilisation, ou des pools multiples dans le cas de redondance ou de cluster DataBase. L’accès pouvant être réalisé en direct ou réparti.
Connexion
ü UNIQUE Une datasource, une instance de base.
ü TYPE Une datasource par type de requêtage (lecture/écriture/transaction).
ü MULTIPOOL Plusieurs datasource en répartition.
Accès
ü DIRECTE Accès direct à l’instance.
ü LOAD BALANCING Une répartition de la charge sur plusieurs instances.
ü FAILE OVER Une bascule en cas de problème, avec un retour éventuel en cas de reprise.
· UNIQUE
L’accès le plus simple est une datasource pour une database. Toutes les requêtes passent par un même pool.
· TYPE
Les pools typés peuvent être utilisés selon des critères de requêtage. Il faudra prévoir dans le code applicatif la datasource associée au type de requête que l’on veut exécuter.
Cela permet de dissocier les flux et le type de fréquentation sur les pools (la lecture étant sauvant plus rapide que l’écriture ou le besoin transactionnel, donc des tailles différentes)
· MULTIPOOL
Le multipool permet de déclarer plusieurs datasource sur des databases différentes ou clusterisées avec un accès centralisé. Cela permet de mieux répartir la charge ou d’assurer une tolérance aux pannes.
Ce mécanisme peut également être assuré par le driver, ou le mécanisme de répartition est décalé côté database.
· DIRECTE
L’accès pouvant être direct, mais sans tolérance aux pannes. La reprise étant assurée automatiquement.
· LOAD BALANCING
Dans le cas d’un load balancing, la répartition de charge est assurée automatiquement. Lors de la tombée d’une instance, le faile over permet de conserver la continuité de service, avec une reprise automatique.
· FAILE OVER
Dans le cas d’une connexion en faile over, c’est la même instance qui est requêtée. En cas de panne, il y a bascule vers l’instance de backup, et en remontée de service il y a faile back pour revenir sur le nœud d’origine.
POOL CONNEXION
Le pool de connexion peut être dimensionné selon les besoins de charge avec des options de contrôle de validité de connexion afin de garantir le service. Le paramétrage peut être différent selon l’architecture mise en place et les cas d’usages.
Faire attention au nombre d’instances déclarées, car les pools déployés sur ces instances ont un facteur multiplicateur.
capacité maximum du pool * nombre de pool * nombre d’instance < capacité de connexion à la base
· Capacity Maximum
La taille maximum que peut atteindre le pool.
Pour déterminer la valeur, effectuer un test de charge en désactivant l’option Allow Shrinking et en positionnant le paramètre initial à 1 et Maximum au maximum. Après le test de charge, vérifier la valeur atteinte du pool (qui représente le maximum du test de charge). Prendre cette valeur +30% comme valeur maximum.
Mettre cette valeur en concordance avec le nombre de thread si on n’utilise pas le pool dynamique de threads (version 8.1 : en théorie, un thread pour une connexion. Attention, dans certains cas (transaction, développement spécifique) il se peut qu’il y ait plusieurs connexions pour un thread actif).
On pourra effectuer un paramétrage via le WorkManager pour attribuer autant de threads que de connexion associée au pool JDBC.
max-threads-constraint Taille maximum de nombre de thread à utiliser (Default : -1). (On peut associer la valeur de la contrainte à un pool JDBC Œ. Si la valeur du pool JDBC changer, cela affectera directement la valeur de la contrainte).
· Capacity Initial
La valeur minimale générée lors de la création du pool. Si l’option Allow Shrinking est activée le pool décrémente les connexions crée en plus pour revenir à la valeur minimale.
ü Prendre la même valeur que Maximum pour obtenir une réponse optimale (pas de perte de temps sur la création d’une connexion JDBC).
ü Dans le cas où le nombre de pool et de connexions associées est supérieur à la capacité maximale de connexion de la base, on pourra utiliser l’option de décrément avec une valeur minimale de pool inférieure aux maxima. Dans le cas de charges sur des plages de temps différentes selon les instances, le nombre de connexions sera lissé naturellement en incrémentant les pools en charge et en décrémentant les pools après la charge.
ü Si on souhaite optimiser le nombre de connexions à la charge, on pourra adopter un paramétrage de type Water Mark. Il suffit de déclarer un minimum à 1 et un maximum défini par les bench et de désactiver l’option de décrément. De cette façon, la valeur sera maintenue au plus haut de la charge de façon automatique. L’inconvénient étant que cette valeur est réinitialisée à chaque redémarrage de l’instance.
· Incrément
Le pas d’incrément
À positionner quand la valeur minimale est différente du maxima.
· Allow Shrinking
L’option de décrément après une charge.
À positionner selon le cas d’usage et si le minima est différent du maxima.
· Enable Connection Leak Profiling
Option à coche (malgré le surcoût de charge que cela induit) pour remonter toutes les connexions JDBC non relâchées par l’application.
· Test Frequency
Préférer ce mode dans le cas d’une plate-forme de production. Elle permet d’effectuer un test sur le pool tous les n secondes (prendre 5 minutes). Cela permet également de s’assurer de la validité des connexions dans le cas ou un il y a un firewall entre l’instance Weblogic et la base.
· Test Reserved/Created Connections/ Released Connection
Évité ces options, car elle impose un requêtage sur chaque action utilisateur (1 requête utilisateur + 1 requête de test)
INDISPONIBILITE
Voir la documentation pour les paramètres suivants :
ü Connection Creation Retry Frequency
ü Inactive Connection Timeout
ü Maximum Waiting for Connection
ü Maximum Connections Made Unavailable
Statement Cache Size
Extraction de la documentation de tuning Weblogic
Increasing Performance with the Prepared
Statement Cache
For each connection pool that you create in WebLogic Server, you can specify a prepared statement cache size. When you set the prepared statement cache size, WebLogic Server stores each prepared statement used in applications and EJBs until it reaches the number of prepared statements that you specify. For example, if you set the prepared statement cache size to 10, WebLogic Server will store the first 10 prepared statements called by applications or EJBs. When an application or EJB calls any of the prepared statements stored in the cache, WebLogic Server reuses the statement stored in the cache. Reusing prepared statements eliminates the need for parsing statements in the database, which reduces CPU usage on the databasemachine, improving performance for the current statement and leaving CPU cycles for other tasks.
The default value for prepared statement cache size is 0. You can use the following methods to set the prepared statement cache size for a connection pool:
! Using the Administration Console. See Creating and Configuring a JDBC Connection Pool in the Administration Console Online Help at
! Using the WebLogic management API. See the getPreparedStatementCacheSize() and
setPreparedStatementCacheSize(int cacheSize) methods in the Javadocs for WebLogic Classes at
! Directly in the configuration file (typically config.xml). To set the prepared statement cache size for a connection pool using the configuration file, before starting the server, open the config.xml file in an editor, then add an entry for the PreparedStatementCacheSize attribute in the JDBCConnectionPool tag. For example:
DriverName="com.pointbase.jdbc.jdbcUniversalDriver"
InitialCapacity="5" MaxCapacity="20" Name="demoPool"
Password="{3DES}ANfMduXgaaGMeS8+CR1xoA=="
PreparedStatementCacheSize="20" Properties="user=examples"
RefreshMinutes="0" ShrinkPeriodMinutes="15"
ShrinkingEnabled="true" Targets="examplesServer"
TestConnectionsOnRelease="false"
TestConnectionsOnReserve="false"
URL="jdbc:pointbase:server://localhost/demo"/>
Usage Restrictions for the Prepared Statement Cache
Using the prepared statement cache can dramatically increase performance, but you must consider its limitations before you decide to use it. Please note the following restrictions when using the prepared statement cache. There may be other issues related to caching prepared statements that are not listed here. If you see errors in your system related to prepared statements, you should set the prepared statement cache size to 0, which turns off prepared statement caching, to test if the problem is caused by caching prepared statements.
Calling a Stored Prepared Statement After a Database Change May Cause
Errors
Prepared statements stored in the cache refer to specific database objects at the time the prepared statement is cached. If you perform any DDL (data definition language) operations on database objects referenced in prepared statements stored in the cache, the statements will fail the next time you run them. For example, if you cache a statement such as select * from emp and then drop and recreate the emp table, the next time you run the cached statement, the statement will fail because the exact emp table that existed when the statement was prepared, no longer exists. Likewise, prepared statements are bound to the data type for each column in a table in
the database at the time the prepared statement is cached. If you add, delete, or rearrange columns in a table, prepared statements stored in the cache are likely to fail when run again.
Using setNull In a Prepared Statement
When using the WebLogic jDriver for Oracle to connect to the database, if you cache a prepared statement that uses a setNull bind variable, you must set the variable to the proper data type. If you use a generic data type, as in the following example, the statement will fail when it runs with a value other than null.
java.sql.Types.Long sal=null
.
.
.
if (sal == null)
setNull(2,int)//This is incorrect
else
setLong(2,sal)
Instead, use the following:
if (sal == null)
setNull(2,long)//This is correct
else
setLong(2,sal)
This issue occurs consistently when using the WebLogic jDriver for Oracle. It may occur when using other JDBC drivers.
Prepared Statements in the Cache May Reserve Database Cursors
WhenWebLogic Server caches a prepared statement, the prepared statementmay open a cursor in the database. If you cache too many statements, you may exceed the limit of open cursors for a connection. To avoid exceeding the limit of open cursors for a connection, you can change the limit in your database management system or you can reduce the prepared statement cache size for the connection pool.
Determining the Proper Prepared Statement Cache Size
To determine the optimum setting for the prepared statement cache size, you can emulate your server workload in your development environment and then run the Oracle statspack script. In the output from the script, look at the number of parses per second. As you increase the prepared statement cache size, the number of parses per second should decrease. Incrementally increase the prepared statement cache size until the number or parses per second no longer decreases. Note: Consider the usage restrictions for the prepared statement cache before you decide to use it in your production environment. See “Usage Restrictions for the Prepared Statement Cache” on page 8-38 for more information.
Using a Startup Class to Load the Prepared Statement
Cache
To make the best use of the prepared statement cache and to get the best performance, you may want to create a startup class that calls each of the prepared statements that you want to store in the prepared statement cache. WebLogic Server caches prepared statements in the order that they are used and stops caching statements when it reaches the prepared statement cache size limit. By creating a startup class that calls the prepared statements that you want to cache, you can fill the cache with statements that your applications will reuse, rather than with statements that are called only a few times, thus getting the best performance increase with the least number of cached statements. You can also avoid caching prepared statements that my be problematic, such as those described in “Usage Restrictions for the Prepared Statement Cache” on page 8-38. Even if the startup class fails, WebLogic Server loads and caches the statements for
future use.
Data Source
Emulate Two-Phase Commit for non-XA Driver
StreamChunk Size
- Required only for large requests/responses
- Appropriate tuning reduces number of socket reads/writes
- Main factors: MTU and request size
- -Dweblogic.ChunkSize and -Dweblogic.utils.io.chunkpoolsize
- Higher memory requirements
A chunk is a unit of memory that the WebLogic Server network layer, both on the client and server side, uses to read data from and write data to sockets. A server instance maintains a pool of these chunks. For applications that handle large amounts of data per request, increasing the value on both the client and server sides can boost performance. See Tune the Chunk Parameters.
1.1.1 Tune the Chunk Parameters
A chunk is a unit of memory that the WebLogic Server network layer, both on the client and server side, uses to read data from and write data to sockets. To reduce memory allocation costs, a server instance maintains a pool of these chunks. For applications that handle large amounts of data per request, increasing the value on both the client and server sides can boost performance. The default chunk size is about 4K. Use the following properties to tune the chunk size and the chunk pool size:
- weblogic.Chunksize—Sets the size of a chunk (in bytes). The primary situation in which this may need to be increased is if request sizes are large. It should be set to values that are multiples of the network's maximum transfer unit (MTU), after subtracting from the value any Ethernet or TCP header sizes. Set this parameter to the same value on the client and server.
- weblogic.utils.io.chunkpoolsize—Sets the maximum size of the chunk pool. The default value is 2048. The value may need to be increased if the server starts to allocate and discard chunks in steady state. To determine if the value needs to be increased, monitor the CPU profile or use a memory/ heap profiler for call stacks invoking the constructor weblogic.utils.io.Chunk.
- weblogic.PartitionSize—Sets the number of pool partitions used (default is 4). The chunk pool can be a source of significant lock contention as each request to access to the pool must be synchronized. Partitioning the thread pool spreads the potential for contention over more than one partition.
Row Prefetch Enabled/Size
Extraction de la documentation de tuning Weblogic
Row Caching with the WebLogic RMI Driver
Row caching is a WebLogic Server JDBC feature that improves the performance of your application. Normally, when a client calls ResultSet.next(), WebLogic Server fetches a single row from the DBMS and transmits it to the client JVM. With row caching enabled, a single call to ResultSet.next() retrieves multiple DBMS rows, and caches them in client memory. By reducing the number of trips across the wire to retrieve data, row caching improves performance.
Note: WebLogic Server will not perform row cachingwhen the client andWebLogic Server are in the same JVM.
You can enable and disable row caching and set the number of rows fetched per ResultSet.next() call with the Data Source attributes Row Prefetch Enabled and Row Prefetch Size, respectively. You set Data Source attributes via the Administration Console. To enable row caching and to set the row prefetch size attribute for a
DataSource or TxDataSource, follow these steps:
1. In the left pane of the Administration Console, navigate to Services→JDBC→Data Sources or Tx Data Sources, then select the DataSource or TxDataSource forwhich you want to enable row caching.
2. In the right pane of the Administration Console, select the Configuration tab if it is not already selected.
3. Select the Row Prefetch Enabled check box.
4. In Row Prefetch Size, type the number of rows you want to cache for each ResultSet.next() call.
DEPASSEMENT DE CAPACITE
Le paramétrage de mise en attente des requêtes sur un pool en saturation se trouve sur la console Weblogic (temps en seconde):
Consoleà${domaine}àServiceàJDBCàData Sourcesà${datasource}àConnection PoolàConnection Reserve Timeout
Lors d’un test de simulation de dépassement de capacité on peut observer la métrique WaitSecondsHighCount atteindre cette valeur (ce qui signifie qu’il y a eu attente et rejet).
Une exception sur la partie cliente intervient sur le rejet avec une Ressource Exception.
Error:Internal error: Cannot obtain XAConnection weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool XE to allocate to applications,
please increase the size of the pool and retry..
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResourceInternal(ResourcePoolImpl.java:559)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:332)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:322)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:431)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:316)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:93)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:61)
at weblogic.jdbc.jta.DataSource.getXAConnectionFromPool(DataSource.java:1584)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1387)
at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:438)
at weblogic.jdbc.jta.DataSource.connect(DataSource.java:395)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:355)
at weblogic.jdbc.common.internal.RmiDataSource_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Pour prévenir être alerté sur ces échecs, on pourra monitorer l’attribut MBean FailedReserveRequestCount.
Libellés :
Inscription à :
Publier les commentaires (Atom)
AUTEUR
- Jean FRANCOIS
- Carrières Sur Sein, Yvelines, France
- Consultant Oracle (Ancien consultant BEA depuis 2001), je m’occupe des expertises sur les produits Oracle : SOCLE (Weblogic, Coherence, JRockit) SOA (Service Bus, SOA Suite, BPM)
MON CV
MAP
CULTURES
LIVRES
1 commentaires:
Bonjour,
J'utilise Weblogic 9.0/9.2/10 couplé à une base Oracle 10G. Notre appli est déployé sur un domaine, pas de clusters et pas d'autres applications partageant l'environnement Weblo.
Oracle 10G possède un Shared pool qui 'garde' les plans d'exécution des requêtes précédemment exécutées.
Il est possible de définir un 'Statement Cache size' pour un pool de connexion afin d'éviter un parsing de la requête.
Mais quel est le plus avantageux? utiliser le cache du pool ou celui de la base de données?
Enregistrer un commentaire