Hi Conrad,
Thanks for the email.
1 - I agree completely. I'm actually not using the
thread-pool
explicitly. My comments were regarding remoting's built-in
usage of the
thread-pool.
2 - This is very interesting and is probably the explanation
of my
"problem". I will have to do some further
testing.
Thanks again. I will update with my results as soon as I
get a chance
to re-test.
Regards,
Jeremy
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNET DISCUSS.DEVELOP.COM] On Behalf Of Conrad
Frix
Sent: Sunday, March 23, 2008 2:23 PM
To: ADVANCED-DOTNET DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Remoting, Threading and
Concurrency
Jeremy,
If I were you I would eliminate the ThreadPool just to be
sure that's
not your issue. The reason for this is twofold
1) You probably shouldn't be using the ThreadPool for long
running
tasks. From http://w
ww.yoda.arachsys.com/csharp/threads/
"In general, you should create a new thread
"manually" for long-running
tasks, and use the thread pool only for brief jobs. The
thread pool can
only run so many jobs at once, and some framework classes
use it
internally, so you don't want to block it with a lot of
tasks which need
to block for other things. The examples in this article
mostly use
manual thread creation. On the other hand, for short-running
tasks,
particularly those created often, the thread pool is an
excellent
choice"
2) When the CPU untilization is high the pool will block
requests until
the CPU goes down. From
http://blogs.msdn.com/tess/archive/2006/
03/27/net-memory-leak-unblock-my
-finalizer.aspx
We know from previous case studies that the CPU utilization
shows the
CPU utilization of the whole system, not only the CPU
utilization of
this process, how could that possibly have anything to do
with the
threadpool? Well, surprise surprise, it does. This piece of
information
is stored in a variable by the framework because it is one
of the
factors that determine whether or not we will be creating
new threads.
In particular, if the CPU utilization is over 80% we don't
create any
new threads... and this is why we are not creating any new
threads in
this case.
If this doesn't fix your problem. I suggest you get a memory
dump and
use WinDbg to figure out what is blocking your short running
task.
-Conrad
On Sat, Mar 22, 2008 at 12:49 PM, Jeremy Byron
<jbyron intelisys.ca>
wrote:
> Hrm....all valid points. Yes, this is just a test app
and is being
> run all on one machine, single proc (don't ask...I'm
not in charge of
> purchasing .
>
> I'll try splitting it out and maybe using a db call for
the "long
> running" process. See if it picks up another
thread while waiting for
> db to return (that's my biggest concern. I don't want
my machine
> sitting and waiting for a long-running db call to
return).
>
> Jeremy
>
> ________________________________
>
> From: Discussion of advanced .NET topics. on behalf of
Stoyan Damov
> Sent: Thu 3/20/2008 5:59 PM
> To: ADVANCED-DOTNET DISCUSS.DEVELOP.COM
> Subject: Re: [ADVANCED-DOTNET] Remoting, Threading and
Concurrency
>
>
>
> Surely you want SingleCall, not Singleton.
>
> Couple of questions:
>
> Q1: How many machines you're using for the test (I
guess 1 for test
> client and 1 for server)? If 1, then not sure what
you're testing but
> maybe Q2 needs an answer.
>
> Q2. What's your machine like and particularly how many
CPUs?
> Hint: if you say 1 wtf , if 2,
then think about it (you have 1 UI
> thread
> +
> 2 background threads + at least one for GC +at least 1
main on
> server-side
> +
> 1 GC...) but in any case Q3 needs an answer
>
> Q3. What does "loops for N seconds" mean - do
you actually spin loop
like:
> while (current time - start time < timeout) { }?
> If yes, then depends on previous answer, but in any
case Windows sucks
> BIG TIME (compared to, say, Solaris) with thread
switching, where even
> 1 thread spin loops like that.
>
> HTH
>
> Cheers,
> Stoyan
>
> On Thu, Mar 20, 2008 at 3:30 PM, Jeremy Byron
<jbyron intelisys.ca>
> wrote:
>
> > Hello everyone,
> >
> > I have been struggling with this for a few weeks
now. I have
> > searched on the web high and low, purchased
"advanced" remoting
> > books, searched newsgroups and these discussion
group's archives. I
> > see hints of explanations/solutions, but nothing
that seems to work
> > or explain what is going on.
> >
> > We are not doing anything special. We are just
trying to create
> > some objects that will be remoted and accessed by
WinForms clients
> > and ASP.NET <http://asp.net/> clients.
But we are noticing that the
> requests are being
> > processed on the server sequentially. So
basically, the remoting
> > object processes one call at a time, with
concurrent requests
> > blocking.
> >
> > I have created a test project (source is
available, but I suspect
> > someone will be able to answer this without
needing to see the
> > source. This seems like such a basic issue I'm
sure someone has some
> > insight). Very basic.
> >
> > One remoted object - two methods:
LongRunningProcess() and
> > ShortRunningProcess()
> > Server is Console app - just sets up the remoting
and remotes the
> > one object (no config file, all done via code)
Client is a WinForms
> > application. Single form with two buttons, one
for each of the
> > methods (and a corresponding textbox to see the
results). Each
> > button spawns a worker thread to make the remote
call, so calls are
> > not blocking on client-side. Using TCP/Binary
channel/formatter.
> >
> > Each of the remote functions is the same, enter a
tight loop for a
> > specified period of time then return a string with
time loop
> > started, time loop ended, thread id and threadPool
status of each
> > thread. LongRunning just loops for 30 seconds and
shortRunning loops
> > for 3.
> >
> > So here's the problem.
> >
> > When I run the test, I click "Start Long
Running" then immediately
> > click "Start Short Running". After 30
seconds, the LongRunning
> > returns, then 3 seconds later ShortRunning
returns. Server Thread
> > IDs are the same and it is a threadpool thread.
(Client ThreadIDs
> > are different
> > obviously) Obviously the calls are blocking so
the remoting host
can
> > only process one request at a time???
> >
> > Now, I try putting a "Thread.Sleep(250)"
in the loop of the long
> > running, now when I click my two buttons,
ShortRunning returns after
> > 3 seconds and LongRunning returns after 30 seconds
and they both
> > have different threadIDs and both threads are
threadPool threads.
> >
> > I was under the impression that on the remoting
server side, the
> > requests were handled via the threadpool and hence
did not block
> > each other. But from my results it sounds more
complicated then
> > that. It would seem to be quite detrimental to
throughput to have
> > requests blocking each other like this. And I
would think that if
> > it was a requirement for me to spawn worker
threads in my
> > remotedObject (or use the sleep method) that would
be documented
> > somewhere. But I've never seen it anywhere.
> >
> > I've tried using SingleCall and Singleton for my
remoted object (one
> > post I read said Singleton was multi-threaded
whereas Singlecall was
> > not). I've even tried changing my host to IIS
(and using the
> > remoting config file) with the same results.
> >
> > Does anyone have any insight on how to get my
object to process
> > requests concurrently?
> >
> > Thanks in advance.
> >
> > Jeremy
> >
> > ===================================
> > This list is hosted by DevelopMentor(R) http://www.develop.com
<
> http://www.develop.com/&g
t;
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
<http://discuss.develo
p.com/>
> >
>
> ===================================
> This list is hosted by DevelopMentor(R) http://www.develop.com
<
> http://www.develop.com/&g
t;
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
<http://discuss.develo
p.com/>
>
>
>
> ===================================
> This list is hosted by DevelopMentor(R) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
|