memory and concurrent users

  • Greetings,

    Boss asked me a hypothetical question of 'How would I configure a SQL server to handle up to 500 concurrent users?' So after scratching my head a little bit I told him I would find out and get back to him.

    So... I'm not going to ask for a direct answer because its probably huge, but if someone could possibly toss a whitepaper link or somesuch at me that would be appreciated. I'm going to poke around myself and see if I can figure out things also but if anyone knows of something good, that would be great.

    Regards,

    Chris

    p.s.

    sheesh, the SQL license alone is gonna be a wad'o'cash 😐

  • With that many users, take a look at the per server license - yep! It's a wad of cash too, but not as bad a per seat.

    Take a look in BOL (Books Online) under memory usage. It identifies the amount used by various system objects, including user connections.

    Guarddata-

  • Hi there,

    I have been looking thru the BOL and I cannot anything definitive that says something along the lines of 'its recommended that you have at least <x> memory per concurrent user'

    I could just as readily pick some arbitrary number like 4GB of memory but I need to justify how I came to that number.

    Thanks,

    Chris

    p.s.

    licensing is just fugly... need to read the legal jargon but per server is defintally the route, just need to see now if its per processor... small difference between 20k and 80k on a quadprocessor machine.

    p.p.s

    mk:@MSITStore:C:\Program%20Files\Microsoft%20SQL%20Server\80\Tools\Books\architec.chm::/8_ar_ts_1o4z.htm

    funny how 'memory connection users' and 'user connection memory' can return 2 different results. 12KB+(3*<Network Packet Size(4)>)^3

    500users = 1429MB of memory

    Edited by - CTKlein on 07/14/2003 9:08:42 PM

  • Previous versions used to say (I think) 17KB per user. I think the formula is simply 12KB + (3 * Network Packet Size). I know it looks like that is taken to the third power, but believe that is a footnote mark. Meaning, generally, 24 KB per user. That means 12 MB total for 500 concurrent users.

    It has been our experience that the volume of data plays a bigger part in requirements than does the number of users. As long as you are running a version that can be upgraded, I would start with 2 GB. 90% of our installations have never needed to go beyond that.

    Guarddata-

  • Hi there!

    Thanks for the info. Guess that being a footnote and not CUBED makes the number more manageable. 🙂

    Regards,

    Chris

  • SQL Server Licensing is per processor, not per server even if you're going to downgrade to 7.0 which does make a big difference on a quad processor system.

    This is probably a topic for another thread, but I wonder what (other than the sheer desire to increase profits) drove Microsoft to go to the per processor scheme and shelve the per server one. They're taking this approach with more and more products now and IMHO it places an onerous burdeon on budget restrained (read us) and smaller companies that want to keep their hardware and software up to date. I also wonder how many companies will now base their hardware purchasing decisions on this policy. All other things being equal, I'm now more likely to purchase a dual processor system than a quad because I'm looking at another $40k that will be going to Microsoft if I do.

    Regards,

    Sandman

    My hovercraft is full of eels.

  • Wow! For a minute I thought you actually believed that Microsoft has desires for something other than "sheer profit". I don't want to start a flame so I'll just agree that it seems to be much better for us to have a "per server" license. Trouble is always with small companies, though. If they did that, the per server cost would still be too high for us.

    Guarddata-

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply