WebLogic optimization is a rich area for possibilities due to the numerous technologies and monitoring tools involved. One crucial area is the database; this post will talk about RDBMS, with subsquent posts in this series addressing NoSQL and data caching.
- JNDI lookups are relatively expensive, so use caching for any objects that initialize database connections (or ANY connections for that matter, such as JMX connections that might be done for server performance monitoring).
- Use resource pooling for connections to the database from WebLogic. The WebLogic JDBC connection pooling feature allows this to be configured relatively easily.
- The Prepared Statement Cache should be optimized and used. This cache keeps compiled SQL statements in memory, thus avoiding a round-trip to the database when the same statement is used later.
- Dive deeper into that realm, and ensure that whenever possible, stored procedures, packages and similar program constructs are used rather than SQL statements.
- Let the RDBMS server do the heavy lifting; that’s what it’s designed to do: serve.
- Understand the set orientation of SQL (which abhors unnecessary use of cursors).
- Understand that other applications may also be accessing that database, and that the root cause of sudden poor performance may be some other business entity hitting that server. Try to ensure your database administrators keep you in the loop in such matters.
These are just some of the considerations that take us out of the application tier and into the database tier, but which may result in perceived poor application performance.
View Comments