I'm currently working with a web application and it has a custom made workflow implemented using .net classes. In that workflow, we update some data base values and send emails to users base on certain business logics.
System has 400 concurrent users and 10000 user base and also users can create Purchase request with maximum 52 Purchase request lines. Average Purchase request data load in this application is 10 -15 Purchase request in 10 minutes. User do some actions using web application which is implemented using ASP.ne开发者_高级运维t 3.5 and based on user input will need to execute workflow.
My Question is due to the the work load we have,
We are trying to execute workflow in a separate thread apart from UI thread. Is it a good decision to take or workflow should run on same UI thread ?
Last time I had to work in a similar scenario we actually had the workflow as a totally separated application from the UI. The reason we did this is because if something failed on the UI it would not affect our workflow, and the other way around. That separate application also was multithreading. After some work I was put out of the project, but I know my Colleague did some more work on it, and he even added a couple of extra Console Applications working at the same time. You can never be too careful.
When dealing with web applications, the thing you have to keep in mind with threading is "Will this task take a long time to complete". If Not, then there is no reason to spin off a thread. Threading doesn't magically make your app work faster, particularly if you just have to wait for the results anyways.
If the work does take a significant amount of time, then spinning off to a background thread would allow the IIS worker processes to be recycled and accept new incoming requests.
Spinning off more threads can actually cause more load on your system, since you're now firing up 2x as many threads, each with it's own stack, and other resources. It only makes sense if you get an actual gain out of it.
精彩评论