home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8680 < prev    next >
Encoding:
Text File  |  1992-12-24  |  2.1 KB  |  50 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!math.fu-berlin.de!mailgzrz.TU-Berlin.DE!news.netmbx.de!Germany.EU.net!infix.de!oliver
  3. From: oliver@infix.de (Oliver Okrongli)
  4. Subject: Re: Informix Performance Tips Query
  5. In-Reply-To: nh@cbnewsg.cb.att.com's message of Wed, 23 Dec 1992 08:44:42 GMT
  6. Message-ID: <OLIVER.92Dec23220135@snoopy.infix.de>
  7. Sender: oliver@infix.de (Oliver Okrongli)
  8. Organization: infix Software-Systeme GmbH
  9. References: <1992Dec23.084442.16657@cbfsb.cb.att.com>
  10. Date: Wed, 23 Dec 1992 21:01:35 GMT
  11. Lines: 37
  12.  
  13. >>>>> On Wed, 23 Dec 1992 08:44:42 GMT, nh@cbnewsg.cb.att.com (nicholas.hounsome) said:
  14.  
  15. > Has anybody got any tips on how to get the best performance out
  16. > of informix (online) ESQL?
  17. > The database is about 10M with the largest table being about 
  18. > 20K rows.
  19. > Increasing the cache size seems like a good idea. I have tried a lot
  20. > of other stuff that they recommend and it doesn't seem to make much
  21. > difference (eg. extent sizes).
  22.  
  23. You could try to figure out the maximum amount of main memory your OS
  24. and applications need (avoid paging).  Then dedicate the remaining
  25. available memory to OnLine as shared memory segment (you may also need
  26. to increase kernel parameters).  This might increase OnLine's cache
  27. hit rate (tbmonitor should show you).  Generic cache problems apply -
  28. at some point further increasing cache size yields neglectable
  29. performance improvements.
  30.  
  31. Increasing cache does not protect you against CPU bottlenecks.
  32.  
  33. BTW - 10M does not sound like a typical OnLine environment.  We do
  34. databases >100M with SE with larger tables containing 150k rows.
  35.  
  36. > How nuch difference does preparing statements make compared to
  37. > statements fully parsed by esql?
  38.  
  39. Depends on your statements.  Using prepared statements we have noticed
  40. execution times at 75% to 50% the time of non-prepared statements.
  41. This is especially true in case of small operations involving little
  42. I/O.  The disadvantage is that syntax checking is done at run time.
  43.  
  44. Hope this helps.
  45.  
  46. -- 
  47. Oliver Okrongli        infix Software-Systeme GmbH      Phone +49 531 238090
  48.             Rebenring 33              Fax   +49 531 3801152
  49. oliver@infix.de        D-W-3300 Braunschweig          F.R. Germany
  50.