Thanks Jeremy for your update... an interesting piece of information. On Tue, Apr 1, 2008 at 4:59 AM, Jeremy Byron <[EMAIL PROTECTED]> wrote:
> Grr...stupid spell checker. That's supposed to be "handle other > remoting requests", not "removing requests" > > Jeremy > > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Byron > Sent: Monday, March 31, 2008 2:58 PM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Remoting, Threading and Concurrency > > > Hi All, > > Just wanted to update the list with my test results. > > I modified my test to offload the blocking process to another server. So > the CPU stays low on my test machine (single processor machine). When I > do this, everything works well. So it looks like everyone was right. > When the CPU was kept high during my test, the thread pool wouldn't > create a new thread to handle other removing requests. But as long as > the CPU is not busy, new requests are handled. > > This is great. The exact answer I was hoping for. > > Thanks to all who helped out. > > Jeremy > > > > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Byron > Sent: Tuesday, March 25, 2008 4:41 PM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Remoting, Threading and Concurrency > > > 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:[EMAIL PROTECTED] 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://www.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<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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > > 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/> > > > > > > View archives and manage your subscription(s) at > > > http://discuss.develop.com <http://discuss.develop.com/> > > > > > > > =================================== > > This list is hosted by DevelopMentor(R) http://www.develop.com < > > http://www.develop.com/> > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com <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(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(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 > -- Cheers, Jason =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
