Frequently Asked Questions about Exchange Load Generator
Topic Last Modified: 2008-02-22
This topic contains answers to frequently asked questions about Exchange Load Generator, including how to obtain the latest version of the tool.
A: Download the latest 32-bit or 64-bit version of Exchange Load Generator from Tools for Exchange Server 2007.
A: Exchange Load Generator throws SwordfishExceptionTooMuchLoad when the number of unfinished tasks, including those in the queue and those being executed, is greater than 1.5 times the number of users. It occurs because tasks are dispatched at a faster rate than they are being executed. Either the server cannot keep up or something is causing really high latency, such as network issues. The following performance counters show how fast tasks are dispatched and completed: Exchange Load Generator Engine\Task Interval, Exchange Load Generator Engine\Task Completed/sec, and Exchange Load Generator Engine\Task Dispatched/sec.
Exchange Load Generator is designed to give up if the task queue length becomes too high. This prevents Exchange Load Generator from experiencing memory issues because of a very large task queue and enables you to verify that there is a problem that has to be investigated sooner instead of later.
To avoid this exception, first, make sure that there is no server side problem of slowing down task execution. If the server performs normally, you can either adjust the task frequency so that the tasks are dispatched at a rate at which they can actually be executed, or use stress mode. Stress mode just executes tasks as quickly as possible based on how quickly tasks are completing.
A: Exchange Load Generator dispatches tasks at a certain rate, which is calculated by this formula:
(simulated day length) / (total number of tasks need to be run during a simulated day across all the user groups)
For each user group, the number of tasks to be run = number of users * number of tasks defined by action profile.
Based on this calculation, you can adjust the task dispatch rate by changing the simulate day length or the task action count in action profile or number of users.
A: The Exchange Load Generator report would indicate that a simulation failed if the following condition was not met.
The actual run length must meet the following formula:
“scheduled run length” <= “actual run length” <= “scheduled run length” + EngineStopTimeOutInSecs.
You can customize EngineStopTimeOutInSecs through the configuration file. By default, this value is 5 minutes, which means the engine should be shut down within 5 minutes.
A: If there is an exception thrown while executing tasks, Exchange Load Generator will catch it and log it if logging is enabled. By setting RethrowTaskExceptions to true, you are telling Exchange Load Generator to rethrow the task exceptions. Meanwhile, you will have to set StopOnTaskExceptionThreshold to a nonzero value so that when the exceptions thrown hit this threshold, it will be thrown.
You will want to set RethrowTaskExceptions to true if you are an API user and want to catch those exceptions. You have options to implement your own UnhandledExceptionEventHandler and register it with TaskEngine.UnhandledException. If you are a non-API user, see the next Question for what will occur if you set RethrowTaskExceptions to true.
A: Most likely you have RethrowTaskExceptions set to true. When the exceptions hit the StopOnTaskExceptionThreshold, it will rethrow the exception, and it goes unhandled. The life of the process is then controlled by the registry keys HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\DbgJITDebugLaunchSetting and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug when managed exceptions become native after being rethrown.
For detailed information about this, see Enabling JIT-attach Debugging (http://go.microsoft.com/fwlink/?LinkId=91845) and Microsoft Knowledge Base article 103861, "INFO: Choosing the Debugger That the System Will Spawn" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=103861).
If you have Exchange Load Generator logging enabled, you can also check the log for a list of exceptions that have been thrown.
A: Exchange Load Generator has two types of user interface. With LoadGenWin.exe (the graphical user interface), there is a wizard page for you to define how many users to create for each mailbox database, and it will create new users if there are not enough existing ones.
With LoadGenCmd.exe (Console), there is no command-line option with which to create users. Users have to be created before running mailbox initialization or simulation.
A: Exchange Load Generator fills the mailbox in much the same way as LoadSim. You can configure how many items to create in a certain folder through the <MailboxStoreProfile> tag within the Exchange Load Generator configuration file. However, these configurations are not exposed through the user interface so if you are using LoadGenWin, after creating users and defining user groups, you will have to save the configuration file and manually edit it if you want to use a custom <MailboxStoreProfile> tag. After editing, you will need to reload it from the “Start a new test” page for Exchange Load Generator to pick up the custom settings.
A: Standard guidance for index or catalog size is 5 to 10% of the database size. Because of the limited message set in Exchange Load Generator, we recommend that you allocate 25% of the database size to accommodate catalog headroom. For additional information about content indexing storage requirements, see Mailbox Server Storage Design (http://go.microsoft.com/fwlink/?linkid=106217).
A: It can be done by using a “concurrency profile” which lets you specify what percentage of users to be used in simulation during a certain period. By default, the concurrency profile has only one <ConcurrencyListEntry> tag which has 100% concurrency. This means it will run 100% users. However, you can edit the default <ConcurrencyListEntry> tag or create an additional <ConcurrencyListEntry> tag with a custom percentage. See the following example in which 100% users will be run during the first four hours, and only 60% of users will be run during the second four hours.
<Label>4 hours at 100%</Label>
<Label>4 hours at 60%</Label>
A: A successful connection requires that you can ping the target forest from the Exchange Load Generator client. Try the command “ping <targetforest>” to make sure that it is reachable. If it is not reachable, you can either substitute with the domain controller name if you can reach domain controller or you have fix it with your domain name server.
A: Any of these will work. But do not type the master client if you do not also intend it to be a remote load generator. The same applies if you edit the <RemoteProfile> tag directly in the configuration file. Before you run simulation in remote mode, you need to start LoadGenRemote service on the remote clients. You can do this by running “net start loadgenremote”, or from “administrative tools”->“services” window.
A: When you run stress mode against Exchange 2003 (SP1 or later versions) mailbox servers using more than 32 Exchange Load Generator servers, you will hit a MAPI session limit. Exchange Server 2003 SP1 imposes a restriction on the number of allowed MAPI sessions per user. By default, the maximum is 32 sessions.
On the Exchange servers you will see the following event in the event log:
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9646
Closing Mapi session "/o=Organization/ou=Administrative Group/cn=Recipients/cn=Recipient" because it exceeded the maximum of 32 objects of type "session".
In the Exchange Load Generator log, you will see the following exception:
Engine.General Critical: 0 : 4/17/2007 12:19:27 PM -- Caught exception in executeTaskStub: Microsoft.Mapi.MapiExceptionSessionLimit: MapiExceptionSessionLimit: Unable to make connection to the server. (hr=0x80040112, ec=1246)
However, you can change the MAPI session limit by modifying a registry key. For more information about MAPI session limits, see the Microsoft Knowledge Base article 842022, "Event ID 9646 is logged in the application event log of your Exchange Server 2003 computer when a client opens many MAPI sessions" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=842022). See the following procedure for changing the registry subkey.
|Incorrectly editing the registry can cause serious problems that may require that you reinstall the operating system. Problems that result from editing the registry incorrectly may be unable to be resolved. Before editing the registry, back up any valuable data.|
Start Registry Editor.
Locate, and then click to select the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services|MSExchangeIS\ParametersSystem.
If the Maximum Allowed Sessions Per User does not exist, do the following:
On the Edit menu, point to New, and then select DWORD Value.
Type Maximum Allowed Sessions Per User as the entry names, and then press Enter.
- On the Edit menu, point to New, and then select DWORD Value.
Right-click Maximum Allowed Sessions Per User, and then click Modify.
Click Decimal, type the value that you want to set in the Value data box, and then click OK.
Exit Registry Editor.