home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2320 < prev    next >
Encoding:
Internet Message Format  |  1992-11-05  |  2.4 KB
  1. Path: sparky!uunet!oracle!pyramid!infmx!davek
  2. From: davek@informix.com (David Kosenko)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: SE vs OnLine results question
  5. Keywords: benchmark online standard engine
  6. Message-ID: <1992Nov5.170648.7064@informix.com>
  7. Date: 5 Nov 92 17:06:48 GMT
  8. References: <1992Nov4.151718.24914@elsouth.uucp>
  9. Sender: news@informix.com (Usenet News)
  10. Organization: Informix Software, Inc.
  11. Lines: 46
  12.  
  13. John White writes:
  14. >
  15. >   I'm the guy that said I was going to be comparing OL vs SE. I've got 
  16. >some preliminary results back from the first test suite and it has raised 
  17. >some questions.
  18. >
  19. >   I created a test script that would create, load, and index 4 tables. 
  20. >This would test insert and index performance. The insert performance was 
  21. >consistently worse in Online (12-75% depending on the bytes/row - the larger, 
  22. >the worse). The wierd things is that as I added indexes, the gains that 
  23. >OnLine brought diminished. It went like this:
  24. >
  25. >    Table    # Indexes    Pct Faster
  26. >    1        4        +265
  27. >    2        8        +82
  28. >    3        8        +44
  29. >    4        2        -22
  30. >
  31. >   I declared rootdbs to be 20M and the testdbs to be 171M. They share a 
  32. >191M drive. The tables take up 71M. All of the indexes are unique.
  33. >
  34. >   My question to the OnLine heads: Is there an obvious fundamental 
  35. >flaw in my setup that is causing the indexing performance to degrade?
  36. >I need to know ASAP as it might invalidate all further tests.
  37. >
  38. >   - john (john%elsouth@concert.net)
  39.  
  40. It is not clear at all what measurement your numbers represent.  Pct Faster
  41. than what?  Are you saying that the whole create/load/index was faster?
  42. Please explain your table (above) more clearly.
  43.  
  44.  
  45. In general, you will probably find that SE outperforms OnLine in low user
  46. count tests (1 user is the extreme).  This is because OnLine is designed
  47. to handle high user, high throughput operations.  Testing it with one user
  48. is incurring a lot of overhead for that one user.  As your user count
  49. increases, that overhead is amortized over more users and it becomes
  50. more efficient.  Try testiong 20 users inserting into those tables, and
  51. you should find that OnLine outperforms SE by a large factor.
  52.  
  53. Dave
  54. -- 
  55. Disclaimer: These opinions are not those of Informix Software, Inc.
  56. **************************************************************************
  57. "I look back with some satisfaction on what an idiot I was when I was 25,
  58.  but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney
  59.