I recently worked with a client on a consolidation project and want to share some observations. Their strategy was to build the new servers and, before they moved users to the servers, wanted to test the performance of the central servers. We used the Server.Load capability that comes with Domino. This has been around for awhile (I worked with it's predecessor, NotesBench, 15 years ago). It is an engine that has several scripts that can be used to simulate thousands of users. It has two basic modes - initialize the environment and running the workload. The initialization phase is key. After all, simulating several hundred users is pretty useless. The challenge of several thousand users is creating that many mail files and populating them with data.
Here is the critical take-away - when running the workload tests, there is a built in delay between each user session which makes sense. Aside from me, I don't know many users that go flat out all the time. And this delay is a random number. The problem is during the initialization phase, you are not collecting statistics, so you don't need to 'simulate' real users, just create the mail files. But this delay can be up to 15 minutes. So, doing the math, creating several thousand user mail files with up to 15 minutes between each user can take days (and yes, do use multiple workstations to attack the server). So, please, help yourself and reduce this delay. What you need to do is take the built-in initialization script, copy to the clipboard, paste into Notepad, CHANGE THE DELAY, and save the custom script. Here are the first few lines
* N85 Mail Initialization Workload
* Script to initialize databases for NotesBench N85Mail
* Pause a random interval (0-15 min) so multiple processes are staggered well.
Remove at least three zeros from that pause line. You will be so much happier with the results.
A couple of other comments about server consolidation projects. A good strategy is to bring up a brand new server. This means that users will have to re-point their mail files to the new server. Consider renting a tool like Marvel Client from Panagenda to make this change easier.
Secondly, why 'consolidate' a database that is not being used by a person? The problem with the activity number in the Catalog is that it considers any activity as using the database. This activity could be mail being deposited in a database or a scheduled agent running against the database. Neither of these 'activities' represent a person. So, while you are ordering the new hardware, consider an approach offered by someone like Inner Ring Solutions. They have a tool which identify's who is using a database; meaning server, agent, or user; and how often. So, a database that is not used by users is a candidate to be retired, not consolidated. Likewise, a database (not mail file) used by 10 or less users could probably be replaced with some other solution, or be advertised to users as an underutilized benefit. My experience from my days at Teamstudio is that up to 75% of databases in a long standing Notes environment can be deleted because they are not being used. A large part of this inactivity can be easily identified by looking at you Catalog. I have a Catalog tool that will identify such things as databases (not templates) with no documents. Databases with 'test' in the title or file name. Databases with a year in the title or file name (think 1998 receipts).
If you want more information on your server consolidation project, contact me. I've been there and done that before, so I can help reduce the pain of your project.