CPU and RAM for TimesTen

Question

I have test performance statistics for our java application (using oracle db) on a 4 X Quad-Core AMD Opteron™ 8360 SE cpu node with 64 GB RAM.
I am trying to collect performance statistics for TimesTen on a 2 X Dual Core Intel Xeon 5160 cpu node with 8 GB RAM.
My question is how does TimesTen treat processors. Is dual core considered as 2 cpu or single cpu?
So am I comparing performance - (2 X 2 = 4) TT vs (4 X 4 = 16) Oracle DB ?
Any suggestions on how should we compare the performance statistics obtained on the two machines ?

Answer 1

Please see my answers embedded below:
1. Under what conditions does TimesTen use multiple processors ?
CJ>> There are many background daemon components to TimesTen that are multi-threaded and may use multiple processors to some extent as required (main daemon, sub-daemons, replication agent, cache agent).
The main daemon is a very lightweight process that is purely supervisory in nature. It is not involved in database transatcion processing etc. and so its CPU usage is very low.
Each active datastore (database) has a dedicated managing sub-daemon. Again, this is not directly involved in transaction processing but it too has several threads. The checkpointer thread may use a lot of CPU while a checkpoint is occurring. The log flusher thread will use CPU in proportion to the intensity of write operations (primarily INSERT/UPDATE/DELETE) in the application workload (this thread is responsible or flushing the transaction log buffer to the log files on disk).
If replication, or AWT caching, is used the replication agent transmitter and/or receiver threads may use significant CPU depending on the replicated workload.
If Cache Connect is being used then the cache agent threads may use significant CPU when e.g. an AUTOREFRESH is in progress.
These ar all background activities and you do not have direct control over how many CPUs or how much CPU time is used by them. They will try and use what they need and the O/S will allocate them time based on available system resources.
Equally significant is the CPU power used to process application transactions. Each application process/thread that is executing via a separate connection will potentially be executing concurrently within TimesTen hence if you have 20 application threads (or processes) each with its own connection to a TimesTen datastore then TimesTen could potentially use up to 20 CPUs/cores concurrently. This is the key factor in your ability to control how many CPUs/cores TimesTen. The crucial things to understand here are:
1. In direct connection mode there is no dedicated TimesTen server process. All DBMS logic is encapsulated in the TimesTen library (libtten.so). All database query and transaction processing is actually executed in the context of the application thrad that makes the database call. Hence, as I mentioned, if there are 'n' concurrent application processes/threads each with a separate database connection then TimesTen can potentially use 'n' CPUs/cores concurrently. Essentially, # concurrent connections = max concurrent CPUs/coires.
2. In client server there is a dedicated server process or thread (depending on configuration) for each application connection and so again # concurrent connections = maximum number of concurrent CPUs / cores that will be used.
2. What techniques do I use to ensure maximum performance on this -
a. Machine with 2 cpu (each is a dual core processor) and 8 GB RAM.
CJ>> The number of physical CPUs (chips) is irrelevant. What matters is the number of cores. In this case 4. So, the system can concurrently execute up to 4 tasks. Anything more than 4 and tasks may have to wait for available CPU in order to execute. Since there are no blocking operations within TimesTen database processing then from a TimesTen perspective this machine can execute 4 application threads performing database access at maximum speed. Of course in reality CPU time is needed for the application, O/S, TT background processes etc. etc. so one would aim for fewer than 4 concurrent database processes. This assumes of cousre that there is no blocking at the application level either and that these processes or threads can therefore spend 100% of the available time executing. If the application blocks for any reason (e.g. waiting for the next 'request' from somewhere) then this introduces idle toime and so one can increase the number of concurrent application processes/threads to use up this idle time thereby increasing overall throughput.
b. Application using direct connection mode with weblogic Application server
CJ>> See my comments above. Generally one would use a connection pool and configure the number of connections to optimise performance (some experiments will be needed to arrive at the optimal value since it is very much dependant on the application workload and processing model).
c. All data is cached in TimesTen (using Cache Groups) for read intensive operations (There are few write operations as well but TT is mainly for the reads). Should the connections be 4 or 3 in this case ?
CJ>> If the volume of cache refrshes is low then you don't ned to 'reserve' much CPU for checkpointing logging and so you have all 4 cores available for application+database processing (plus O/S etc.). If the application is mostly using the database and not waiting for stuff outside the database then the optimal number of connections is probably in the range of 3-6. If the application does a lot of non-database work which may include waiting for things then the optimal number of connections will be much higher. Again, you need to experiment to find out what is optimal.
Chris