Measuring COM+ Performance

• Download source - 27.1 KB

Introduction

COM+ on different Microsoft Windows versions performs differently on the same machine. For example, COM+ on Windows Server 2012 performs worse than on Windows Server 2003. This tool helps to measure COM+ performance.

Background

In many applications, the business logic and data access layer runs in COM+ components. It is therefore important that these components perform well, as they significantly influence the overall performance of the application. COM+ and .NET are available on most Windows versions, and therefore porting COM+ applications can be done without changing the code. It would be desirable that performance also remains the same across the different Windows versions, but this is not the case.

This tool spawns several threads, and each thread reads a record from the database by calling a non-transactional COM+ component, and writes this record to the database by calling a transactional COM+ component. The performance is set to the amount of time required to do this procedure a certain amount of times, for example 1000 times. This tool also provides the described test without using COM+, as well as tests to read and write files.

Using the Code

Project ComPlusPerf

The Visual Studio 2010 project ComPlusPerf.vbproj is provided which contains the following items:

• ComPlusPerf.snk: Contains the strong name with which the assembly is signed. Assemblies that are registered in COM+ must be strong signed.
• Form1: The user interface to configure and run the tests
• ModSettings: The module to read and write user settings
• SQLDataAccessComPlusR: Non-transactional COM+ component to read and write to the database
• SQLDataAccessComPlusU: Transactional COM+ component to write to the database
• SQLDataAccessNormal: Class to read and write to the database, non COM+

Compiling and Registering

• Open ComPlusPerf.vbproj in Visual Studio 2010. Later versions of Visual Studio should also work.
• Build the project. This will create an assembly with target platform AnyCPU, that means it can be registered as well on 32 bit, as well as on 64 bit machines.
• For 32 bit machines, double-clicking on RegisterComPlusPerf.bat should register the assembly in COM+.
• For 64 bit machines, change in the first line of RegisterComPlusPerf.bat "Framework" to "Framework64".
• Executing in Start/Run comexp.msc should show the COM+ explorer, where you can see, if the component ComPlusPerf is installed.
• Depending on the security settings, you might have to set the identity of the COM+ component (right click on ComPlusPerf component, Properties/Tab Identity). The exception message: "COM+ was unable to talk to the Microsoft Distributed Transaction Coordinator", indicates, that a correct identity must be set.

Form Description

Double-click on bin/ComPlusPerf.exe. The following form appears:

• The listbox at the top of the form contains the different tests that can be run. On each iteration, the checked tests are executed. The following tests are provided:
  • DbNormalAdd: Adds a record to Table1 in the database using a normal component (non COM+). Table1 has 94 fields. The 56^th field is of type varchar(max) and is filled with 4000 characters.
  • DbNormalUpdate: Reads a record from the table specified in the property-grid's "Table name" field, updates the column, specified by the property-grid's "Column name" field, to the current date and time, and updates the record in the database using a normal component (non COM+).
  • DbComplusAdd: Like DbNormalAdd but using a COM+ component.
  • DbComplusUpdate: Like DbNormalUpdate but using a COM+ component.
  • SleepComplus: Calls a COM+ component which sleeps for the amount of time defined in the property-grid's "Milliseconds" field.
  • ReadFile: Reads the file given in the property-grid's "Path" field.
  • WriteFile: Writes the file given in the property-grid's "Path" field. The size of the file is specified by the property-grid's "Size" field.
