[Mono-dev] Memory usage on Mono remoting

[pablosantosluac at terra.es]

Hi Gonzalo,

>> Testing PlasticSCM under really heavy load (hundreds of clients against
>> a single server delivering hundreds of Gb over the network).
>>     
>
> So no profiling...
>
>   
Comparing the same code, the same hardware and the same test under Linux
and Windows. On Windows we run under .NET, and the test passes successfully.

Dick (in CC) is looking into GC problems.

>>> System.Web uses unmanaged chunks of memory together with an unmanaged
>>> memory based stream.
>>>   
>>>       
>> That's what I need. Can you point me to the right class?
>>     
>
> It's HttpResponseStream.cs all the *Bucket classes that then use an
> IntPtrStream.
>
> I still don't think that allocating MemoryStream (256 bytes by default)
> is hurting that bad. 
Considering Boehm GC seems to have really hard times releasing memory
and we're delivering GBs of data... it could be.

I'm not 100% sure, but it seems reusing buffers could be a very good idea.

> A wild guess is that the BufferedStream wrapping
> the NetworkStream is allocating much more memory (4kB by default). But
> if the code is rewritten following what xsp does, this should not be a
> problem any more.
>   
Ok, I'm not familiar with xsp, I'll take a look.

I've just noticed that you use "send" from libc instead of the socket
functions... I guess it is due to performance reasons, right?

Also, you mentioned in a previous email that the TcpChannel should be
changed so it uses Asynch sockets. I've seen you use AsyncCallBack on XSP.

My question is: I guess AsynchCallback will use a thread underneath,
won't it? If so: what's the advantage over launching threads to accept
calls?

You mentioned it is better to use the default ThreadPool instead of the
internal one in the TcpChannel, why is it going to be better?

Thanks again Gonzalo,

pablo


www.plasticscm.com