Before I continue, I’d like to state up front thatnothing in this article should be construed as casting Windows 2000 / COM+ in anegative light. On the contrary, I’ve seen pretty much across the boardperformance increases for reasonably constructed transactions.The particular application I’m about to present has pretty drasticallydeviated from the recommended guidelines for server application construction.Nonetheless, if you are working with such a design, you should be aware of theramifications. Although you may be meeting your target performance rate underNT4, you might very well experience a dramatic performance drop in the future,if the application is deployed under Win2K.

Transaction a unit of work. Not to be confused withMTS/COM+ database transactions. To be sure, an MTS/COM+ database transaction is a transaction. But not every transaction is an MTS/COM+ database transaction.

A client of mine asked me to take a look at a problemhe was experiencing when deploying his application to Windows 2000. The truthwas, the application was not all that responsive under Windows NT4 either. Aftertweaking and optimizing, drastically reducing VB string concatenation, andadjusting the code for efficient objectaccess we were able to meet our stated goal of handling a server load of 5 usertransactions per second,with pages returning in under 5 seconds. We all realized that this rate ofperformance was pretty poor and we resolved to dramatically re-architect for thenext release. No one was prepared though for the performance drop we experiencedwhen the application was deployed under Win2K. Suddenly pages were taking 45 90 seconds to return! Obviously some pretty drastic blocking was taking place.My client asked me to figure out what was happening.

The term object is often used somewhat ambiguously. For the purposes of this article, an object refers to a particular instance of a class at run-time.

It is often very difficult to calculate expected server load prior to actual system deployment. A handy spreadsheet which can help calculate server load based on user population, and projected activity patterns, can be downloaded from ftp://FPSNow.com/FPSNow/LoadCalc_xls.zip.

Looking through the reports from the Web ApplicationStress Tool, it was easy to spot the problem areas. All were pages which invokeda common component structure to fetch the data and render the page. My firstline of investigation was to trace exactly what classes were involved in thistransaction. Easy enough. Throw a switch and convert the Library package into aServer package. Request the page and watch which objects spin up. I observed 39 objects spinning away. 39 Objects! A pretty class heavyhierarchy, if you ask me. But the worst was yet to come.

After consulting with the developers, it turned outthat several of these classes were collections of other classes. Since thecollection was data driven no one could be sure just how many classes wereactually being instantiated at run time. I inserted some profiling code to logevery class instantiation to a file. We were all amazed at the results. Theobject hierarchy, which we had already determined was comprised of 39 separateclasses, actually created 378 instances of those various classes!

Well, here was something pretty radical to take a closer look at. AlthoughMicrosoft has done a good job of ensuring behavioral compatibility between theMTS and COM+ runtimes, the literature is pretty clear that COM+ is verydifferent internally, from MTS. I wrote a small driver utility to benchmarkclass instantiation under MTS and under COM+. The results are quiteenlightening.

You can download the benchmark utility fromftp://FPSNow.com/FPSNow/CCBench.zip. The zip file contains all the source files forthe server components, a Windows client driver, as well as an ASP script driver.

The benchmark utility is quite flexible and provides numerous options forclass instantiation. The server component can either be called by the Windowsclient driver, or by the included ASP script. As Don Box states early on in his House of COM article in the March 2000 issue of MSDN, ‘Betweenthe addition of a new apartment type and the integration of the Microsoft®Transaction Services (MTS) context model into core COM, the number of possibleconfiguration scenarios is mind-boggling’. Since you can download thesource code and run your own benchmarks, we’ll avoid presenting and comparinga mind-boggling number of cases here. We’ll stick to the basics.

For our first suite of benchmarks we’ll use the Windows driver just totest raw class creation and collection access. Of course, these numbers won’tdirectly map into a multi-user scenario where concurrency will be an issue.We’ll get into concurrency later on when we’ll use the Web ApplicationStress Tool to drive our ASP benchmark script.

First a few points about class creation and access. Both of the cases abovecreated a collection of 1000 objects. The second case on the right performed aCross-Tier creation request, meaning the Windows driver called in to the middletier for each and every class creation and object access. For this benchmark,both the driver and the middle tier classes were installed on the same server.Obviously, this degradation would be even more exaggerated if the Windows driverwas deployed remotely, across a hardware boundary from the middle tier, as isusually the case. You can see how this cross tier construct has a radicalnegative impact on performance for a tiered architecture.

You’ll see this performance degradation where the middle tier components aredeployed remotely from its clients, or where it is installed to MTS/COM+ on thesame machine as its clients. Where the DLL is installed locally with the driver,and is simply registered, but not configured in either MTS or COM+, you won’t notice any difference (I tested up to 10,000 objects). Of course, if the Windows driver would be accessing the components remotely, via DCOM, then you’d certainly see a performance difference due to network latency for each communication between the client and the server.

Therefore, in a tiered scenario, wherever possible, allowserver  processing to take placeindependently of its client. In other words, let the client pass in enoughinformation immediately, so that the server can perform the requested task andreturn the results to the client in a single transaction.

We won’t discuss cross tier performance any more in this article since inour context, and generally speaking in an n-tier scenario, the cross tierconstruct usually represents a deficient software architecture. All of thenumbers presented below are generated using the n-tier paradigm where the clientmakes a single call in to the server layer, all processing is performed by theserver, and the results are finally returned back to the client.

OK, here are the numbers for raw object creation and access. All tests weretested on the exact same hardware platform, a PentiumII 450Mhz, with 256 MegsRAM. For raw object creation I deployed both the Windows driver and the serverclasses on the same PC. Since all object creation and access takes place in theserver layer, during this operation the Windows driver is simply idling and notconsuming any significant resources. (Later when we get into concurrency tests,I’ll be driving the Web Application Stress Tool on a separate clientworkstation.) Here are the numbers to create and access a collection of 1,000objects:

Raw ObjectCreation Scenario

Wow! Do you see what I see?Under Windows 2000, using the Library defaults (that is, the defaults which arepre-set by creating a Library application and dragging in the CCBench DLL)object creation takes 33 times longer than it does under NT4 in a LibraryPackage! Now it is true that we were able to optimize the Win2K Library scenarioand see quite an improvement as shown below. We adjusted the followingdeclarative settings in an attempt to minimize object creation and accessoverhead. At the package level, set the security level to perform access checks only at the process level. At the component level, for all three components, disable transaction support, disable JIT, remove support for events and statistics, and disable synchronization support. Then for the Obj and ObjCol objects, specify that they must be activated in the caller’s context (colocation). The ObjWrapper component cannot be colocated since its caller is outside of the COM+ application. After applying these settings we saw the followingbenchmarks:

Object creation time hasimproved quite a bit. But still, even under this optimal scenario (which is onlypossible for non-JIT, non-transactional components), object creation under Win2K took 2