• The property-grid in the middle of the form defines parameters to be used by the tests described above.
  • DB
    • Column name: The name of the column to update, must be a date column.
    • Connection string: The connection string to use to access the database. The user must have the right to drop and create tables, and select, insert and update records.
    • Start record nr: The table must have a column "Id". The tests will operate on the record nr defined by this value and upwards, for example if 1 tests will start from the first record, if 100, then tests will start at the 100^th record.
    • Table name: The table on which to run the tests. It must at least contain two columns: column Id of type int and primary key, column defined in the field "Column name" of type date.
  • Execute
    • Chunk size: Each thread takes a chunk of data to iterate on, and then takes the next chunk. The number of records in the chunk are given by this parameter.
    • Nr of iterations: The total number of iterations to be executed.
    • Nr of threads: The number of threads to run in parallel. At the beginning, each thread gets a chunk to work on. As soon as a thread has finished working with a chunk, it starts to work on the next chunk. The test ends, when all chunks have been processed, that means, all iterations have been completed.
  • File
    • Path: The file path to read or write
    • Size: The size of the file to write
  • Sleep Com+
    • Milliseconds: The number of milliseconds to sleep in the COM+ component.
  • Context menu: By right-clicking on the property-grid, a context-menu with the following items appears:
    • Table1 create: Creates tables Table1, Table1_Audit and a trigger for Table1 on the database given in the connection string. This table has 94 columns and is similar to a real-life case.
    • Get number of rows: Counts and displays the number of rows in the table defined in the property-grid.
    • Reset settings: Resets all values to the original settings.
  • The start button is at the bottom of the form. When the test starts, its text and functionality changes to that of a stop button.
  • The progress bar shows the percentage of iterations completed.
  • The label next to the progress bar shows the total amount of time in hours, minutes and seconds spent so far by the test.

Test

This program has been tested on Windows 7, Windows Server 2003 and Windows Server 2012. To run the program, follow these steps:

1. Run ComplusPerf.exe.
2. In the property grid, change the connection string to point to your test database on your SQL server.
3. On the property-grid, right-click and choose "Table1 create" from the context menu. This will create the table named Table1.
4. In the list-box, check DbNormalAdd and click on button Start. This will add as many records to Table1 as defined in the property-grid's "Nr of iterations" field.
5. On the property-grid, right-click and choose "Get number of records" from the context menu. This will display the number of records in the table defined in the property-grid's "Table name" field, which by default is Table1.
6. In the property grid, uncheck DbNormalAdd and check DbComplusUpdate and click on button Start. This will update in the table defined by the property-grid's "Table name field" as many records as defined in the property-grid's "Nr of iterations" field. The bottom right label indicates the test's run time.
7. You may also try the other tests, and you may change the execution parameters and see how the tests are performing with different number of threads.
8. If you change the table name, you will also experience a different performance. Small tables with few columns perform much better.

Results

A number of tests were run on two machines with 4 Intel(R) Xeon(R) CPU E5-4660 v2 @ 2.20 GHz processors, with 32GB of memory. One machine had Windows Server 2003 installed, and the other had Windows Server 2012 installed. On both machines, the assembly was registered with the 32 bit regsvcs. Some tests were run having registered the assembly with the 64 bit regsvcs. No big difference in performance was found between the 32 bit and 64 bit versions.

DbComplusUpdate

This test reads and writes 5000 records to the database with 10 and 100 threads respectively using COM+. On Windows Server 2012, additional tests were run with application pooling of 2, 4, and 10 respectively. The application pooling determines how many dllhost processes are created for each COM+ application. The results show that Windows Server 2012 is slower than 2003, but with application pooling of 2 and 4, performance improves significantly. The column seconds holds the test's run time, and the column diff holds the difference in percentage of Windows Server 2012 and Windows Server 2003.

DbNormalUpdate

This test is the same as the previous one, but without using COM+. In this case, Windows Server is again slightly slower, but not that much slower. This is an indication that mainly COM+ slows down on Windows Server 2012.

SleepComplus

In this test, a function is called on a COM+ component which sleeps for 10 milliseconds. Again, Windows Server 2012 is slower, and significantly slower with more threads, that means with more activated objects in COM+. This is an indication, that COM+ does not scale as well on Windows Server 2012 as on Windows Server 2003.

History

1. Tests for reading and updating one record in the database with and without COM+, and tests for reading and writing files