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 6

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

USING COMMERCE.DICTIONARY

Yet another dictionary object is the Commerce.Dictionary found in Site Server Commerce Edition. This dictionary component is easy to use (see the code example below), and it is more competent than the LookupTable. Commerce.Dictionary has Any Apartment as the Threading Model.

This test is similar to the LookupTable test in how the problem with the reference to the object is solved, and how the object is marked as dirty. The biggest difference here is that the data is not fetched from a file, but from the database when the first thread is started.



It was hard to find information as to whether I needed to protect reading from and writing to this dictionary object with a mutex or whether that is taken care of internally and automatically. The throughput results indicate that this is taken care of automatically, and J.D. Meier at Microsoft confirmed my guess, thanks J.D.!

Observe in this code for the static fetch that the key-names look like properties on the object; vat is really a key. The results are shown in Figure 17.

Private Function StaticFetch() As Single

StaticFetch = gobjDictionary.vat

End Function

Figure 17 Results for Commerce.Dictionary

Commerce.Dictionary

No of transactions (1 CPU)

CPU-usage (1 CPU)

No of transactions (2 CPUs)

CPU-usage (2 CPUs)

Static read

8

100%

8

76%

Semi-static read

18

100%

18

74%

As a matter of fact, the extra CPU has a slightly negative impact, probably because of contention. The result isn’t that impressive, but Commerce Server is often using this dictionary component internally. Because of that, my guess is that this component will be developed in the future.

SUMMARY OF THE RESULTS

I’ll try to summarize my results. A picture says more than 1000 words, right?

Figure 18 compares the results for both the static read and the semi-static read with 1 CPU and 2 CPUs.

Figure 18. Transaction and CPU usage results for static read, 1 CPU

Figure 19. Transaction and CPU usage results for static read, 2 CPU

Figure 20. Transaction and CPU usage results for semi-static read, 1 CPU

Figure 21. Transaction and CPU usage results for semi-static read, 2 CPU

Figure 22 compares the 8 techniques.

Figure 22 Summary of techniques

Go to db server each time

SPM

Files

Global Vars

Lookup Table

GIT

Commerce.Dictionary

What to cache

State

State (not VB-objects)

State (and serialized objects)

State (not VB-objects)

State

Objects

State

Threading model

N/A

N/A

N/A

N/A

Any Apartment

Creates a thread neutral object

Any Apartment

Implementation detail

X
<![if !supportLineBreakNewLine]>
<![endif]>

Not supported

X

A wrapper needed to use from VB

You need Site Server Commerce Ed

Built-in locking

X

X

X (I chose to use a mutex in my tests)

Typically not needed, one instance per thread

X

Typically not needed

X, automatic

Automatically realtime OK with farm for COM+ servers also for semi-static data

X

No contention because of several copies of the data

X

Need for holding a reference somewhere between requests

X

X

X

And Figure 23 summarizes my recommendation.

Figure 23 Recommendation summary

Go to db server each time

SPM

Files

Global Vars

Lookup Table

GIT

Commerce.

Dictionary

Per user data

X

Static data

OK if performance and scalability is good enough

X

X

X

X

Perhaps OK if complex structure

X

Semi-static data

X

X

X

No (because of several instances)

X

Perhaps OK if complex structure

X

Data seldomly read

X

Data often updated

X

Much data

X

No (because of several instances)

High isolation level needed/real time consistency

X



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