Well in your described situation it is indeed foolish to use multithreading
( if it is only about static data retrieval )
However what if the business logic is on the server ? ( as it is more and
more the case nowadays , thanks to webservices , remoting and COM+
architecture )
Instead of waiting for a transaction to finish you could already send or
process another piece of information
even better a "Good" programmer starts the longest running task first and
then starts all subsequent tasks in order of longest running time
in a ideal situation the total processing time on the client is now the time
of the longest running process while in a single threaded architecture
the total processing time is at least the sum of all tasks.
But indeed "most" people use multithreading / asynchronous processing in a
bad way and forget that one person running 100 meters is almost ever faster
as 10 persons running 10 meters , but as i said in some situations the
opposite is true let say we talk now about 50.000 meters who is now faster
?? ( unless he comes from Kenia or Ethiopia :-) .
So in the end it all comes down in rightly defining the solution`s
architecture
regards
Michel Posseth [MCP]
"Cor Ligthert [MVP]" <no************@planet.nl> schreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
Mischel,
Describe where I am in your opinion wrong.
Suppose I want 1000 parts of data.
I get this from a server over whatever line.
The bottleneck is mostly the line but can be of course somewhere else
Suppose I create 1000 threads to get everytime 1 piece of data.
Where is than my benefit because the data has sequential to pass the
smallest part of the pipeline (Can be by instance as well the processing
ability (speed etc) of the Server).
I know situations where it can be benefited beside what I wrote already if
there are more suppliers.
That is where there are supporting more connections per user but where the
maximum throughput per connection is limited by a certain bandwidth.
Because that stupid situation has everybody made multithreading programs
for that. Therefore I assume that in those cases in future that the
connections will be limited per user. As sample this is the fact by
downloadaccelarators (As they are using more downloadservers than it is
fine, than they fall in the category I have described in my first
message).
But from what was written I had not the idea that it was about such a kind
of downloadaccelarator.
Cor
"Michel Posseth [MCP]" <MS**@posseth.com> schreef in bericht
news:e1**************@TK2MSFTNGP04.phx.gbl...
IMHO in a server based architecture this is not the case Cor and i
believe that is where the TS is talking about
With SOA designs this is exact one of the few situations were
multithreading really can give you a performance benefit
regards
Michel Posseth [MCP]
"Cor Ligthert [MVP]" <no************@planet.nl> schreef in bericht
news:uq**************@TK2MSFTNGP05.phx.gbl... Melton,
Don't expect that with threading you can speed up processes which have a
serial botleneck.
There cannot go more water through a pipe than its through its smallest
part.
The same is with data. Now your process takes 1.5ms. With the threads it
will take probably more just because that the throughput is interupted
and that your webservice is probably handling more users in a sequential
way, therefore you have introduced extra waittimes.
Your smallest part is not widened up by threading. (Or you should have
different independent working webservice on more locations).
Just my thought,
Cor
<me*****@hotmail.com> schreef in bericht
news:11**********************@f6g2000cwb.googlegro ups.com...
Sorry, I think I misspoke. I am building an app on the user side to
access a webservice. I think I've figured out how to run the form
separately using BeginInvoke, but I still haven't solved the requests.
Is it even possible to send 3 at the same time or will it run 1 then
the next etc? It takes about 500ms to recieve the response and
process. So if I were able to manage to send all 3 requests at the
same time then I would probably have to put a thread.sleep(600) on the
ui update thread. Otherwise its going to take about 1.5 seconds to run
all 3 in line.
Any ideas? If I have to run them in line then I will, but I would
rather try and speed this up.
