My scenario is : WebApp -> WCF Service -> EDMX -> Oracle DB
When I want to bind grid I fetch records from Oracle DB using EDMX i.e LINQ Query. But, this degrades performance as multiple layers take place between WebApp & Oracle DB. Can I use caching mechanism to improve the performance? But as far as I know cache is shared across the whole application. So, if I update cache other user might receive wrong information. Can we use caching per user? Or is there any other way to improve performance of the application?
Yes, you can definitely use caching techniques to improve performance. Generally speaking, caching is “application wide” (or it should be) and the same data is available to all users. But this really depends on your scenario and implementation. I don't see how adding the extra caching layer will degrade performance, it's a sound architecture and well worth the extra complexity.
ASP.NET Caching has a concept of "cache dependencies" which is a method to notify the caching mechanism that the underlying source has changed, and the cached data should be flushed and reloaded on the next request. ASP.NET has a built-in cache dependency for SQL Server, and a quick Google search revealed there’s probably also something you can use with Oracle.
As Jakob mentioned, application-wide caching is a great way to improve performance. Generally user context-agnostic data (eg reference data) can be cached at the application level.
You can also cache user context data by storing data in the user's session when they login. Then the data can be cached for the duration of that users session (HttpContext.Session)
Session data can be configured to be stored in the web application process memory, in a state server (a special WCF service) or in a SQL Server database, depending on the architecture and infrastructure.
Related
I am using Nhibernet with SysCache Provider for second level cache in an Asp.net MVC 4 application. Somewhere i found that SysCache use ASP.Net default cache system to store the cache items. To reduce the use of my limited RAM, i have implemented my custom cache provider which store data in MongoDB.
Now my question is, as i am using my custom cache provider using mongodb, where will be the nhibernet second level cache data stored? Is in mongodb by my custom cache provider or it still will be in RAM?
By the way, my ultimate target is, i want the NHibernet second level cache using SysCache or any other free cache provider but not want to store the cache items in RAM rather in mongodb. Please give a better suggestion to achieve it.
regard
Habib
Now my question is, as i am using my custom cache provider using mongodb, where will be the nhibernet second level cache data stored?
As you have already developed mongo's SLC and if you change settings the data will be probably in mongo ... ?
The point of caching is to provide faster way how to obtain/fetch frequent data than select them from original database.
Your approach makes perfect sense to work correctly with limited memory but I'm not sure whether it will improve the performance of your application how the point of SLC would require.
You store cached data as document/blob in mongo? Have you compare performance against original cache and w/o cache?
If your solution would be successful it requires to develop mongo's cache better than your original queries against RDBMS. This does not have to be true by default. Depends on your purpose and queries you use.
What is database backed Cache and how does it work ? Something similar in line of when the app server goes down and database is backed by cache there is no time wasted to repopulate an in memory cache
A database backed cache is a method of storing data that is costly (in resources or time) to generate or derive. You could see them implemented for such things as:
improving web server performance by caching dynamic pages in a db as static html so additional hits to the page do not incur the overhead of regenerating the page. Yes, this might be counter-intuitive as often database access is the bottleneck, though in some cases it is not.
Improving query time against a slow (or offsite) directory server or database.
If I understand your example correctly, I believe you might have it backwards. The database is backing some other primary location. For example, in an app server farm, if a security token is stored in a db backed cache and the app server you are currently interacting with goes down you could be routed to a different service instance. The token cache check it's in-memory cache which won't contain the token, so it will be retrieved from the database, deserialized and added to the (new) local cache. The benefits are minimized network transport and improved resilience to failures.
Hope this helps.
What are the advantages and disadvantages of using caching in an asp.net application?
Answers will vary based on Environments and Technology.
Advantages
Reduce load on Web Services/ Database
Increase Performance
Reliability (Assuming db backed cache. Server goes down and db is backed by cache there is no time wasted to repopulate an in memory cache)
Disadvantages
Could run into issues syncing caches
Increased Maintenance
Scalability Issues
With great power comes great responsibility ;). We ran into an issue where we decided to use the HttpContext.Cache (bad idea) in an application that was distributed. Early on in the project someone deemed to just throw it in there and we didn't run into issues until we went live. Whenever it comes to caching you need to look at the big picture. Ask yourself do we have enough Data, enough Users, or a performance requirement that warrants implementing caching?
If you answer yes then you are probably going to need a farm of servers so choose your caching provider wisely.
With all that being said, Microsoft has a new cache API AppFabric/Velocity that you could leverage that handles the distribution and syncing of the cache auto-magically.
AppFabric caching allows you to do time out eviction, or even built in notification eviction, so as your data chances the caching server takes not of it and periodically the cache client checks in with the server and gets a list of stuff it needs to sync.
http://msdn.microsoft.com/en-us/library/xsbfdd8c%28VS.71%29.aspx
Advantage: performances
Disadvantage: new data is not displayed immediately
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I need to create a web application for tasks delegation, monitor and generate reports for a organization.
I am thinking about ASP.Net and MVC should be the architecture to support so many concurrent users. Is there any other better architecture that I should be looking for ?
What kind of server configuration will require to hold this application ?
How do I test so many users connected before I launch this application, is there any free/economical testing tools available ?
Thanks in advance.
anil
the choice of MVC versus webforms have little/nothing to do with the ability for the app to handle load. Your problems will be reading/writing to the DB, and that doesn't change no matter which of the two you choose.
ideas for improving ability to handle load:
first and foremost: absolute minimum is two servers: web server and DB server, they should NEVER run on the same box.
DB:
Efficient queries towards the DB, indexes in the DB, denormalizing tables that are hit a lot, CACHE, CACHE CACHE, running the DB in a cluster, oh, and did I mention CACHING?
Processing:
if you need heavy processing, do this in web services that can run on separate machines from the web servers so that you can scale out (buy more servers and put them behind a load balancer if needed)
WEB:
avoid the need for server affinity (so that it doesn't matter which web server serves a given user at any given time) this means using DB or StateServer to store sessions, syncing the MachineKey on the servers.
the decision of using MVC or not have NO impact on the ability to handle 10k concurrent users, however it's a HUGE benefit to use MVC if you want the site to be unit-testable
remember: Applications are either testable or detestable, your choice
Cache Cache Cache Cache :-) a smart caching policy will make even one server go a long way ... aside from that, you will need to find out where your bottleneck will be. If your application is database heavy, then you will need to consider scaling your database either by clustering, or sharding. If you expect your web server to be the bottleneck (for example if you are doing a lot of processing, like image processing or something), then you can put a load balancer to distribute requests between N number of servers in your webfarm.
For a setup this large I would highly recommend using a Distributed memory caching provider to be layered above your database. I would also really suggest using an ORM that has built in support for the memory cache, like NHibernate since in an application of this scale your biggest bottleneck will definitely be your database.
You will most likely need a webfarm for this scenario, if a single server is strong enough for it currently at some point in the near future you will most likely out grow a single box which is why it's important to architect in the distributed cache first so you can grow your farm out and not have to re-architect your entire system.
I'm looking for a good caching strategy for an CRM App written in ASP.NET. Almost all sites depend heavily on the database, which means caching parts/the whole page for some time does not work in my situation. Is there any other way you use caching in these situations?
UPDATE 1:
The setup is the following:
- ASP.NET App hosted on IIS
- App uses either Entity Framework or nHibernate as OR Mapper as Data Access technology - which ever technology has more advantages for my specific requirements
- SQL Server 2008
We use caching for reference data that populates combo boxes and other fields(e.g. help fields) and any values that are unlikely to change frequently.
There are different levels of caching that are stored for different periods of time, including:
Session (lifetime of the session)
Application (lifetime of the web service)
What database engine?
For SQL Server, have you looked at SqlCacheDependency? Allows you to retain data sets and provides a cache invalidation mechanism based on notifications from the server. See The Mysterious Notification for an explanation how it works.