I would like to integrate a Cache Manager in an ASP.NET application. Basically I would like a page that would display what's in the cache and let me delete specific items or clear the whole cache. Ideally I would like as much information as possible, such as how long it's been in the cache for, the hit count, the size of the object, possibly see the object itself, etc. Of course I realize that some of this information might not be available from the default cache API.
I think it would be fairly easy to implement but I don't want to reinvent the wheel. I did a search and came across that one:
http://aspalliance.com/cachemanager/Screenshots.aspx
Just wondering if there are other options that I could compare.
Cheers
I use this code to view the cache data.
http://www.codeproject.com/KB/session/exploresessionandcache.aspx
Its not a cache manager, but its a good point to start.
You can use one of the following open source cache solution if you find it useful
http://csharp-source.net/open-source/cache-solutions
hope it helps
Related
I'm trying to cache user controls and on some pages i want to cache single objects. There are multiple ways of implementing caching, and my head is breaking over it.
The way I see the caching options now:
You have the PartialCaching option which is set to cache the control for 30 minutes, and after that it clears itself... You have the varyByParam to identity the page by its querystring paramaters... or other vary options
But i just cant find an appropriate way to add caching to a control, and be able to clear the caching programmatically when i update one of the objects used in the control from the backend.
You can do HttpContext.Current.Cache.Insert(), which accepts a key on which you can destroy the caching item later by using remove... This can save objects in cache but can you use options like varyByParam?
My questions are burnt down to two:
Is there a way to clear the caching on specific user controls from the code? If yes, can this be done according to the varyby options?
How would the object caching respond to logged in users or anonymous users using Insert()?
EDIT:
I'm caching multiple things.... And I'm really flabbergasted in which choice to make referring to caching. Can the Cache.Insert be varied by Parameters?
The main problem is peopling editing things from the backend, which needs to trigger an event that reinstantiates or clears all caching items referring that object.
You can remove items from the output cache using the following.
HttpResponse.RemoveOutputCacheItem("/caching/CacheForever.aspx");
Now, this is only going to get you part of what you are looking for. This will remove ALL cache entries for that specific page. The MSDN documentation confirms the behavior.
As to your other question Cache.Insert() is a single cache store across the application, user identity is not considered.
Now I would also take a bigger look at what you are doing, it might make sense to only cache the actual data and then you can add/remove the specific items. However, if your .control really does take a lot of CPU etc to handle the display then the output cache idea works.
Using the System.Web.Caching.Cache class you can cache items and create dependencies for the items in the cache. If you're using a SQL server, then you can use the SqlCacheDependency class to clear items from your cache based on your database.
Otherwise you can create your own derivatives of the CacheDependency class which you can use to accomplish the same thing. I found this post that describes doing that.
Running an MVC2 site against IIS7 and would like to capture more detail of how users traverse the site - ideally to the point of being able to replay even the duration between mouse clicks - feedback of where people pause and/or backtrack.
I could do this with flash but that's no longer an option. Now it's just IIS7 via asp.net f4. IIS7 _should be able to provide this via 3rd party extensions - especially for this sort of niche need. I'm willing to consider client-side .net components but this sure seems to be the responsibility of the server.
[opps...does this belong on serverfault?]
thx
justSteve. Here is a solution that we have used:
http://www.seevolution.com/
I don't think that it gives time between clicks, but it does give very detailed tracking considering it's price (I don't know if that's an issue). We have really liked it. Fantastic detail.
You could also roll your own solution. Using jQuery and the $(document).click() function, you can log when they click, and the points on the screen. Then every couple of minutes, serialize it and fire it off to the server. You can get extremely fine-grained detail that way. The nice thing with seevolution is that they've done all of the work for you already, but it probably isn't as detailed as you would like.
JMax
Maybe not the "in-house" solution you're after but we are about to implement SessionCam at my company, which seems like a pretty good match for what you're looking for. Not having actually finished implementing it yet, I can't vouch for it in terms of quality at this point - but the description of the product certainly matches.
You aren't going to be able to capture the level of detail you need using a solely server-side solution. There needs to be a degree of client-side work - whether it's in flash or javascript - to capture things such as where the mouse is hovering (for heatmaps etc).
I personally haven't used this product, but a friend of mine spoke highly of it.
Clicktale
Is there any way that I can list the pages which are currently stored in the OutputCache?
Just a list of paths would do, but if there's a way to get more information about each item (expiry etc), then all the better.
As far as I remember Cache is a singleton and there is only one instance of it per app domain. OutputCache uses it too and it's nothing more than just a Response.Cache. So I think cached pages should be available through the Cache (Sorry, I can't check this at the moment). And the following articles should help you in this case:
http://www.codeproject.com/KB/session/exploresessionandcache.aspx
http://aspalliance.com/CacheManager/Default.aspx
Here is a little tool I wrote that will let you to view the contents of your Cache. You can also view the dependencies on a file and remove the cache.
https://github.com/azamsharp/WIYC
Here is another tool that displays the Usercontrol(Webforms) cache and am extending that to display the outputcache details as well
https://github.com/chandarmk/InternalCacheHandler
Has anyone ever tried to integrate AspDotNetStorefront and Sitecore? I've been trying for the past couple of days to come up with a way to get the two systems to play nicely together, but it doesn't seem feasible from what I can tell. A couple issues I've run across so far:
Authentication between the two (AspDotNetStorefront has its own implementation, Sitecore just uses/extends .NET Membership)
The main DLL for AspDotNetStorefront is what pops up in the stack trace when I get yellow-screened, but that DLL is obfuscated so I can't figure out what the problem is.
The biggest issue is that we need to keep our existing AspDotNetStorefront application as an e-commerce backend and use Sitecore to do everything else. AspDotNetStorefront has a CMS as part of it, but it's really not an acceptable solution for anything but really basic content pages.
Any thoughts on how I might go about this?
EDIT:
I've decided to break this whole thing down into the different problems that I am facing at the moment and solve each one as efficiently as I know how. I'll detail the ones I have here and then update when I run into new ones.
Problem 1: Authentication between the two systems.
This one isn't too bad actually if you're knowledgeable about forms authentication tickets, which I wasn't at the time but am learning quickly enough. As long as the two systems share the same encryption info, it's easy enough to pass information back and forth between them using cookies as stated below in the accepted answer. The other kicker is that I needed to set the CustomerGUID in the AspDotNetStorefront Customer table to be the user ID from the Sitecore user tables (standard ASP.NET membership). So far this approach seems to work pretty well (I'm still in the proof of concept stage at the moment.
Another thing to keep in mind if you ever need to attempt this is that AspDotNetStorefront comes with a web service that you can use to basically do anything you need. Since they use the same encryption keys, I am able to log in on the storefront side using this service more securely than just passing over clear text passwords (I had to write the method myself, I don't believe it comes standard, if I am mistaken please let me know). Although I doubt it's a huge deal since it all happens server side anyways.
Problem 2: Getting at the product data
This one was a little more troublesome. The aforementioned web service has a few issues I've had difficulty working around. However, since the databases are going to be on the same server, I simply decided that since all I really need is the price and ID I would go ahead and set the ProductGUID column of each product in the Storefront database to match the Sitecore item ID of the corresponding item in the Sitecore database. This way I just need a quick query to grab the ProductID and price information which is only used in a few places. Everything else is going to be housed in Sitecore.
If anyone has anything to add feel free, as far as I can tell from Google, no one has actually done this before, so I'm having a lot of trouble finding resources on this particular topic.
UPDATE:
The integration is in fact possible and our site has been up for a week and a half now with very few integration related problems. This isn't something I recommend doing really on a personal level, but it is in fact possible to pull off.
I know ASPDotNetStorefront and other CMS systems (but not Sitecore). If I was approaching this, I would probably start simple and create a custom URL structure for sitecore 'content' pages that ASPDNSF would direct to Sitecore to handle. [possibly replacing the existing topics system in ASPDNSF]. So, for example: a URL such as www.domain.com/p-1234-aproductpage.aspx would be handled by ASPDNSF whereas www.domain.com/content/123/a-content-page would get sent to Sitecore to render. This is a straightforward web.config edit.
Security sharing across the systems should be possible across the same domain as the cookie information will be available (you should be able to create some code in Sitecore using the ASPDNSFCommon.dll and a cast of HttpContext.Current.User into a AspDotNetStorefrontPrincipal class to detect if a customer is logged in)
Another way to approach the problem would be to write a function that retrieved Sitecore content from the database based on a URL id and then write an ASPDNSF XML template to use the function to retrieve this content based on the URL. For example, you could create a custom URL structure in ASPDNSF such as www.domain.com/sc-1234-sitecore-content-item.aspx which is sent to your custom code; 1234 is used as the sitecore content id and the XML template retrieves the content and renders it on screen.
This second approach has the advantage of using Sitecore for all non-product content management while keeping the live application in ASPDNSF. Also one set of design templates and all your security issues go.
We are working on Grid Views in an ASP.NET application.
Here we would like to avoid the database calls for binding dataset/data table to grid view whenever a user clicks on sort (column sorting), pagination links or whenever he updates a record.
Would you please let me know the best practice to handle it?
If would be great if you could also provide a reference document or web references (If needed).
Many Thanks,
Regards,
Nani.
If you want your users to have extensive sorting, pagination and editing capabilities without frequent database calls, you'd be better off creating a fat Windows client. Web apps in general are better for thin clients.
You could do all your sorting and editing client-side with JavaScript, but that would be an incredibly bad idea. I would say: let your server and your database do what they're good at, and don't be overly concerned with minimizing their roles in your application.
You have a few options here, but they all have their own pitfalls and are often worse than just hitting the database again. Some possibilities:
Save the DataSource in the Cache. See Caching Application Data for a good overview.
For small amounts of serializable data, you can consider saving it to the Page's ViewState. The drawback of this is that it increases the size of the HTML you send to the client, so you need to balance that against the time you may be saving by not hitting the database again. Scott Mitchell's Understanding ViewState is a great introduction to this.
Just for completeness' sake - this one is terrible: you can save the GridView's DataSource in the user's Session. This eats up your web server's memory; you probably should not use this technique except for prototyping (in which case you might as well hit the database again).
Finally, you should absolutely take seriously the advice in these other answers.
I think you will be hard pressed to make this optimization of any use. Are the GridView sort/update/page functions taking a lot (inordinate) of time to complete? You might need to look at the database design as well.