Most dynamic websites will usually update their content based on a few items. The first most and obvious occurrence would be that the content of the page actually changed; Either your XML file has been re-written or your database contains updated information. The second occurrence would be parameters passed either by the client or the server to the page or web application.
Content on dynamic web pages is rarely real time, unless you are in an interactive page such a forum. Most of the time content will not update in real time. Users browsing a web site will consistently view the same information. So if user A loads the front page of a web site, and user B loads the same front page 20 seconds later they will see the exact same content. before asp.net Microsoft really did not have a real solution to this problem. In ASP you can use application variables but this gets extremely cumbersome and buggy; I do not recommend going this route. If you have to solve this problem in an asp environment the best solution I have found is to write small .exe programs in VB6 or VC++ that use the File.System.Object to write out static html files or .asp files that dont hit the database. You can schedule the .exe files to run in scheduled tasks to run at regular intervals.
ASP.net offers a solution to our problem, output caching. By just implementing a simple tag the entire content of your page gets cached as html to main memory on your web server. So when user B loads your front page not only does that user not force the server to re parse your XML and re query your database, but that request comes straight from main memory, the hard drive does not get hit at all ! This works great and your web page will scream even if you syndicate content from outside resources or complex database types. To implement output caching simply drop this line of code anywhere in your asp.net file:
<%@ OutputCache Duration = "1200" VaryByParam="none" %>
Ok well thats all great but in reality you really need to cache a few different versions of your front page. Your data may not update in less than 1200 seconds. ( 20 minutes ) but the page may need to refresh if a page level or application level parameter changes. There are a few ways of dealing with this one would be partial page caching, you can cache only web controls by simply putting the output cache tag within the web control. Personally I do not like this solution, I am looking to send an instantaneous response to the user. And with 1 gig of memory on my server its got plenty of space to store all those 30-50k cached documents.
page level parameters
Page level parameters such as querystring or form variables are parameters that are passed to a page. To cache multiple versions of a page based on page level parameters you can use VaryByParam.
You do not want:
http://www.myserver.com/article.aspx?articleid=17
to output the same exact information as
http://www.myserver.com/article.aspx?articleid=21
So in this case you would specify:
<%@ OutputCache Duration = "1200" VaryByParam="articleid" %>
This would now cache a separate version of the page for each articleid. To list multiple parameters simply separate them with a semicolon or use a * (wild card) to create a separate cach for any page level.
<%@ OutputCache Duration = "1200" VaryByParam="*" %>
application level parameters
Application level parameters such as session variables or client side cookies are parameters that are page independent. To cach multiple versions of a page based on application level parameters you can use VarByCustom and the global.asax file.
In my case the problem I was faced with was using Forms.Authentication in combination with output caching. If user A logged into my site I did not want it to "Welcome User A" to User B.
he first thing we will need to do is set the location of the output cache to "client or "server, this ensures that the page will not be cached by a proxy server. To learn more about caching location please visit: This Link
Secondly you will need to set up an override function in your global.asax file
<Script language="VB" runat="server">
Public Overrides Function GetVaryByCustomString( _
ByVal context As System.Web.HttpContext, _
ByVal custom As String) As String
Select custom
Case "username"
Return Context.User.Identity.Name
Case Else
Return MyBase.GetVaryByCustomString(context, custom)
End Select
End Function
</script>
And lastly specify your custom variable:
<%@ OutputCache Duration = "1200" VaryByParam="*" Location="Server" VaryByCustom="username" %>
So now if a user logs in he will receive his own custom cached page, as he browses around the site and hits the same pages, he will receive the pages that were cached for him.
http://www.aprogrammersjournal.com/id/58/Output+Caching+and+VaryByParam,+VaryByCustom.aspx
=====================
VaryByCustom Caching By User
Ran into an interesting bug today with one of my applications. A user control that provides messages based on a user's account was showing the wrong information to other users in our testing. The user control was set up with an output cache directive and a VaryByParam="*" setting, yet it was showing other users' messages (one in particular) to basically everybody - not good. The funny thing was, it was only doing it on one server instance, not on localhost, despite its having the same code and same database.
Well, we quickly figured out that this was a caching issue. The problem was that everywhere in the application, the account the user is accessing is specified with an ID in the querystring, so the VaryByParam="*" should do the trick. Everywhere, that is, but one page: the very first page the user encounters and, coincidentally, the one with the problem.
To correct the issue, we (as in Brendan) added a VaryByCustom="userName" attribute to the OutputCache directive, like so:
<%@ OutputCache Duration="99999" VaryByParam="*" VaryByCustom="userName" %>
Then, to make the VaryByCustom work, the final step is to add the following to Global.asax:
public override string GetVaryByCustomString(HttpContext context, string arg)
{
if (arg == "userName")
{
return context.User.Identity.Name;
}
return string.Empty;
}
http://aspadvice.com/blogs/ssmith/archive/2007/10/29/VaryByCustom-Caching-By-User.aspx