Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I want to use ThreadStatic atrribute in my code. I want to know if there will be some performance issue in IIS if I use ThreadStatic attribute in my application as multiple threads are going to access those fields . So I want to get idea if the resources of IIS are overused or any another thing I should keep in mind before implementing this.
There is no direct performance issue using ThreadStatic through IIS, but you have to take in consideration that IIS use a thread pool.
It means that your thread static is not free after a single call.
In an other hand, a web request can be composed by multiple threads executions (page for example but not web service) and may not share the same thread for a same "client request".
If you don't free yourself the ThreadStatic thing, it may cost memory usage.
If you valuate a ThreadStatic in a synchronous method that call only synchronous process and free it in a finally block at end of the same method, you can use it without any side effect.
Related
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 5 years ago.
Improve this question
I've read that using Task.Run in an ASP.NET web app was a bad idea as it uses another thread from the thread pool and hence prevent this particular thread from being used to serve a request.
Isn't the same situation with Parallel.ForEach? Won't it use multiple threads from the thread pool and hence prevent these particular threads from being used to serve a request ?
Isn't the same problem with Parallel.ForEach? Won't it use multiple threads from the thread pool and hence prevent these particular threads from being used to serve a request?
Yes, it will. This means that you'd be decreasing the total throughput of your server by having requests using up multiple requests like this. That individual request would complete faster, but it would complete faster at the expense of other requests.
This also assumes that your machine is under a high load. If there isn't a sufficiently high load on the thread pool, then it could afford to dedicate more resources for that request without inhibiting the ability of other requests to be served, and dedicating more resources for that request may well speed up that request.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I want to stress my .net web service, It feels like something is limiting the concurrent connections I can have.. even when trying from 2 different computers on them server the results were pretty the same. (All of this is done locally, server and clients are on local network so response time is very fast)
So is there a settings I need to change in my server machine to allow more incoming connections?
There are various things that can limit the amount of processing possible, each of which require research to see if they apply. So you might want to add more to your question about what has been verified today.
Regardless, based on your information I would assume that SessionState is enabled. This, with default behavior will limit processing to a single request at a time for each client due to synchronization locks for guaranteed read-write ability. I assume this is the root cause of what you are seeing today. This StackOverflow post talks about this specifically
Others have posted various details in the comments that can help also.
I have found though that load testing is best done from outside sources as well to ensure your entire production pipeline is involved. (Network components, etc)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am new to asynchronous programming in .Net using C#. All I have understood so far is :
With asynchronous programming, threads that are waiting for a web service or database to return data are freed up to service new requests until the data the is received.
Once the data is received, the thread is restarted and continue processing the code that comes after that call.
Now , I wanted to know in details How the state is managed for the thread so that it can start executing from the point the async call was made.
If it uses a stack to handle that, Can some one please give me an insight into the process?
Thanks,
Mayank
Now , I wanted to know in details How the state is managed for the thread so that it can start executing from the point the async call was made.
Async method are divided into smaller chunks. Basically, when compiling async method, for every await keyword new method is generated.
Keep in mind, that this is a big simplification and it's all done behind the scenes and you really don't need to know how it works in order to use it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Is it possible to somehow notify a running process from the "outside"?
I have a C# program that theoretical runs forever. And I would like to notify it to trigger some action manually. It would be best, if this solution is possible on Windows and Linux (mono).
EDIT:
The solution should work without a user interface
My program is, as for now, a part of web service. On initializing, a new Theread is created, which uses the Task class to stay alive
Take your forever-running-process and let it provide a webservice other processes can call.
You might use any cross-plattform webservice framework like WebApi or ServiceStack to achieve this via HTTP calls. This will even work over the internet (if the machines can reach each other).
There are dozens of approaches. You could also use named pipes for example, or put commands into a database (the other process has to query regularly) or - if you're fearless enough - write/read files to communicate. Be creative ...
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 8 years ago.
Improve this question
I am building a WPF frontend that interacts with another EXE that is acting as a TCP service. I had never looked at this before today... being focused on the front end..
However, when I looked at it today, it uses a While true loop with a Thread.sleep(5000) in it to keep it alive and able to process requests from the GUI. However, this seems ridiculous. while it's sleeping, it can't respond to requests and this is causing the GUI to hang while it waits.
Shouldn't this be implimented as a service running in IIS or as a window's service? At least that way it would be more responsive and manageable through the IIS management console?
Thanks
Harold
Rather than sleeping in the loop, it should be waiting for new incoming requests. IIS/ASP.NET could do this for you, but that may be overkill, and may impose hosting requirements that conflict with other requirements. Assuming you don't want to use ASP.NET, a service in C# should inherit from System.ServiceProcess.ServiceBase, which has virtual functions you implement that are called to start and stop the service. These should start and stop one or more secondary threads which do all the processing. Depending on what kind of connection it is expecting, you'd have different ways of waiting for new requests. Assuming it's raw sockets, Such processing should not involve sleeping, as it should be accepting connections on a socket with Socket.Accept and then waiting for instructions (request details) using Socket.Receive, then immediately processing the request and going back to waiting on new input. None of those involve sleeping and make it possible to not only respond quickly, but respond to multiple requests simultaneously.