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 3

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

GOING TO THE DATABASE EACH TIME

Going to the database each time even if the value is readonly is one extreme of these techniques. If you meet your performance goal with this solution, then this is a good solution. Simple and flexible.

And since this is the technique that I’m trying to beat with the other solutions, I have (as stated above) recalculated the results from this test so that the result from going to the database always equals one. This way the relative difference will be obvious when you compare the results.



Figure 6. Data access

Public Function VatGet() As Single

Dim con As ADODB.Connection

Dim cmd As ADODB.Command

Set cmd = New ADODB.Command

With cmd

.Parameters.Append .CreateParameter("", adSingle, adParamOutput)

.CommandType = adCmdStoredProc

.CommandText = "VatGet"

Set con = Connect()

Set .ActiveConnection = con

cmd.Execute , , adExecuteNoRecords

VatGet = .Parameters(0).Value

.ActiveConnection = Nothing

End With

'Clean up

Set cmd = Nothing

ConRelease con

End Function

Observe that the code shown in Figure 6 is used for the database access in the other components too. As you can see, I have used stored procedures in the database. Another thing to note is the use of the GetString method to convert the recordset into a string. You may not want to receive information back to the client tier in this way, but I wanted to use a string as a simple caching unit. (Otherwise I could use disconnected recordsets for moving data between layers, but I decided to free my tests from all recordset-related issues. It’s actually not a recommended solution at all to use ADO recordsets for caching solutions in a shared scenario as is the case with server-side caching). The code for fetching static data for this technique looks like this:

Private Function StaticFetch() As Single

StaticFetch = VatGet()

End Function

In the table in Figure 7, I show the CPU-usage from the COM+ server (which is what I am going to show in all the following result tables too). Don’t forget that in this case there will also be a lot of CPU-usage on the database server which will be avoided in the other solutions. Often the database server is the hardest component to scale out and therefore this is valuable.

Figure 7. Results for Going to the database server each time

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%

For static reads, there is little use of the extra CPU on the COM+ server, and for semi-static reads there is significant benefit from the extra CPU. I assume that in the second case there is more work done by ADO in the COM+ server than in the first case. Observe that the static read test was CPU-bound on the COM+ server, even though it has a significant CPU footprint on the database server too.

DOING NOTHING

Figure 8 shows the results when nothing is really done at the server. That is exactly what the Do nothing coclass is trying to do. It returns a constant for the static read and the semi-static read.

The results for the number of transactions of all other techniques should probably be somewhere between Go to the database server each time and Do nothing.

Figure 8 Results for Do nothing

Do nothing

No of transactions (1 CPU)

CPU-usage (1 CPU)

No of transactions (2 CPUs)

CPU-usage (2 CPUs)

Static read

50

100

64

98%

Semi-static read

90

100

105

74%

So far I have a nice range from 1 to 64 for the static read and 1 to 105 for the semi-static read to compare all the other techniques. I expect those ranges to be the lower and upper results.



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