Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Object Creation Under Windows NT4 and Windows 2000

Do you have an application which is running sluggishly under Windows NT4 / MTS, not providing quite the performance you expect? Are you thinking about porting it to Windows 2000 / COM+ in order to achieve a performance boost? Be very careful. Depending on why your application is not performing up to speed under NT4, you may not experience any performance gain by migrating to Win2K. You might very well see a performance drop. A significant performance drop. In this article Joseph Geretz will show you all the do's and don'ts of the subtle art of object creation under Windows NT and 2000.

Before I continue, I’d like to state up front that nothing in this article should be construed as casting Windows 2000 / COM+ in a negative light. On the contrary, I’ve seen pretty much across the board performance increases for reasonably constructed transactions. The particular application I’m about to present has pretty drastically deviated from the recommended guidelines for server application construction. Nonetheless, if you are working with such a design, you should be aware of the ramifications. Although you may be meeting your target performance rate under NT4, 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 with MTS/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 problem he was experiencing when deploying his application to Windows 2000. The truth was, the application was not all that responsive under Windows NT4 either. After tweaking and optimizing, drastically reducing VB string concatenation, and adjusting the code for efficient object access we were able to meet our stated goal of handling a server load of 5 user transactions per second, with pages returning in under 5 seconds. We all realized that this rate of performance was pretty poor and we resolved to dramatically re-architect for the next release. No one was prepared though for the performance drop we experienced when 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 Application Stress Tool, it was easy to spot the problem areas. All were pages which invoked a common component structure to fetch the data and render the page. My first line of investigation was to trace exactly what classes were involved in this transaction. Easy enough. Throw a switch and convert the Library package into a Server package. Request the page and watch which objects spin up.  I observed 39 objects spinning away. 39 Objects! A pretty class heavy hierarchy, if you ask me. But the worst was yet to come.

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

Well, here was something pretty radical to take a closer look at. Although Microsoft has done a good job of ensuring behavioral compatibility between the MTS and COM+ runtimes, the literature is pretty clear that COM+ is very different internally, from MTS. I wrote a small driver utility to benchmark class instantiation under MTS and under COM+. The results are quite enlightening.

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

The benchmark utility is quite flexible and provides numerous options for class instantiation. The server component can either be called by the Windows client 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, 'Between the addition of a new apartment type and the integration of the Microsoft® Transaction Services (MTS) context model into core COM, the number of possible configuration scenarios is mind-boggling’. Since you can download the source code and run your own benchmarks, we’ll avoid presenting and comparing a mind-boggling number of cases here. We’ll stick to the basics.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date