I have started to work on this .NET web application where it has an IOC container (Windsor) to create business managers, and to keep them in the memory until the IIS recycles them. Basically these business managers are having their own states, and data of which the content is modified from background threads that are fired at the Application_Start . This is not the way I was expecting an web application to work ( which are supposed to be stateless and per thread for per request) and I'm not quite sure if this implementation is sustainable/scalable. Has anybody tried the things in this manner if so what are the consequences/pros that you see in this?
We use statics in the application, only for the core features. Static classes are shared across all the requests, so usability should be somewhat low. In the development world, we're seeing statics pop up more and more: ASP.NET MVC 3 utilizes them for various areas of the application, as well as other popular OS source libraries.
As long as there aren't a lot of them, you should be OK... but you can always verify with a memory profiler too see how big they are getting, and whether they are sucking up too much memory.
The other alternative could be to place them in cache, or rebuild them and store them in each request. To store them globally in a request, use HttpContext.Current.Items collection.
Related
Are singletons in ASP.NET shared between users/sessions? And if they are, are there any safety considerations? Think serializing/deserializing vulnerabilities, thread safety etc.
Is it the way to go using settings from the database that are the same for all users?
Hand crafting the anti-pattern called "Singleton" in C# code is a really bad idea in general, ASP.NET or not.
The singleton lifetime that is supported in the dependency injection framework is a good idea if it does what you need.
I would advise you to only use it for read-only data, like settings, though. You don't have an application on the desktop as of old. Your application might be recycled on the fly, or maybe stretched across multiple nodes on a server farm. So suddenly your "singleton" is actually only a singleton if you have a single instance of your program running. Building your application so this becomes an artificial problem (i.e. the framework would support it, but your own code is build to fail if you actually do so) is not a smart way to go about this.
So to summarize: Singleton lifetime in your dependency injection container? Might be okay. Depends on your use case. An actual "Singleton" pattern in your code? Bad. Very Bad. Tells me you don't actually do any unit testing and nothing is planned to bring this application over a few thousand hobbyist users who don't care if your app is down every time you deploy.
I have to see if I can work around a known thread safety issue on third party component. The plan was to let an ASP.Net app to talk to the third party component via a WCF service, this was based on the assumption that I will be able to assign the WCF service to it's own application pool, restrict the pool to one working process and the working process to one thread. Requests to the service will have to wait for their turn, but that's OK because we expect them to require very little time and to be rare as well.
Problem is, I can't find anything that suggests how to achieve this part: "restrict the working process to one thread".
I have found a few useful pages, but no solution:
On IISforums, the discussion seem to suggest that I can achieve this in IIS 7+ but does not mention IIS6.
On MSDN Blogs and linked MSDN books chapter (can't put the link because I'm new here!) the discussion is mostly about what you can set via the machine.config file, which, if I'm understanding it correctly, is going to apply to all AppPools/Worker processes and is not what I'm trying to do, I would like to control what one single app can do, leaving the other applications untouched.
Questions:
Is it possible to achieve what I'm trying to do? (assign the WCF service to it's own application pool, restrict the pool to one working process and the working process to one thread" via IIS 6 configurations)
If not, can this be achieved programmatically somehow? For example, using locks or other threading-related tricks within my WCF service implementation.
It doesn't make much sense to me.. A web server have to be multithreaded by definition, because it must handle different income messages at the same time, if there is only one thread once in use any new request will fail.
What about to wrap the component in a class with a SynchonizationAttribute, so only one thread can access the component? Even if this will make your solution less scalable, at least it may work
http://msdn.microsoft.com/en-us/library/system.runtime.remoting.contexts.synchronizationattribute(v=vs.110).aspx
I've written a class in VB.Net that is consumed in an ASP.NET Web Application running IIS7. I use .NET Framework 4.0. The class performs a REST request to an online and retrieves an XML response containing strongly typed data.
This class also performs caching using an SQL Server database. The class is compiled to a .DLL and referenced by the Web Application. It works excellent and now I need to know how to make the class thread-safe.
I have no experience with making code 'thread-safe'. I don't know where to begin in determining whether or not it is thread-safe. Am assuming, because I didn't pay attention to this during development, that it is NOT thread-safe and that since it the web application will be used by many users at the same time that it must be payed attention to.
Can anyone point me on how to test for thread-safety? Are there any resources online that that will give me some ideas? Are there any rules of thumb that will tip me off as to where my main concerns are?
The easiest possible thing you can look out for is the use of "static" (C#) or "Shared" (VB.NET) variables. If these variables can be modified throughout the lifetime of the application you will likely run into threading issues which can really often result in "random looking" problems.
I would also be concerned about how you are doing the caching in your database as multiple .NET threads hitting SQL (for the cache) could cause issues as well depending on how its designed.
Bottom line is you are likely going to need to learn more about threading if you want to be sure this is going to not have issues. Probably the best book I have ever read in terms of simple to very complex C# topics is C# 4.0 In a Nutshell I would take a look at that book especially the threading chapters. (Seriously read the whole thing though) If you get that read through and have a good understanding of the concepts mentioned you should be fine.
I'm porting a cpu-heavy .net 4.0 windows application to a .net 4.0 wcf service. Basically I just imported the .net classes to the wcf service.
All is working well except for performance at the wcf service - a task that takes 6267947 ticks (2539ms) uses 815349861 ticks (13045ms) on the aspx.net wcf service running locally on the same develop machine.
I allready have uploaded the service + a test client to appharbor where the performance is as bad as on my local machine - the link to my test app is: http://www.wsolver.com/. Any ideas on how I can improve performance?
Check any dependencies on your service that may be constructed at Request Time. These Include constructor dependencies and field/property dependencies. Maybe one of them is causing the delay? If this is the case consider using a singleton to instantiate the long running class.
Have you confirmed that subsequent requests still cause the delay?
Also create a band new service that does something simple like Datetime.Now.toString() and see if it has the same problem.
Please take a look at the articles and whitepapers below. I think they should give you enough concrete performance considerations to explore, and likely some very practical settings to tweak, optimize, or change.
Performance Tuning WCF Services
Optimizing WCF Web Service Performance
Using ServiceThrottlingBehavior to Control WCF Service Performance
Transport Quotas
Optimizing IIS Performance
ASP.NET Performance Overview
A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies
If you need to do time-consuming initialization of a complex datastructure, you should to that once in Application_Start() and assign the generated datastructure to a static variable on the MvcApplication object. Doing it just once on application start is going to be much faster that doing it in each request.
I would take a full memory dump during the 13 seconds (or several using procdump) and then acutally look at what is occurring in the process (windbg and sos.dll). Then, you can narrow down which code is the culprit.
I take it that the dictionary tree is only loaded once, into cache? You're not loading it on every call are you?
My team has been tasked with designing a web application that is workflow driven. I need some advice regarding the design.
The workflows need to be dynamic. Meaning, users can define the workflows through some interface and apply those workflows to a given scenario (The definitions will live in a SQL 2008 Database). The scenarios are defined by the business and will never change. So there may be only 2 types of scenarios a workflow can be defined for. The workflows are not necessarily linear. Some sort of state will drive the workflow. States will also be dynamic, but only exist in a workflow.
I have been looking at examples of workflows and state machines and my head is spinning. I am not sure I want o leverage Workflow Foundation or something we develop. I have seen this and think it may work, but I am not sure the state full implementation will work for us.
You can do this using WF4. I have never used Objectflow so I can't really comment on that but it appears to be an in memory solution and with an ASP.NET web site hosted in IIS that means you will occasionally lose state as IIS recycles and AppDomain. Usually not a big problem as it doesn't happen often but a WF4 InstanceStore will take care of that. It will also allow you to run on a web farm without sticky sessions and have the workflow migrate from machine to machine.
Another nice thing is the workflow designer. Its a WPF control you can rehost in your own app. Not in am ASP.NET or Silverlight app but you can provide a smart client to have users update the workflow definition using the sane designer as you use in VS2010.
The biggest problem with WF4 is the asynchronous execution nature. You will need to use a SynchronizationContext to execute the activities and wait for the workflow to go idle in the new state before you return the resulting HTML to the browser.