hello
i got ajax call to a webmethod performing one linear task - which is getting data from mongoDB database(the new driver which is all async!), calculate the data, and return result.
is there is any point to use multithreading on handling the database cal?
is there is any point to use multithreading on handling the database cal?
Generally, you are going to want your database calls / access to be somewhat synchronous (at least in a sense) as otherwise you can run into possible concurrency issues that come along with multithreading. As long as you aren't building the threads on your
own and creating these requests, you should probably be fine (i.e. just using the built in async/await behaviors and making these calls either through server-side events or AJAX calls).
It's not something that you have to do or that you might even see any type of significant benefit from though.
If you measure where the time is being taken and find that the process is CPU bound (which seems very, very unlikely) then you could look into multithreading in an effort to devote more resources to the problem.
On the other hand, if you measure and discover that the majority of the time is taken waiting for a piece of rust to rotate into place so you can read data from it then there will be no point in multithreading.
Bottom line - find what is taking the time and make that step faster.
My guess which is probably worth less than two cents because you have given us very little information is that the database calling code will take 100 microseconds and getting the data off the disc takes 100 milliseconds. Total elapsed time = 100.1 milliseconds.
You could multithread the database access code and bring the time down to 100.01 milliseconds if you are lucky.
AFAIK it enhances scalability my understanding being that the IO is awaited anyway so rather than having ASP.NET to block on that instead it could serve other requests and resume only when the IO is actually completed. IMO you won't see any difference unless
your site (or server) have a very high traffic. As it seems you are telling the MongoDB driver is now async only, it might be better to ask in a Mongo DB forum what drove this design decision.
It could be interesting for hosting services (by "forcing" async code, they might see benefits we couldn't see at a much lower scale). All this is just a guess.
Member
20 Points
90 Posts
is there is any point to use multithreading on handling the database cal?
Oct 26, 2015 04:58 PM|2xo1|LINK
asp.net.4.5.2
hello
i got ajax call to a webmethod performing one linear task - which is getting data from mongoDB database(the new driver which is all async!), calculate the data, and return result.
is there is any point to use multithreading on handling the database cal?
thanks
All-Star
113110 Points
18367 Posts
MVP
Re: is there is any point to use multithreading on handling the database cal?
Oct 26, 2015 05:19 PM|Rion Williams|LINK
Generally, you are going to want your database calls / access to be somewhat synchronous (at least in a sense) as otherwise you can run into possible concurrency issues that come along with multithreading. As long as you aren't building the threads on your own and creating these requests, you should probably be fine (i.e. just using the built in async/await behaviors and making these calls either through server-side events or AJAX calls).
It's not something that you have to do or that you might even see any type of significant benefit from though.
Member
720 Points
362 Posts
Re: is there is any point to use multithreading on handling the database cal?
Oct 26, 2015 11:37 PM|PaulTheSmith|LINK
If you measure where the time is being taken and find that the process is CPU bound (which seems very, very unlikely) then you could look into multithreading in an effort to devote more resources to the problem.
On the other hand, if you measure and discover that the majority of the time is taken waiting for a piece of rust to rotate into place so you can read data from it then there will be no point in multithreading.
Bottom line - find what is taking the time and make that step faster.
Always worth reading - http://ericlippert.com/2012/12/17/performance-rant/
My guess which is probably worth less than two cents because you have given us very little information is that the database calling code will take 100 microseconds and getting the data off the disc takes 100 milliseconds. Total elapsed time = 100.1 milliseconds. You could multithread the database access code and bring the time down to 100.01 milliseconds if you are lucky.
Member
20 Points
90 Posts
Re: is there is any point to use multithreading on handling the database cal?
Oct 27, 2015 06:03 AM|2xo1|LINK
thank you.
i dont understand:
if there will be the same task journey - for the sync and asnc - what benefit will we gain by adding more threading?
- receive the ajax call
- call for database
- wait for data from database
- calc that data and return.
so if you makeing the database call with an extra worker - you say it might be beneficial?
why? the way i see it it only will use unnecessary cpu resources.
All-Star
40120 Points
12972 Posts
Re: is there is any point to use multithreading on handling the database cal?
Oct 27, 2015 09:52 AM|PatriceSc|LINK
Hi,
AFAIK it enhances scalability my understanding being that the IO is awaited anyway so rather than having ASP.NET to block on that instead it could serve other requests and resume only when the IO is actually completed. IMO you won't see any difference unless your site (or server) have a very high traffic. As it seems you are telling the MongoDB driver is now async only, it might be better to ask in a Mongo DB forum what drove this design decision.
It could be interesting for hosting services (by "forcing" async code, they might see benefits we couldn't see at a much lower scale). All this is just a guess.