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


Server-Side Caching in COM+ and VB

Are there times when server-side caching is a good idea? How does server-side caching impact data access performance? Testing the various techniques seems to be the only way this can be determined. Thats what this article is all about. It examines and shows test results for COM+ techniques that are VB-friendly such as using the Shared Properties Manager, using the file system, and using global variables, a lookup table, the Global Interface Table, and commerce.dictionary, and compares these techniques to the caching performance of going to the database each time for data and the baseline when no data is read. Then the article looks at other algorithms and caching options you might want to consider. Also provided with the article is a tool you can use for your own tests.


Is server-side caching good or bad? This question can create many heated discussions. Since I’m from Sweden, I like what we call the golden middle course. We even invented a word, lagom, which means something like not too much and not too little. (This is my favorite expression in Swedish and therefore I just have to tell it to the world all the time.) Obviously, whether it is good or bad depends upon the context. In this article I will try to show that there are situations when server-side caching can be useful by showing how it can be done with different techniques based on COM+.

There are a lot of different solutions to choose from; therefore I will not invent one of my own. Instead I will test a few that have been around for a while such as the Shared Properties Manager (SPM), LookupTable, Global Interface Table (GIT), Commerce.Dictionary, and more.

This article is written for Visual Basic developers and I will focus on presentation-independent caching of data in configured COM+ components. All tests and code will work in MTS too if you are using NT 4. I will not show any results from MTS, only from COM+.

Even though I will show some results from my tests, my goal with the article is to encourage you to do tests on your own, so that you get results applicable to your own environment and for a real application.


I ran my tests in an environment with a very simple architecture. My default architecture is a lot like the one used by Duwamish OnLine. For the configured COM+ components Duwamish calls the different layers Workflow, Business Logic, and Data Access. (Mostly to get a nice sort-order in project groups in VB, I call them Application, Domain, and Persistence Access instead, but that’s another story.)

Where does the caching tested above fit in? In my opinion the most typical place would be the Data Access Layer. Be very sure that you encapsulate all the caching so that you can change it at will easily and without risk.

All the tests discussed in this article have been run in my lab. All the machines are totally untuned. The database server machine is running SQL Server 7 (sp2) on Windows 2000 Server. This 650 Mhz server has 256 MB of memory. The COM+ components are running on a 2 x 533 Mhz Windows 2000 Server with 256 MB of memory. The simulated clients are running on a 266 Mhz NT 4 Workstation (sp4) with 128 MB of memory. The network is a switched 100 Mb and very lightly loaded.

To run the tests, I added the following in the Operating Systems section in boot.ini:

multi(0)disk(0)rdisk(0)partition(1)\WINNT="ONE CPU" /fastdetect /onecpu

That way I created a boot-selection to disable one of the CPUs to do the single CPU-tests.

Developers often believe that if they double the number of CPUs, the throughput will increase 100%. That is of course not the case. Other parts of the system will become bottlenecks, and contention will often be the enemy.

However, it is very important to have an SMP computer in your test environment to help find bugs before you go into production with your applications. I’m always surprised to find that only about 5% of the attendees at my MTS/COM+ course say they have an SMP in their testing environment. Developers often have SMPs in their customer’s production environment, but not in their own testing environment. This is not a realistic choice. In this scenario, problems often occur in production and not in testing, but when the CPUs in production are disabled to make it a one-way box, the problem could not be duplicated

For my company, a one-man-shop, I tried to borrow a dual processor machine for my tests. When I asked around, none of my friends at different companies (and now I am talking about large companies) had an SMP in their testing environment--at least not one running Windows 2000. I finally decided to ask a friend to build me a cheap SMP machine, with off the shelf components. However, when I executed the tests for this article on my SMP, I ran into a problem with the Shared Properties Manager (SPM) that I couldn’t duplicate on my other machines. But I’ll talk more about this later.


I decided to test two different things:

Reading a static value; in this case, the VAT (Value Added Tax). (This value could be implemented as a constant, but then a recompile would be needed if and when it is changed.) The value fetched is of the datatype single. By static I mean a value that is changeable with some administrative work, but doesn’t require recompilation. Typical examples are the VAT or values needed for business rules that seldom change.

To read some semi-static values; in this case, the id and description of all products that a company produces. The values fetched will be a string with information about approximately 60 products and the total size of the string will be approximately 800 bytes. By semi-static I mean data that is seldom changed, but it must be updateable without the support of an administrator. Since these values are semi-static, they will change every now and then, but I don’t want any user to see an old value at any time. Therefore, it is a requirement that the value seen by the user must always be the same value that is stored, at least at the point in time when the component fetches the value.

I wrote a third test to update the semi-static data, but I won’t show any results from that test since the updating doesn’t happen often and therefore, is not time critical.

Figure 1. ITest Interface

To really stress the COM+ server, I decided to create a loop at the server side for each call from the client tier. This code shows how the looping is accomplished and Figure 1 shows the methods in the ITest interface.

Private Function ITest_StaticFetch() As Single

Dim intI As Integer

For intI = 1 To StaticMax

ITest_StaticFetch = StaticFetch()

Next intI

End Function

For both the static and semi-static tests I made 10 calls to the caching mechanism for each call from the client. If I made only one call for each call from the client over DCOM, the DCOM call would take perhaps 90% of the time, and therefore the different caching mechanisms would appear to have similar performance. My descision is realistic to some degree since it is common to fetch several values from the cache at each client request. This also helps to make the tests more CPU-bound on the COM+ server.

Performance comparisons can vary for many reasons and with distributed applications, the problem is much worse. Note that the results I give in this article are only an indication of what you might see in your own environment. You’ll also note that the code is written as simply as possible to perform the task, often at the expense of good coding style. (See Example of Code Structure for COM+ Component.)

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