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
I have a WCF service which essentially just does this:
public SomeClass SomeMethod(){
using(var db = new LinqToSqlContext()){
return db.SomeMethod();
}
}
Client side it has auto generated asynchronous methods but I'm just wondering if there is any benefit to making the service itself use async Tasks? After all the method finishes when it finishes and it could only ever await on a single method.
Short answer: probably not.
async can help a WCF service scale faster and farther, but if your backend is just a single SQL server (as seems likely from your code), then even synchronous code can probably scale further than your SQL server.
Long answer: you won't know for sure until you do it both ways and run performance tests.
If the method can do multiple tasks independently at the same time, then there might be a performance benefit from using Tasks to run them asynchronously.
Otherwise there's no point (and it may even be a negative effect due to overhead of multi-threading).
Related
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 3 years ago.
Improve this question
I display some of the data i.e. Sum, Average and Total on a page and want to update them after the data changed using SignalR. Most of the examples uses the following approach that broadcast all of the clients after create / update / delete methods (that change data) are executed:
private void BroadcastDataChange(Data data)
{
Clients.All.dataChanged();
}
However, I am wondering if there is a smarter approach that let me update the data i.e. periodically refreshing without broadcast in each of the create-update-delete methods (I do not use SqlDependency, etc, juts using SignalR). On the other hand, I am not sure this kind of approach is contradictory to the SignalR logic. This is the first time I use SİgnalR and I am too confused :( Any help would be appreciated.
You can use polling with SignalR. It's just an inefficient way of doing things though, because: (1) there would be a delay between when changes happen and when they are broadcast to clients. (2) broadcasts would happen even if data didn't change, which is a waste of resources.
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 4 years ago.
Improve this question
To enhance performance, I want to exit a function without waiting for all async functions to complete. I only care about the results of the first function. The others should complete when ever and log their own exceptions.
// I care about this result
int? bookingId = await BookingService.SaveBooking(...);
// These should run async in the background. All async methods.
EmailService.SendEmail(...);
CreditCardService.SaveCard(...);
SMSService.SendSms(...);
return bookingId;
What are the risks of omitting await keyword there?
The main risk here is that they fail and cause unobserved exceptions. A secondary risk is that they attempt to interact with some async state that no longer makes sense once the main operation has completed. If you're happy that neither of these things are a problem, you should be fine - but you should be a little cautious with this approach. This is essentially a "fire and forget" scenario - the compiler will try to fight you
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 am learning async/await and I came across the blog in which it's mentioned about using ConfigureAwait with async/await. It read's like this:
ConfigureAwait accepts a Boolean continueOnCapturedContext parameter: passing true means to use the default behavior, and passing false means that the system doesn’t need to forcefully marshal the delegate’s invocation back to the original context and can instead execute the delegate wherever the system sees fit.
The information does not tell much in detail, can anybody explain the real world example of using it. I also searched further and found out that it should be used with HTTP calls and such, but didn't got concrete answer for why should we use it.
Reference link: https://blogs.msdn.microsoft.com/windowsappdev/2012/04/24/diving-deep-with-winrt-and-await/
This is useful for scenarios where a single thread handles multiple actions, think Dispatcher thread in WPF or the host thread in IIS.
It is most obvious in Asp.Net (on Windows and full .net, hosted in IIS) -> if you do not specify .ConfigureAwait(false) and the request takes a significant amount of time, no other requests can be processed by the same w3wp.exe process.
The whole app is essentially blocked.
What this is doing is saying that the control can return to this stack using another thread from the threadpool, essentially unblocking the main thread.
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 9 years ago.
Improve this question
I'm implementing a network library, and I'm making it asynchronous (with beginxxx-endxxx, not async/await). I also want to leave some synchronous methods, which I plan on implementing like
xxx()
{
var r=BeginXXX();
EndXXX(r);
}
I know that doing something similar with async/await is a bad idea and will cause deadlocks.
Is this a good idea with Begin/End, or will this cause any problems down the stream/kill app's performance?
This way of doing synchronous operations will be less performant, in particular around memory allocations. Immediately blocking on the IAsyncResult also (usually) requires you to allocate your AsyncWaitHandle, so you're also allocating an extra kernel object for each request.
In the end, it just depends on how performant you need your synchronous apps to be. If this is a general-purpose, widely-used library (e.g., System.Net.Sockets.Socket), then you should definitely not take this approach. If it's just a basic library and you don't need to support extreme scenarios, then you could probably get away with wrappers like this.
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 8 years ago.
Improve this question
I have been told to make a process that insert data for clients using multithreading.
Need to update a client database in a short period of time.There is an application that does the job but it's single threaded.Need to make it multithread.
The idea being is to insert data in batches using the existing application
EG
Process 50000 records
assign 5000 record to each thread
The idea is to fire 10-20 threads and even multiple instance of the same application to do the job.
Any ideas,suggestions examples how to approach this.
It's .net 2.0 unfortunately.
Are there any good example how to do it that you have come across,EG ThreadPool etc.
Reading on multithreading in the meantime
I'll bet dollars to donuts the problem is that the existing code just uses an absurdly inefficient algorithm. Making it multi-threaded won't help unless you fix the algorithm too. And if you fix the algorithm, it likely will not need to be multi-threaded. This doesn't sound like the type of problem that typically benefits from multi-threading itself.
The only possible scenario I could see where this matters is if latency to the database is an issue. But if it's on the same LAN or in the same datacenter, that won't be an issue.