[Mono-dev] Remoting and thread pool limits
pablosantosluac
pablosantosluac at terra.es
Sun Dec 16 08:35:25 EST 2007
Hi Robert,
Here are my numbers on a Linux (Xeon) box:
[CODICE\pablo at juno client]$ /opt/mono/bin/mono client.exe
tcp://localhost:10020/remote
1 - Time 1296 ms
5 - Time 1023 ms
10 - Time 1025 ms
20 - Time 1031 ms
40 - Time 1041 ms
50 - Time 1041 ms
200 - Time 10126 ms
As you mentioned I can't currently understand the "hit" when creating 200
threads because if you try to create them in a standalone application (a
loop launching 1000 threads), it works perfectly... but doing remoting (I
don't know where the problem can be), the impact is quite high... ¿Something
socket related? (I doubt it!)
I'll take another look into the channel's code.
Regards,
pablo
----- Original Message -----
From: "Robert Jordan" <robertj at gmx.net>
To: <mono-devel-list at lists.ximian.com>
Sent: Saturday, December 15, 2007 9:25 PM
Subject: Re: [Mono-dev] Remoting and thread pool limits
> pablosantosluac wrote:
>> Well, it is not a *bug* but a feature. I wonder if it should be changed.
>> If
>> you look into RemotingThreadPool.cs there is a line like:
>>
>>
>> threadDone.WaitOne(PoolGrowDelay, false);
>>
>>
>> This one is actually the one making the process too slow. I'm afraid it
>> must
>> be something similar on the .NET code too!
>>
>> Of course removing this line the problem gets solved, but I guess there
>> is a
>> reason in the channel to do that.
>
> I noticed that too, but this doesn't solve the real problem: the 200
> thread test is still too slow on my machine. The degradation seems to
> start after 60-80 threads on my pretty weak SMP machine.
>
> Just to be sure, I've replaced RemotingThreadPool with an own, simple
> version based on the standard BCL ThreadPool => same issue, although
> I've raised the env var MONO_THREADS_PER_CPU to an insane value.
>
> Robert
>
>>
>>
>> pablo
>>
>>
>> ----- Original Message -----
>> From: "Robert Jordan" <robertj at gmx.net>
>> To: <mono-devel-list at lists.ximian.com>
>> Sent: Saturday, December 15, 2007 4:12 PM
>> Subject: Re: [Mono-dev] Remoting and thread pool limits
>>
>>
>>> Hi,
>>>
>>> pablosantosluac wrote:
>>>> Hi,
>>>>
>>>> I've found the following difference working with .NET and Mono
>>>> remoting.
>>>> In
>>>> .NET when the remoting ThreadPool reaches the pool's maximum (25
>>>> threads
>>>> per
>>>> process), it is able to continue creating new threads. In fact, you can
>>>> end
>>>> up having a remoting server with hundreds of threads.
>>>>
>>>> In mono the behaviour is different. Once the limit is reached it starts
>>>> refusing connections.
>>> This is unrelated to mono's remoting thread pool. You have probably
>>> ran your tests on Windows, where mono indeed fails with a GC failure
>>> when too many threads are created because the GC has a hard coded
>>> max thread count limit.
>>>
>>> On Linux (x86_64, Mono 1.2.6) I can finish the tests:
>>>
>>> Linux Mono client -> Linux Mono server (same machine)
>>>
>>> poseidon [~/foo] $ mono client/bin/Debug/client.exe
>>> tcp://localhost:8084/remote
>>> 1 - Time 1206 ms
>>> 5 - Time 2045 ms
>>> 10 - Time 3575 ms
>>> 20 - Time 8174 ms
>>> 40 - Time 12055 ms
>>> 50 - Time 8185 ms
>>> 200 - Time 46150 ms
>>>
>>>
>>> MS.NET client -> Linux Mono server (different machines)
>>>
>>> troll:/cygdrive/u/foo/client/bin/Debug $ ./client.exe
>>> tcp://poseidon:8084/remote
>>> 1 - Time 1297 ms
>>> 5 - Time 2000 ms
>>> 10 - Time 3515 ms
>>> 20 - Time 6016 ms
>>> 40 - Time 11031 ms
>>> 50 - Time 6016 ms
>>> 200 - Time 94375 ms
>>>
>>>
>>> The numbers don't look very well, though. I promise to look at
>>> this when you file a bug report so that it doesn't get
>>> overlooked.
>>>
>>> Robert
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
More information about the Mono-devel-list
mailing list