Slashdot Mirror


Testing Pre-Production Servers Accurately?

An anonymous reader asks: "Having been granted a 90-day demo enclosure of new blade servers from a major vendor the question I find myself asking is: On a limited budget, how does one simulate 1000+ attached clients and the activity of those clients? We're a K-12 school district and our current servers don't keep up with all the roaming-profile abuse from our Windows workstations. Are there tools or tricks available to simulate load on Netware/Linux servers? The user groups around here usually answer this question with 'Get some workstations for a test lab!', there's got to be a less expensive option, right? Can we leverage our existing client populous to achieve our goal, without interrupting or changing the quality of service at the desktop, substantially?"

1 of 48 comments (clear)

  1. Simple answer: don't use roaming profiles... by Anonymous Coward · · Score: 1, Insightful
    I work for a high school district and roaming profiles are nothing but trouble. I've found that it works far better to just not use roaming profiles at all. Reasons for this are:
    1. Roaming profile become enormous. Roaming profiles would often grow to over 20 MB. A single file doesn't take long to copy, but roaming profiles consist of many smaller files, often times over 5,000 files. 20 MB divided up into 5,000 files takes a significant amount of time to copy. In a school setting where someone could log on to 8 different computers throughout the day, 2-3 minute login times (time spent copying the roaming profile) are unacceptable.
    2. Roaming profiles allow for malware. If you don't save any user settings, malware is made pretty much non-existent.
    3. Roaming profiles would frequently become corrupted. This would lead to the inability for users to log on unless a network administrator would delete their profile so that it would just grab a copy of the default profile. Down time for the users is not good.
    4. Roaming profiles lead to more problems with users changing program settings and then not being able to get something to work. If you don't save any of these settings and instead always have the users use a clean default profile, problems with incorrect settings are greatly reduced. Generally these problems require interaction with the user because they are not easily reproducable problems since all of the roaming profiles are different.
    5. To some degree, Windows XP, 2000, and 2003 profiles are incompatible. If you use multiple of these, you are likely to run into some problems as each user only gets one profile.

    I really could go on and on with problems they cause. They have but one sole purpose which is to save user settings. While this in itself is a very strong reason, all of the negative side-effects of using them outweighs their benefit. Over time you will find yourself cutting more and more out of the user profiles in order to fix the problems they cause. For example, to reduce the size of the profiles, you can have certain subdirectories ignored. This works great, but by the time you eliminate the problem directories to reduce the number of files in the profile, you realize that much of the value of roaming profiles is being eliminated just to make them work decently. In the end it's just better to avoid them.

    This even applies to situations where each user typically uses only a single PC, an environment which is very different from a typical school. In those environments, what purpose does a roaming profile serve? If the users don't roam, you might as well just use local profiles stored on the workstations themselves.