Last post Dec 20, 2010 06:47 PM by DigiMortal
Dec 14, 2010 01:44 PM|jeremyrfoster|LINK
I have an MVC3 web app that represents about a dozen different entities, but I have built a common search function so that the user can do a single search and get results from the various entities. It works fine, but as I suspected, the performance is slow
because the search is occurring live and there's a lot to search. A cache would be fine even if it was a long one (daily even), but I don't know where and when to actually refresh the cache. If a person uses the search when it's been longer than the cache
timeout then it will be really slow for them that one time and that's not acceptable. I'm thinking that I have to have a Windows service in place or something that builds the cache, but perhaps there's a better way that I don't know about. I can't do it entirely
in the database because some of the entities don't exist in the database (one entity list is composed by searching through some files on the system for instance). Any help is appreciated.
Dec 20, 2010 04:09 PM|jeremyrfoster|LINK
I'll answer my own question in case it's of benefit to anyone else. I found a solution that works great. In the global.asax.cs file I create a timer on Application_Start, set that time to elapse hourly, tie up the event handler, then in the event method
I build my site's index and populate the cache using HttpRuntime.Cache. It works excellent. The cache is updated each hour and users never know the difference.
Dec 20, 2010 05:59 PM|sachingusain|LINK
If you are looking at distributed cache then look at AppFabric.
Dec 20, 2010 06:32 PM|DigiMortal|LINK
Relational database is not very good choice for searches. OLTP highly normalized data structures doesn't perform well in search scenarios.
If you don't have huge amount of pages you can use
Microsoft Search Server Express - it's free. You can make it index your web app and you can also write indexing filters for it if you need. Practically you can make it index everything you need. You don't have to use Search Server UI to search data - you
web services it provides and integrate search to your site. It looks like it is part of your site. Behind curtains you have powerful search server you can configure to get better and better results.
Dec 20, 2010 06:38 PM|jeremyrfoster|LINK
Not sure what you mean about a relational database not being a good choice for searches. If the data exists in a database then there's no getting around that and it's going to have to be "cached" in one sense or another anyway. So waiting for it to come
out in the form of html pages and letting it get indexed is really just another form of caching and in this case I don't think it would work as well because the data exists behind forms and requires that users do keyword searches, right? So the solution I
have now where the application updates the cache from the database every hour still seems to me to be a great option. Let me know if I'm missing something.
Dec 20, 2010 06:47 PM|DigiMortal|LINK
Well.... I'm not sure how fast your database grows or what will be it's size let's say year after active using. Your solution works only up to point where your database is not big. If your database grows big then your idea doesn't work very well anymore
because after each hour your database will be flooded over with queries that update search indexes. Search servers work on small and large scenarios very well because they are highly scalable.
If you want to build you search stuff manually and you want it work fast then I suggest you to use in-memory cache server like memcached or something like this.
If you plan to stay small with your database then you can do whatever you want - it is not very easy to get nowadays servers down if some task needs a little bit more resources and it is not something big. :)