 Print
 Add To Favorites
 Email To Friend
 Rate This Article
|
Use Write Caching to Optimize High Volume Data Driven Applications
|
by Steven Smith
Feedback
|
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days):
62825/
88
|
|
|
|
| Test – Cache Reads, Not Writes |
In this interim test, I’m again comparing a local database with a remote database while modifying the application so that the reads on the page are cached. Reads represent 2 of the 5 database calls made per page and are being cached for 5 seconds. The reason for this interim step is mainly due to the fact that when most people think of caching, they think of read caching. Almost all write operations in data driven applications (that I’ve worked with) are immediately persisted to the database. Most applications do a lot more reading than writing, too, so there are clearly greater gains to be made by caching the former than the latter in most applications. Since it represents the ‘typical’ scenario, it’s included here for comparison.
Figure 3 shows the two scenarios. Once again, the blue line shows the first test with the remote database, while the magenta line shows the second test with everything on one machine.
Figure 3: Read Caching Enabled
As you can see, the difference between local and remote databases is still huge. Both tests performed marginally better than in the no-caching scenario, showing some benefit to adding the caching. In fact, were it not for the huge difference in performance between the local and remote databases, the addition of the caching would certainly be looked upon as a major improvement, since requests per second between them increased 50% for the remote database case when caching was added.
More Details
Test 1 (Blue) averaged 13.85 ASP.NET requests/second. Test 2 averaged 95.36 ASP.NET requests/second. For Test 1, the web server’s CPU averaged 14%. For Test 2, the web server CPU (and also the db server in this case) averaged 70%. Average Time to Last Byte (TTLB) in Test 1 for each whole page was 67.43ms. For Test 2, it was just 5.66ms.
Looking at the database, in Test 1, the remote database averaged 84.54 Batch Requests/sec. In Test 2, the local database averaged 286.49 Batch Requests/sec.
My editor wondered if perhaps part of the difference between local and remote databases was due to using named pipes instead of TCP/IP stack. I ran the local test again, forcing the connection to go through TCP/IP, and the results were unchanged. In order to do this, I altered the connection string so that the server was referenced by IP (127.0.0.1) and added “Network Library=DBMSSOCN.” |
|
|
|
User Comments
Title:
Modern SQL XML Support
Name:
Steve Smith
Date:
2008-08-08 2:33:41 PM
Comment:
Jason Follas posted recently on how to do the SQL XML work more efficiently in SQL 2005+:
http://jasonfollas.com/blog/archive/2008/06/19/coding-in-sql-server-an-evolution.aspx
|
Title:
MSMQ
Name:
Derek
Date:
2008-01-14 9:37:07 AM
Comment:
Thanks for the article. Having some experience with MSMQ I can tell you it will probably perform well, but we've had a lot of issues with using it in a clustered environment. This is a well-known shortcoming of MSMQ.
We've gone to some 3rd party pub-sub solutions that work much more efficiently and work well in a clustered environment.
|
Title:
Using a synchronized HashTable
Name:
Tim
Date:
2005-08-22 1:41:25 PM
Comment:
Also, how would this be affected by using Hashtable.Synchronized(...) to create the hashtable. It appears that automatically protects the hashtable's Add method and the indexing property Set accessor with a lock, which would protect you during writes.
|
Title:
What about the code for updating the item in Cache?
Name:
Tim
Date:
2005-08-22 12:08:14 PM
Comment:
Can you show sample code for updating the item in Cache? For example, if item is added to cache with certain expiration, etc., when you update it, do you have to add it back with the same parameters, or do you just reference it like Cache[myitem] = updatedValue, and it will retain all previously set values...
Thanks
|
Title:
Programmer
Name:
Microfolx
Date:
2005-05-21 10:33:19 AM
Comment:
This is a very nice site. Keep it up.
|
Title:
Re: Consistency
Name:
Brett
Date:
2005-05-20 5:15:54 PM
Comment:
Nice article... I might consider trying normal XML writers rather than StringBuilder. Or even XML serialization. Probably slightly slower, but reduces errors.
On the point regarding charging for page views. I have two suggestions. One is to periodically reload the current click count from the database and not worry about being exact. Hey if they get 1 million or 1,005,000, does it really matter? This isn't the space shuttle. The second would be to switch to a non-caching code path when you get close to whatever your maximum value is. So when you hit, say 990,000 views (based on your hit rate, etc.) then switch to the non-caching version for that customer.
|
Title:
Consistency
Name:
Brian
Date:
2005-05-20 2:03:29 PM
Comment:
I had to accomplish this exact same scenario. The problem I ran into was the caching. Lets say that one of your advertisers pays you to show their ad 1 million times. How can you insure that it doesn’t go over? If you are holding the most current counters in cache, won’t each process be looking at their own cache, not to mention each server in the web farm and all it’s processes be looking at their own cache.
Another general Cache question. When I write something to cache, isn’t it only available for that particular process? So if you setup your application to have 5 worker processes, won’t that have 5 separate cache entries?
|
Title:
web farm
Name:
parker
Date:
2005-04-24 3:19:08 AM
Comment:
How do you account for disperate sessions in a web farm scenario? Is the cache shared amoung the servers?
|
Title:
Too Good
Name:
Zulfiqar Damani
Date:
2005-04-18 12:46:36 AM
Comment:
It presented very well, also it was interesting too.
|
Title:
Thanks
Name:
Happel
Date:
2005-04-14 8:23:23 AM
Comment:
Thanks for sharing this article, very interesting.
|
|
|
|
|
|
