Design | Prototype | Development | Testing | Staging | Production | Optimization
Like any production application, Omnidex applications should be monitored to insure the best performance and flexibility. Monitoring an Omnidex application is very similar to monitoring any production application. Overall performance is monitored by checking on the available system resources for the servers. Load balancing and connection pools are commonly used to insure the highest performance and connectivity. It is also important to watch for competing processes running on the servers as they can adversely affect Omnidex performance.
There are several common strategies for maintaining a production Omnidex application:
Omnidex delivers the highest performance when there is a healthy balance between the main system resources: processor speed, memory and disk access. Omnidex's performance is limited by the slowest of these three resources.
Omnidex uses substantial amounts of all these resources when building indexes. Building indexes is a very intensive process and is often localized on a separate server for this reason. Building indexes on a server that is actively servicing concurrent users can degrade the performance of both activities.
Well-optimized Omnidex queries will use short bursts of all of these resources. That is the goal of Omnidex optimization – to allow the query to complete quickly so that resources are freed for the next query. This will happen naturally with well-optimized applications; however, some applications will also need to support long-running queries. If needed, these applications can redirect these queries to a separate server to insure the best performance.
Omnidex responds well to load balancing. Omnidex does not provide its own load balancing, but it easily responds to general load balancers that are used across the application or the enterprise. Typically, load balancers direct queries to lightly loaded servers, and this helps insure that all Omnidex queries remain fast. Some load balancers may also direct certain classes of queries to specific servers in recognition of their resource needs.
Connection pools are a common method of caching database connections. This helps insure the speed of queries. These connection pools will keep the Omnidex Environment open, along with the corresponding database connections and Omnidex index files. Many applications use connection pooling services such as Java's DBCP services.
For Omnidex Grids, Omnidex provides a pooling service for the internal connections to the grid nodes. This can reduce the connection overhead with Omnidex Grids.
Omnidex performance can be impacted by other applications running on the server. One of the most common examples is the relational database itself. Most relational databases will spawn as many threads as the server will support, and will consume the majority of the memory on the server. This maximizes their performance but degrades the other processes on that server. Relational databases rely more heavily on disk access as well. It is common to see a large multi-processor machine with plenty of memory and fast disk drives fully consumed by the relational database. When this happens it is appropriate to move Omnidex onto a different server than the database, and direct Omnidex to access the database over the network.
Omnidex applications do not need much periodic maintenance. It is valuable to defragment the Omnidex index files by regularly defragmenting the disk drives. It is also important to defragment the underlying data, especially in the case of raw data files. Omnidex uses a temporary file space, so the drive containing the temporary file space directory should be maintained with plenty of unfragmented disk space.
See also: