Microsoft Transaction Server (MTS) is a remarkable product. To appreciate MTS's functionality, consider how the complexity of an application increases as the number of users it must support increases. An application that supports hundreds, thousands, or tens of thousands of users must include support for multithreading, database connection management, and load balancing. MTS makes these necessary features easy to add to applications, so product developers can focus on their applications' core functionality without worrying about scalability. (For an overview of MTS, see Ken Spencer and Charles Caison, "Administering MTS," March 1998.)
However, if you don't configure MTS properly, it can overburden your system resources. Fortunately, you can adjust a few MTS settings and plan your MTS implementation to optimize MTS performance on your Windows NT server.
Adjust MTS Settings
MTS comes as part of the Microsoft Windows NT 4.0 Option Pack, and it runs as part of the Microsoft Management Console (MMC). You administer, distribute, install, deploy, and test MTS applications through the MTS Explorer. The MTS Explorer's easy-to-use interface is similar to the NT Explorer interface: MTS Explorer displays a tree view (the hierarchy pane) on the left and the contents of the item you select in the hierarchy pane on the right. After you install the components that make up an MTS application, you can adjust the MTS Explorer's View and Log settings to minimize the components' use of system resources.
View settings. MTS reports information about running components through transaction windows. The Transaction List window displays information about the current transactions of components on a specific computer. The Transaction Statistics window displays current and cumulative information about transactions that MTS's distributed transaction coordinator (DTC) services. The Trace Messages window reports warnings and errors and displays other informational messages about the status of various MTS activities. You can adjust settings for all three transaction windows in the My Computer Properties dialog box under the Computers folder in the MTS Explorer. Icons in the Computers folder represent the computers that you can configure packages on. (A package is a group of MTS components that run as an application in one process.) Right-click the My Computer icon, select Properties, then select the Advanced tab, as Screen 1 shows.
The Display Refresh property specifies the rate at which MTS updates the transaction windows. Display Refresh rates can range from 1 second to 20 seconds. The Transactions Shown property specifies the length of time that a transaction is active before its information appears in the transaction windows. If you select Very Old, the transaction windows display information only about transactions that have been active for 5 minutes. If you select New + Old, the transaction windows display information about all transactions that have been active for more than 1 second. The Trace property specifies the types of trace messages MTS sends to the Trace Messages window. You can set the Trace slider to send no trace information (the slider's left position), all trace information (its right position), or specific types of trace information (only error traces; both error and warning traces; or error, warning, and informational traces).
Each of these settings relates to an auxiliary MTS activity that increases MTS's use of system resources. Monitoring a process in MTS degrades the performance of that process, because frequent monitor updates increase administrative overhead on running transactions. MTS must divide its time and resources between performing auxiliary activities and running the components that make up your MTS applications. Therefore, if you monitor a process less, you can expect better performance (but less-current information in the transaction windows). For example, when you move the Display Refresh slider to the left, you tell MTS to refresh the transaction windows less often, which frees more MTS time and processing power for your applications.
By adjusting the View settings, you can reduce MTS stress on the network and increase MTS performance, especially when components run on one server and MTS reports information to another server. To get the highest level of performance from MTS, set Display Refresh to Infrequently, Transactions Shown to Very Old, and Trace to Less. These settings will focus MTS resources on running your applications, rather than collecting and displaying status information.
Log settings. The size of the MTS DTC log file also affects MTS's performance. You set the log file size using the Capacity slider in Screen 1. The larger the log file, the more transactions MTS can run concurrently. The fact that MTS runs transactions concurrently can be a performance benefit, but your server can run only a limited number of simultaneous transactions efficiently. The maximum size of the MTS DTC log file is 512MB on NT and 64MB on Windows 95. By setting the Log Size to 5MB or less, you can prevent MTS from overburdening your system and maximize your system's performance. If you want to save log information for an extended period, you can back up the file to tape or write it to a database.
Options. After you adjust the settings on the Advanced tab, select the Options tab. The Transaction Timeout property on the Options tab tells MTS how much time to let transactions run before terminating them. You want MTS to terminate a transaction if a problem causes the transaction to stop responding. Because MTS can roll back transactions, MTS can terminate transactions gracefully through code that uses MTS-specific calls. Your developers need to include MTS-specific calls in your applications to ensure that the applications perform well.
Changing the Transaction Timeout property doesn't enhance application performance under most conditions, but it helps ensure that your applications continue to perform by terminating transactions that stop responding. Transaction Timeout values can range from 0 to 3600 seconds (1 hour). The default setting of 60 seconds is satisfactory for most applications, but if your transactions are operation-intensive and require 30 seconds to 45 seconds to execute, you need to increase the Transaction Timeout value. Identify the transaction that takes the most time to execute and multiply its execution time by three. Set the Transaction Timeout value to that number.
Shut Down Server Processes
Sometimes you need to manually shut down an MTS application. For example, if an application becomes unstable, processes might malfunction or stop responding. Often, you can remedy the problem by forcing a shutdown of the offending processes. You also need to shut down an MTS application if you want to move a component DLL from one folder to another and run the DLL from the new location, or if a developer rebuilds a component and wants to copy the new version over the old version.
In MTS 2.0, you can shut down an individual MTS process running on a specific computer by opening the Packages Installed folder under the icon for the computer you want to stop the process on. Right-click the package you want to stop processes for, and select Shut Down from the context menu.
If you don't use MTS 2.0, or if more than one package has become unstable, you can shut down all the server's processes at once. Shutting down all of a server's processes terminates its active MTS transactions, resets the MTS applications, and recovers server resources. Within the MTS Explorer hierarchy pane, select the computer you want to shut down processes for, and select Shut Down Server Processes from the Action menu, as Screen 2 shows. You can also shut down server processes from the command line: Navigate to your server's system32 folder, which NT usually stores at C:\winnt\system32, and type
You will receive a message stating that the application server processes are stopping.
After you stop the MTS processes, you can run your client applications as usual. You don't need to manually restart the processes you stop; your client application will automatically restart them.
Refresh Server Component Information
The NT Registry and a data store called the MTS Catalog store information about MTS components. MTS uses this information to activate and run the components. Some component information appears in both places. If a piece of information that MTS stores in both places changes in one place but not the other, the application associated with the component will malfunction.
Some applications, such as Visual Basic (VB), can rewrite Registry information for an MTS component. For example, when a developer updates and rebuilds a component, VB rewrites component information to the Registry but not to the MTS Catalog.
If your component's Registry information becomes inaccurate, you must refresh it. You can assume that you don't need to refresh component information if your MTS application works properly. However, if an application begins to malfunction after a developer has altered its components, you need to refresh the components' Registry information.
You can refresh a component's Registry information from the MTS Explorer, the command line, or the VB add-in that comes as an optional MTS component in the Option Pack. To refresh the settings from the MTS Explorer, open the Computers folder in the MTS hierarchy pane. Select the computer that you want to refresh components on, and select Refresh All Components from the Action menu.
To refresh settings from the command line, open a command prompt and navigate to your system's MTS installation folder (usually C:\Program Files\Mts), as Screen 3 shows. Type
on the command line. MTS will display a message confirming that it has refreshed the components registered on your computer.
To refresh component settings through the VB add-in, you must install the add-in, then select Transaction Server AddIn for VB 5.0 from the list of add-ins within the VB integrated development environment. The Transaction Server add-in will automatically refresh your MTS components when you rebuild them.
Balance the Network Load
If your applications must support several hundred users, you need to distribute your MTS components to multiple servers across your network to achieve a balanced load. For example, if components A, B, and C work together as one MTS application, you might install component A on Server 1, component B on Server 2, and component C on Server 3. If all three servers run MTS, the three components can work together as one application. Your system works more efficiently if multiple servers divide the workload, because this load balancing prevents an application from overburdening one server.
Another benefit of installing components on multiple servers is increased reliability of the MTS application across the network. You can install all three components on Server 1 and Server 2, and then run components A and B on Server 1 and component C on Server 2. Such an installation spreads the network load between the two machines. In addition, the duplicate installation provides redundancy that makes your application more reliable. If either server goes down, you can use the MTS Explorer to quickly reconfigure the application to use all three components on the functioning server until the disabled server is back online. Microsoft has announced that it will include dynamic load balancing in future versions of MTS, which means MTS will automatically run each component on the server that is least busy.
To enable multiple MTS components running on multiple servers to work together as one MTS application, you must associate all the components with the MTS server that the application will run on. The MTS Explorer on that server must list each component under an icon representing its server: Components on the local server appear in the Installed Components folder, and components on other servers appear in the Remote Components folder. You associate all your components with the server that the application will run on by distributing information about each component and its supporting files to that server.
You can distribute component information to servers across your network using two methods: First, the source server (the server that the component will run on) can push the information to the destination server (the server that doesn't have the component). Second, the destination server can pull the information from the source server. Both methods let client software anywhere on the network use the distributed components as if they were executing on the destination server, although the components run only on the source server. Components always run on the computer on which you added them to a package. Component pushing and pulling copies information and supporting files that destination servers need to access the component on the source server.
Figure 1 shows three MTS servers and a network client. Component A runs on Server 1. Server 1 pushes component A information to Server 3. Component B runs on Server 2. Server 3 pulls component B information from Server 2. Component C runs on Server 3. All three components work together as an application that the client accesses from Server 3 via the distributed component object model (DCOM).
To prepare your system to push and pull component information, you must perform a preliminary setup. You must place each component you want to push or pull in a shared folder on its source server. The share will store and deliver DLLs and type library files. The share must grant Read rights to the account that you will use to log on to the machines to perform the push or pull. MTS will automatically locate the share.
In addition, you must make sure that each source and destination server is running MTS and has icons representing the other servers in its MTS Explorer Computers folder. For example, Server 1 in Figure 1 must list My Computer, Server 2, and Server 3 in its Computers folder. Likewise, Server 2 must list My Computer, Server 1, and Server 3 in its Computers folder. To add icons representing the other computers, select the Computers folder in the MTS Explorer. Select New, Computer from the Action menu, and enter the computer's name (without the Uniform Naming Convention--UNC--backslashes).
Finally, you must open the Packages Installed folder for the source server. Look at the System package properties to determine whether the package has administrative security enabled. You need to enable administrative security on the System package if you plan to use component push. (For information about enabling administrative security, see the sidebar "MTS Security," page 158.) If the System package has administrative security enabled, make sure that the NT account that the destination computer's System package runs under is a member of the Reader or Administrator role for the source server's System package. When you have completed this preliminary setup, you're ready to configure your component push or pull.
Set up component push on the source server. The first step to enabling component push is to make sure that the NT user account that you use to log on to the source server is a member of the MTS Administrator role for the System package on the destination server. Then, expand the hierarchy beneath the icon representing the destination server. Open the Remote Components folder, because the component will execute remotely from the perspective of the destination server. Select New from the Action menu. Use the Remote Computer drop-down list box to select the source server. Then use the Package drop-down list box to select the package on the source computer that contains the component you want to push information for. Select the component from the Available Components list box, and click Add to move the component to the Components to Configure list box. If you select the Details check box, the Components to Configure box will show information about the remote computer, package, and path for DLLs.
Repeat these steps for every component you want to push. Click OK when you finish. MTS will push component information from the source server to the destination server. The destination server will then have an icon under the Remote Components folder in the MTS Explorer for each pushed component. Client applications will be able to access the components as if they were running on the destination server.
Set up component pull on the destination server. In the MTS Explorer, open the Remote Components folder under the My Computer icon in the Computers folder, because the components will execute remotely from the perspective of the destination server. Select New from the Action menu. In the dialog box that appears, select the remote computer and package that contain the component you want to pull. From the Available Components list, select the component that you want to pull. Click Add to add the component to the Components to Configure list box. Click OK.
Repeat these steps for every component you want to pull. When you finish, click OK to close the Remote Components dialog box. MTS will pull component information from the source server to the destination server, and client applications will be able to access the components as if they were running on the destination server.
Keep Your System Running Smoothly
Downloading and installing the most current MTS service packs (SPs) helps optimize performance. SPs add new features and fix problems in the system. However, SPs occasionally introduce bugs to the system.
If I have a system that works, I usually wait until a few weeks after the SP's release before I install it. I watch newsgroups for reports of problems with the SP. If I don't hear of problems with the SP, I install it. However, I make exceptions to this rule when my system urgently needs some functionality that the SP can fix. I always let the setup program create an uninstall directory. You can find MTS SPs at http://premium.microsoft.com/support/transaction.
MTS will soon be an indispensable tool for systems administrators. As NT becomes an enterprise operating system (OS), it must run software that can support organizations. In addition, more and more Internet Service Providers (ISPs) are running NT with Internet Information Server (IIS) and using MTS to run Web applications that support many Internet users.
Fortunately, MTS is surprisingly easy to administer. The MTS Explorer lets you manage servers and applications through an easy-to-use hierarchy. Use this article's tips to keep your MTS servers running enterprise applications efficiently and reliably to support your business' needs.