Re: Informix Performance Test

David J Meyer wrote: +> The strange thing is that I can only get 400 rows per +> second inserting into this table. The table has no +> indexes and is spanned over 4 spaces. I know that +> the problem is not ODBC - we are getting roundtrip +> clock rates from 0-15 milliseconds. +> +> Does any one have any ideas of what I can look at +> to raise these rates?... The processor itself can +> handle alot more than this. I dont think it is +> head contention because I used ROUND ROBIN and +> there are no indexes...Logging is Off. [...] +> Desc: Allows user to select number of threads. +> Will send insert statement through ODBC +> into a test table comprised of one integer column. Couple of thoughts: First, bear in mind that a table consisting of one integer column is a wierd situation. Since OnLine can only support 255 rows/page, you are going through a lot more pages that would normally be the case. Measured on a per byte basis, your insert time might not be all that bad. Try comparing the performance as you increase the number of integer columns in the table. Second, are you sure the program can drive > 400 rows/sec? Just asking. Third, what are your checkpoint intervals and durations? With the rate you will be snarfing through buffer pages, you're likely to be filling up the physical log pretty darned quick. For such a test, I'd have LRU_MIN_DIRTY and LRU_MAX_DIRTY cranked WAY down - like 1 and 2 or so. Otherwise the checkpoint duration could be a killer. What does the message log say? Duration of > 1 or 2 seconds is death in such a test. Finally, to get > 400 rows/sec, insert in parallel (i.e. run lots of inserts at the same time). Btw, the contention that "mutexes" are somehow the cause is pretty unlikely if only a single insert proc is running - where's the contention? Also, run some sars to see if the processor is in fact maxed out or not. Dave