home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / informix / 1851 < prev    next >
Encoding:
Text File  |  1992-09-01  |  1.7 KB  |  42 lines

  1. Newsgroups: comp.databases.informix
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbfsb!cbnewsg.cb.att.com!ashaw
  3. From: ashaw@cbnewsg.cb.att.com (andrew.shaw)
  4. Subject: Online Performance Degradation
  5. Message-ID: <1992Sep1.174328.6212@cbfsb.cb.att.com>
  6. Keywords: select prepare sun
  7. Sender: news@cbfsb.cb.att.com
  8. Organization: AT&T
  9. Date: Tue, 1 Sep 1992 17:43:28 GMT
  10. Lines: 30
  11.  
  12. I hope someone can help with a performance mystery with an ESQL-C program.
  13. We are using Online 4.0 on a Sun 690 w 4 processors, 128M, etc.  The
  14. process starts up and begins doing transactions from a file (adding data,
  15. with lookups) to an empty database.  The performance data looks like this:
  16.  
  17. Elapsed minutes:   1    2    3 ... 10  ... 35  ... 50
  18. # of transaction: 220  210  200    150     100     50
  19.  
  20. If you plot the number of transactions possible against elapsed time you get
  21. what looks like a log N graph, ie plotted on log paper you get a downward
  22. sloping straight line.  I should point out that since we are doing adds,
  23. the elapsed time reflects the database getting continuously larger, albeit
  24. at a slowing rate.
  25.  
  26. So, the question is: why would performance be falling off in such a drastic
  27. and sterotyped fashion?  The logN nature must surely be a clue, but I can't
  28. fathom OnLine internals.  The performance fall-off slows, but since this
  29. program is supposed to run briskly over time, I am concerned that the
  30. performance might be asymptotic to zero transactions per minute.
  31.  
  32. All of the ESQL-C statements are $prepared the first time they are run,
  33. and their cursors $declared.  There are hardly any joins (if any at all).
  34. There is a table with a combination (2 ints) index.
  35.  
  36. Any help would be most appreciated.
  37.  
  38.     Thanks,
  39.         Andrew Shaw
  40.         AT&T Bell Labs
  41.  
  42.