Table of Contents

About

Oracle TimesTen In-Memory Database (TimesTen) delivers real-time performance by changing the assumptions around where data resides at runtime.

Timesten Response Transactions Average

Performance Monitoring has two dimensions :

  • response time. With TimesTen, a transaction that reads a database record can take less than 2 microseconds, and transactions that update or insert a record can take less than 7 microseconds (measured on Oracle Linux running Intel Xeon 5670 2.93Ghz processors).
  • and throughput. Throughput is measured in tens to hundreds of thousands of transactions per second, using commodity hardware.

Workload Comparison

From the OBE.

Initialized the workload package on TimesTen
  
Called workload.oltp_read_only  10000 times. TPS = 5347.5
Called workload.oltp_read_write 10000 times. TPS = 1745.2

Initialized the workload package on Oracle Database
  
Called workload.oltp_read_only  10000 times. TPS = 948.7
Called workload.oltp_read_write 10000 times. TPS = 334.7

Best practice

Connection Pooling

As an in-memory database, TimesTen uses available processor resources efficiently and is, in general, CPU-bound (as supposed to disk-bound for many applications running on disk-based RDBMS). In general, it is difficult to achieve best performance if there are more concurrent connections active simultaneously than there are CPUs on your machine to handle the operations, and unnecessary concurrent connections may result in lower application throughput If your application requires a lot of connections, you should ensure that connections are held efficiently for the transactions. Efficient usage of connections via a connection pool is better than having lots of idle connections. For examples of connection poolings using TTClasses and JDBC, see the Quick Start demo. Also, commercial J2EE application servers typically use connection pooling by default.

Documentation / Reference