Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Server-Side Caching in COM+ and VB : Page 2

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.


advertisement

TEST TOOLS

One of the test tools I wrote is a single-threaded Visual Basic application that I call Td for test driver. (See Figure 2.) To simulate a high load, I just start several instances of the application. This test tool is a bit of a fast hack, and it is highly coupled, not only to the interface ITest that the coclasses are implementing, but also to the coclasses themselves. Anyway, it does its work and it could easily be adapted to be more flexible and competent. All the test results in this article have been created with this tool.

Figure 2. TD application



I can specify when Td is to start calling the component so that I can synchronize several instances of Td. I can also state how many seconds the component will get calls before I count the transactions so that the component gets its working temperature up. In the Execute (s) box, I enter the length of time I want the test to be executed and in Server I specify the machine where the component is located.

The Activate button puts the application in a wait-state until its Start time. When the Save button is pressed, all the settings in the form are saved to the registry. When the Get button is pressed, settings read from the registry fill the form. The Save and Get buttons will make it easy to synchronize multiple client instances so they start at the same time, do the same work, and so on. The close button closes the form.

I have created eight different ActiveX DLLs (one for each technique that I test). Each ActiveX DLL has a coclass called Test that implements the ITest interface. The coclasses also implement the IBank interface (see Figure 3). The DoCommitOnly method is used for StaticFetch. This means the VAT will be returned as a Long, which appears strange since the VAT (in Sweden at least) is 25% or 0.25 (a decimal value). DoDebitCreditTx is used for SemiStaticFetch, and DoSimpleReadSP is used for SemiStaticUpdate.

The coclasses implement the IBank interface to make it possible to use them from the MTClient application in the Windows DNA Performance Toolkit (http://www.microsoft.com/Com/resources/WinDNAperf.asp). MTClient is a multithreaded client that can simulate loads more or less like Td does, but you don’t need several instances on every client machine (unless you want to mix different transactions). To make the tests more realistic, you often want a mix of transactions (for example you might want to have 70% reading and 30% updating). However, each instance of MTClient can only call one specific method and therefore only one transaction-type (unless the method itself is using several transactions to create a mix of transactions). To simulate mixed transactions with MTClient, two instances must be used.

MTClient is also more loosely coupled to the progids than Td since you give the progid to MTClient by typing it in. Another good thing with MTClient is that you can enter your estimation for the number of Transactions Per Second (TPS) needed. Then MTClient will tell you if your component met your expectation.

Figure 3. IBank interface implemented by the coclasses

Using MTClient like this is a bit of a hack of course. This interface isn’t needed for the tests I did, but I implemented it so I could use MTClient. Nevertheless I think using MTClient is sometimes a good solution. Figure 4 shows some results from MTClient although I am not comparing this solution to the other solutions. For these results, I’m using the ProgId SrvCacheFile.Test and the method DoCommitOnly. You can see the settings I’ve used in the Figure 4 (10 client threads, 5 seconds ramp up time, etc). You can see that my goal of 10 TPS was met. You can easily experiment with MTClient directly if you install the Windows DNA Performance Toolkit and download the code for this article.

Figure 4 MTClient results

MTClient -PSrvCacheFile.Test -M1 -#10 -RU5 -SS15 -RD5 -RT2 -SC10 -T1000

test parameters:

Using JIT (Just In Time) Activation

DriverID: 0

SrvCacheFile.Test

DoCommitOnly

10 client threads

5 seconds rampup time

15 seconds work time

5 seconds rampdown time

2 seconds response time required

10 TPS scaling

1000 milliseconds think time

----------

Driver 0 running mtclient.exe

TPS Tx % calls % calls met Secs Secs/Tx

succeeded response time

___________________________________________________________________________

Driver 0 9.89 150 100 100 15.17 0.011

I tested these eight techniques. I will explain each technique and show the test results in the following sections.

Going to the database server each time to get data

Doing nothing (only to give the best possible results for comparison)

Using the Shared Properties Manager

Using the file system

Using global variables for read-only data

Using a LookupTable

Using the Global Interface Table (GIT)

Using Commerce.Dictionary

With the code available for download with this article, you can choose to run the tests for any one of the techniques. You don’t have to install Site Server Commerce Edition, for example, if you only want to compare SPM with LookupTable.

All results will be shown relative to the first scenario of going to the database server each time using 1 CPU in the COM+ server. Therefore, this base value is set to 1. All other values in the test results will be relative to this value. (CPU-usage is for the COM+ server.) As you can see in Figure 5, by adding another CPU, the number of transactions increases by 10% and the CPU-usage goes down from 100% to 94%.

Figure 5 Test results example

Go to the database server each time

No of transactions (1 CPU)

CPU-usage (1 CPU)

No of transactions (2 CPUs)

CPU-usage (2 CPUs)

Static read

1

100%

1.1

94%

Semi-static read

1

100%

1.5

99%

All tests are run with five instances of Td on one client machine. Observe also that I instantiate the COM+ component from the client and then that instance is used until the test finishes. The components will not call SetComplete and they do not implement the ObjectControl object. The components will not have error handling either. Once again, the components are by purpose extremely simple.

OK, let’s move on to the different techniques I tested for this article.



Comment and Contribute

 

 

 

 

 


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

 

 

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