Re: SE vs OL - Lets get to the crux.

John White writes: > On the other hand, I do think think this is the right forum for >one of the non-application-specific issues that was brought up. >It has been repeatedly pointed out that OnLine doesn't show its >performance increase at lower user numbers. I've been promised that >OnLine is buttloads better when the user count goes up. I don't >think so. > > TEST: > o Put 50 users on each of two machines > o One machine running OnLine > o One running Standard Engine > o Have all of the users pull up perform screens. > o Have the users do nothing (easy). > o Run database performance tests on each machine. > > I think you'll get very similar numbers to when there is a single >user. I submit that the important factor in the equation is not the >number of users, it is more likely the number or transactions per >second, or the number of transactions per user per second. Well of course users doing nothing do not affect the performance. I'm sure most of those (myself included) who suggested more users meant more users doing work! TPS is of course, key, but with a single user it is almost impossible to stress OnLine sufficiently to get anything approaching peak performance from it. For that you need a lot of users doing a lot of work, i.e. a lot of transactions. > Having said that and feeling the incoming corrections in my >peripheral conscience, I ask four things: > > 2) If I'm wrong, what is the correct answer? What is that elusive > most-important-factor (X), that as X increases, the performance > of OnLine does not degrade as rapidly as Standard Engine. You asking for X is , in my opinion, misplaced. Buffering of data in shared memory is pretty much what buys OnLine performance over SE (at least in the simplest analysis). Raw disk access helps too, but only if you are doing a lot of i/o relative to processing. Again, keep in mind that OnLine is doing a bit more work to achieve the same end as SE (for example, physical logging, an OnLine consistency/recovery mechanism, is not present at all in SE). This added work cost gets amortized over higher user counts, to the point where it becomes a benefit. Also consider shared memory buffering. If two users want the same data, one of them causes the data to be read from disk into shared memory. The second user can just read it directly from shared memory. So the i/o cost for such an operation for one user is X, that same operation for two users is X/2, and so on. As the user count increases, the cost of that i/o for any single user gets smaller. With SE, each user pays cost X, regardless of how many users there are (and when updates are added into the equation, the costs increase considerably for SE, but very little for OnLine). > 3) How does a person measure this factor on his active system? How > can I say with confidence that at my shop X = 4.63? Have your benchmark time operations against the database for each user. For example, perform inserts into the table and time a number of inserts for each user. This gives you inserts/second. Run 1 user, 2 users, etc. For multi-user runs, sum the resulting inserts/second. Perform the tests on OnLine and SE. You can use selects (count records fetched), updates, deletes, etc. Compare the results. Unless you have your OnLine system tuned extremely poorly, you will no doubt find that as the user count increases, SE performs worse while OnLine performs better. > 4) What is the break point? At what point do the performance gains > that OnLine brings make up for its overhead costs? i.e. When X > 2. Depends on the application, tuning, CPU, etc. etc. For an example, on an RS6000 running a more-or-less tpc-B benchmark, an untuned OnLine system peaked (for me) at about 25 users. This means that after 25, the performance started to drop. Tuning the machine and OnLine could have increased that substantially (esp. since I had one disk for everything), but the purpose of that exercise was to see what "out of the box" performance looked like. You number will depend on many different variables. Dave -- Disclaimer: These opinions are not those of Informix Software, Inc. ************************************************************************** "I look back with some satisfaction on what an idiot I was when I was 25, but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney