home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8707 < prev    next >
Encoding:
Text File  |  1992-12-29  |  3.1 KB  |  69 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!agate!rsoft!mindlink!a269
  3. From: Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg)
  4. Subject: Re: 500'000 records - who does best?
  5. Organization: MIND LINK! - British Columbia, Canada
  6. Date: Tue, 29 Dec 1992 19:47:16 GMT
  7. Message-ID: <18996@mindlink.bc.ca>
  8. Sender: news@deep.rsoft.bc.ca (Usenet)
  9. Lines: 58
  10.  
  11. > Mark Baldridge writes:
  12. > >It isn't the number of users, it's the basic size of the tables.
  13. > >One of our clients has pushed a table to 900k rows, 250Mb on an RS/6000
  14. > >with 50Mb memory dedicated to the Sybase server. Working with it
  15. > >feels like retiling the bathroom while an elephant uses the john.
  16. >
  17. > Maybe I am missing something, but we routinely have customers with 250 to
  18. > 800
  19. > megabyte tables and 200-300 users on RS6000s.  Earlier this year, we did a
  20. > benchmark with 1600 users, all with under one or two (I do not remember
  21. > now)
  22. > second response time.  The benchmark was to ensure that the fully
  23. > configured
  24. > system could handle the expected 2500 users.
  25. >
  26. > We use uniVerse.
  27.  
  28. Pardon my ignorance as to what uniVerse is.
  29.  
  30. I suspect we are talking about different kinds of apps here, in which
  31. case you may find Sybase or Oracle or what-have-you to be plenty good
  32. (but perhaps you could expand on what uniVerse is or does). Sorry,
  33. from your original posting I thought you were having a problem.
  34.  
  35. "one or two ... second response time" suggests that your client users
  36. are perform transactions on a limited number of rows, and from the numbers
  37. I suspect that your chief concern is TPS. B-tree or (even better) hashed
  38. access time doesn't rise dramatically with table size, and you probably
  39. aren't even really interested in clustering and contiguous allocation.
  40. Furthermore, I'd wager that database changes once the system is in production
  41. are not a major concern, either.
  42.  
  43. In any case, I'm impressed by anything
  44. running on a Unix box, presumably with TCP/IP connections, actually
  45. handling 1600 or more concurrent requests, which amounts to 1K TPS
  46. or better --- assuming that is what you indeed mean by "1600 users".
  47. Our systems "handle" a few hundred users, but with only a couple dozen
  48. connected at one time :-).
  49.  
  50. The kind of transactions that concern me are high-activity requests,
  51. i.e., where nearly every transaction involves a significant chunk
  52. of the table. Our servers receive remote updates over a WAN that
  53. are EACH typically 1-10k rows; and alterations to the running system
  54. occur on a monthly basis, typically requiring all rows to be updated
  55. (this is the way the apparel business works).
  56.  
  57. So, we may well be talking about completely different problem domains.
  58. I'd be interested in hearing more about the specifics of yours.
  59. Did I miss it when you mentioned exactly what these 30K records contain?
  60.  
  61.  
  62. --
  63. Mischa Sandberg ... Mischa_Sandberg@mindlink.bc.ca
  64.                  or uunet!van-bc!rsoft!mindlink!Mischa_Sandberg
  65. *-*-*-*-*-*-*-*-*-*-*
  66. Engineers think equations are an approximation of reality.
  67. Physicists think reality is an approximation of the equations.
  68. Mathematicians never make the connection.
  69.