Troubleshooting the Site Hierarchy Design
for Better Performance

As you test your pilot project, you might identify site hierarchy or hardware problems that require troubleshooting. After you identify and correct any such problems, you are ready to re-run the tests. Testing and troubleshooting are iterative processes that can be repeated as long as a site does not meet the performance goals set during the initial planning stages.

The load on an SMS site or client frequently varies between idle and busy. A constantly busy computer is about as uncommon as a constantly idle site. Therefore, to interpret how your system is functioning, you must not only wait for hardware or system failures — you must also carefully investigate how your computer is working. Understanding where problems are likely to arise requires practice. Once you are familiar with the log files, all of the SMS and Windows NT performance tools and the performance issues, you can more quickly identify and resolve many of the issues described in the following sections.

Burst and Recovery

Many SMS processes generate “bursts” of information, loading up SMS inboxes with information that is processed in a timely manner. However, if your computer cannot process this information, or if it cannot process the total amount of files that will be generated at one time during bursts, you can have a serious performance issue. Be sure that you watch for burst and recovery situations that might overwhelm your hardware.

Bursts might occur during the following situations:

• Whenever you have a scheduled item that occurs at a specific time. For example:
  • If you schedule an advertisement to run at a specific time for all clients in the site, a burst of status messages is likely.
  • If you schedule hardware or software inventory to run at the same time on all clients in the site, a burst of MIF files is possible.
  • If you schedule a particular discovery method to run at a particular time, a burst of DDRs is possible.
  • If the site needs to perform a resynchronization operation, a burst of full MIFs from clients in the site is likely.
• During operations that tend to occur during certain times of the day. For example, when employees log on to their computers in the morning, a burst of advertisement status messages, DDRs resulting from logon discovery, and hardware and software inventory files.

Total Time

The total time it takes for your computer to process files is an important performance metric. For example, the time it takes for a client to take hardware inventory plus the time it takes for the hardware inventory file to reach the SMS site database would be the total time for inventory. When testing your pilot project, you should take total time measurements for every type of process on a regular basis.

One basic operation that you should monitor on the site server is the total time that it takes the server to process objects, such as DDRs and MIF files. To do so, simply locate the server component that processes the object that you are interested in and review the time stamps in the corresponding log file to determine the length of time it took to process individual objects.

It is important to consider that using this method to monitor processing time can be somewhat misleading, because it’s not obvious what other processing tasks the server might be performing during that interval. The processing of many SMS objects simultaneously by the server will affect the time required to process individual objects.