home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / informix / 2352 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  4.7 KB
  1. Path: sparky!uunet!ukma!netsys!decwrl!gossip.pyramid.com!pyramid!infmx!davek
  2. From: davek@informix.com (David Kosenko)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: SE vs OL - Lets get to the crux.
  5. Message-ID: <1992Nov9.170244.20742@informix.com>
  6. Date: 9 Nov 92 17:02:44 GMT
  7. References: <1992Nov6.194129.4846@elsouth.uucp>
  8. Sender: news@informix.com (Usenet News)
  9. Organization: Informix Software, Inc.
  10. Lines: 83
  11.  
  12. John White writes:
  13. >   On the other hand, I do think think this is the right forum for
  14. >one of the non-application-specific issues that was brought up.
  15. >It has been repeatedly pointed out that OnLine doesn't show its 
  16. >performance increase at lower user numbers. I've been promised that 
  17. >OnLine is buttloads better when the user count goes up. I don't 
  18. >think so. 
  19. >
  20. >   TEST: 
  21. >      o Put 50 users on each of two machines
  22. >     o One machine running OnLine
  23. >     o One running Standard Engine
  24. >      o Have all of the users pull up perform screens.
  25. >      o Have the users do nothing (easy).
  26. >      o Run database performance tests on each machine.
  27. >      
  28. >   I think you'll get very similar numbers to when there is a single 
  29. >user. I submit that the important factor in the equation is not the 
  30. >number of users, it is more likely the number or transactions per 
  31. >second, or the number of transactions per user per second.
  32.  
  33. Well of course users doing nothing do not affect the performance.  I'm sure
  34. most of those (myself included) who suggested more users meant more users
  35. doing work! TPS is of course, key, but with a single user it is almost
  36. impossible to stress OnLine sufficiently to get anything approaching peak
  37. performance from it.  For that you need a lot of users doing a lot of work,
  38. i.e. a lot of transactions.
  39.  
  40. >   Having said that and feeling the incoming corrections in my 
  41. >peripheral conscience, I ask four things:
  42. >
  43. >   2) If I'm wrong, what is the correct answer? What is that elusive 
  44. >      most-important-factor (X), that as X increases, the performance 
  45. >      of OnLine does not degrade as rapidly as Standard Engine.
  46.  
  47. You asking for X is , in my opinion, misplaced.  Buffering of data in 
  48. shared memory is pretty much what buys OnLine performance over SE (at least
  49. in the simplest analysis).  Raw disk access helps too, but only if
  50. you are doing a lot of i/o relative to processing.
  51.  
  52. Again, keep in mind that OnLine is doing a bit more work to achieve the
  53. same end as SE (for example, physical logging, an OnLine consistency/recovery
  54. mechanism, is not present at all in SE).  This added work cost gets amortized
  55. over higher user counts, to the point where it becomes a benefit.
  56.  
  57. Also consider shared memory buffering.  If two users want the same data, one
  58. of them causes the data to be read from disk into shared memory.  The second
  59. user can just read it directly from shared memory.  So the i/o cost for 
  60. such an operation for one user is X, that same operation for two users is X/2,
  61. and so on.  As the user count increases, the cost of that i/o for any single
  62. user gets smaller.  With SE, each user pays cost X, regardless of how many
  63. users there are (and when updates are added into the equation, the costs
  64. increase considerably for SE, but very little for OnLine).
  65.  
  66. >   3) How does a person measure this factor on his active system? How 
  67. >      can I say with confidence that at my shop X = 4.63?
  68.  
  69. Have your benchmark time operations against the database for each user.
  70. For example, perform inserts into the table and time a number of inserts
  71. for each user.  This gives you inserts/second.  Run 1 user, 2 users, etc.
  72. For multi-user runs, sum the resulting inserts/second.  Perform the tests
  73. on OnLine and SE.  You can use selects (count records fetched), updates,
  74. deletes, etc.  Compare the results.  Unless you have your OnLine system
  75. tuned extremely poorly, you will no doubt find that as the user count
  76. increases, SE performs worse while OnLine performs better.  
  77.  
  78. >   4) What is the break point? At what point do the performance gains 
  79. >      that OnLine brings make up for its overhead costs? i.e. When X > 2.
  80.  
  81. Depends on the application, tuning, CPU, etc. etc.  For an example, on
  82. an RS6000 running a more-or-less tpc-B benchmark, an untuned OnLine
  83. system peaked (for me) at about 25 users.  This means that after 25, the
  84. performance started to drop.  Tuning the machine and OnLine could have 
  85. increased that substantially (esp. since I had one disk for everything),
  86. but the purpose of that exercise was to see what "out of the box" performance
  87. looked like.  You number will depend on many different variables.
  88.  
  89. Dave
  90. -- 
  91. Disclaimer: These opinions are not those of Informix Software, Inc.
  92. **************************************************************************
  93. "I look back with some satisfaction on what an idiot I was when I was 25,
  94.  but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney
  95.