This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
admin:admin:applications:production [2011/01/10 17:08] 127.0.0.1 external edit |
admin:admin:applications:production [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | {{page>:top_add&nofooter&noeditbtn}} | + | ~~NOTOC~~ |
| + | {{page>:top_add&nofooter&noeditbtn}} | ||
| - | ====== Omnidex Administration ====== | + | ====== Administration: Administration Basics ====== |
| ===== Building Omnidex Applications ===== | ===== Building Omnidex Applications ===== | ||
| - | [[admin:admin:applications:design|Design]] -> [[admin:admin:applications:prototype|Prototype]] -> [[admin:admin:applications:development|Development]] -> [[admin:admin:applications:testing|Testing]] -> [[admin:admin:applications:staging|Staging]] -> **[[admin:admin:applications:production|Production]]** -> [[admin:admin:applications:optimization|Optimization]] | + | [[admin:admin:applications:design|Design]] | [[admin:admin:applications:prototype|Prototype]] | [[admin:admin:applications:development|Development]] | [[admin:admin:applications:testing|Testing]] | [[admin:admin:applications:staging|Staging]] | **[[admin:admin:applications:production|Production]]** | [[admin:admin:applications:optimization|Optimization]] |
| ---- | ---- | ||
| - | |||
| ==== Production ==== | ==== Production ==== | ||
| Line 26: | Line 26: | ||
| 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 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 a great deal 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. | + | 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. | 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. | ||
| Line 37: | Line 37: | ||
| === Connection Pools === | === Connection Pools === | ||
| - | Connection pools are a common method of caching database connections. This helps insure the speed of queries. These connection pools will 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. Alternatively, Omnidex Network Services provides a connection pooling facility. | + | 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. | ||
| === Competing Applications === | === Competing Applications === | ||
| Line 45: | Line 47: | ||
| === Periodic maintenance === | === Periodic maintenance === | ||
| - | 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 defragement the underlying data, especially in the case of raw data files. Omnidex uses a temporary file space, so so the drive containing the temporary file space directory should be maintained with plenty of unfragmented disk space. | + | 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. |
| - | ====== ====== | ||
| - | \\ | ||
| - | ---- | ||
| - | \\ | ||
| - | The next stage in building an Omnidex application is [[admin:admin:applications:optimization|Optimization]]. | + | ===== ===== |
| **[[admin:admin:applications:staging|Prev]]** | **[[admin:admin:applications:optimization|Next]]** | **[[admin:admin:applications:staging|Prev]]** | **[[admin:admin:applications:optimization|Next]]** | ||
| + | ====== Additional Resources ====== | ||
| + | |||
| + | See also: | ||
| + | |||
| + | {{page>:admin:admin:see_also&nofooter&noeditbtn}} | ||
| {{page>:bottom_add&nofooter&noeditbtn}} | {{page>:bottom_add&nofooter&noeditbtn}} | ||
| + | |||
| + | |||