How Insert Work on global cache group?

Question

Hi all , i'm doing some test about how many transactions for second TimesTen can process.
With a normal configuration "direct" i reached 5200 transaction for second, on my machine (OS windows normal work station).
now i'm using the global cache groups because we need more then one DataSource , and they have to be syncro, one with each other.
And how i read in the guide the global cache group are perfect for this purpose.
After configured the 2 environment with different DataBase TimesTen (those machine are server SUN, much better of my work station :P), i tried a simple test
of insert on a single node.
But i reached only 1500 as maximum value of transactions for second.
The 5200 value when testing on my work station was with normal Dynamic Cache Group, not Global. So i was thinking if this performance issue was related on how the Insert statement work on a global cache group.
Some questions:
1) before the insert is done on Oracle, the Cache Group do some query on the other cache global group to avoid some conflicts on primary key?
2) there is any operation performed from global cache to others when a statement is sendend?
The 2 global cache anyway are working well, locking and changing owner on a instance cache so no problems detected atm are about " how they have to work":).
The problem is only that we need that the global cache do it more and more faster :P at last the 5200 transaction for second i reached on my work station.
Thanks in advance for any suggestion.
P.S.:I don't know much about the server configuraion (SO solaris some version) but anyway good machines :).

Answer 1

Okay, the rows here are quite large so you need to do some tuning. In the ODBC (DSN) parameters I see that you are using the default log buffer abd log file sizes. these are totally inadequate for this kind of workload. You should increase both to a larger value. For this kind of workloads typial values would be in the range of 256 MB to 1024 MB for both log buffer and log file size. If you are using 32-bit TimesTen you may be constrained on how large you can make these sicne the log buffer is part of the overall datastore memory allocation wh9ich on 32-bit platforms is quite limited. On 64-bit TimesTen you have no such restriction (as long as the machine has enough memory). Here is an example of the directives you would use to set both to 1 GB. The key one is the log buffer size but it is important that LogFileSize is >= LogBufMB.
[my_ds]
LogBufMB=1024
LogFileSize=1024
For this change to take effect you need to shutdown (unload from memory) and restart (load back into memory) the datastore.
Secondly, it's hard to be sure from your example code but it looks like maybe you are pre-paring the INSERT each time you execute it? If that is the case this is very expensive and unnecessary. You only need to prepare once and then you can execute many times as follows:
insPs = connection.prepareStatement("Insert into test.transactions (ID_ ,NUMBE,SHORT_CODE,REQUEST_TIME) Values (?,?,?,?)");
for (int i=1; i < 1000000; i++)
insPs.setString(1,""+getSequence());
insPs.setString(2,"TEST_CODE");
insPs.setString(3,"TT Insert test");
insPs.setTimestamp(4, new Timestamp(System.currentTimeMillis()));
insPs.execute();
connection.commit();
This should improve performance noticeably. mif you can get away with only comiting every 'N' inserts you will see a further uplift. For example:
int COMMIT_INTVL = 100;
for (int i=1; i < 1000000; i++)
insPs.setString(1,""+getSequence());
insPs.setString(2,"TEST_CODE");
insPs.setString(3,"TT Insert test");
insPs.setTimestamp(4, new Timestamp(System.currentTimeMillis()));
insPs.execute();
if ( (i % COMMIT_INTVL) == 0 )
connection.commit();
connection.commit();
And lastly, the fastest way of all is to use JDBC batch operations; see the JDBC documentation about batch operations. That will improve insert performance still more.
Lastly, a word of caution. Although you will probably be able to easily achieve more than 5000 inserts per second into TimesTen, TimesTen may not be able to push the data to oracle at this rate. the rate of push to Oracle is likely to be significantly slower. Thus if you are executing a continuous high volume insert workload into TimesTen two things will happen; (a) the datastore will become fiull and unable to accepot any more inserts until you explicitly remove some data and (b) a backlog will build up (in the TT transaction logs on disk) of data waiting to be pushed to Oracle.
This kind of setup is not really suited to support sustained high insert levels; you need to look at the maximum that can be sustained for the whole application -> TimesTen -> Oracle pathway. Of course, if the workload is 'bursty' then this may not be an issue at all.
Chris