[Mono-dev] Memory usage on Mono remoting

[pablosantosluac at terra.es]

Hi Gonzalo,

First, thanks for the detailed answers.


>> Considering Boehm GC seems to have really hard times releasing memory
>> and we're delivering GBs of data... it could be.
>>     
>
> Delivering GBs of data and having hundreds of connections should not be
> a problem. Years ago, when testing iFolder under those conditions
> everything worked just fine. But it was mod-mono-server/apache.
>
>   
Dick is actually checking this. I hope it's not the issue.
>> I'm not 100% sure, but it seems reusing buffers could be a very good idea.
>>     
>
> Xsp does it too and it's much better than allocating 32kB for every
> request every time.
>
>   
Good.
>> 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?
>>     
>
> Your guess is wrong. Those asynchronous calls from Socket are treated as
> if they were a WorkItem for a ThreadPool, only that when they are made,
> the socket is added to an epoll fd (if you're on linux with support for
> epoll). And when there's an event in the socket, there's a dedicated IO
> threadpool to take care of reading/writing data and invoking the
> callbacks. The advantages: if you have 10k connections, you don't need
> 10k threads, threads are reused (no creation overhead), ...
>
>   
Ok, of course. Well, when I said "launching a thread" I really meant
"launching a thread on a thread pool".

Well, I'll try to use the ansync sockets then, but I guess to get the
best out of them I'll need not only to use them during accept, but also
read data asynchronously, right?

BTW, I already replaced the built-in remoting threadpool by the
System.Threading one.


>> 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?
>>     
>
> Coupled with asynchronous I/O, it will make better use of the resources
> available. There's no need to create 100 threads for 100 client or
> having 1 threadpool thread blocking on a socket asynchronous
> operation,... Also, if you're thinking of reusing buffers, this helps
> too, as the number of buffers will be bound to the maximum number of
> threads in the threadpool, ...
>   
Good, so, whenever I wait for a read or a write using async, the thread
should be able to work on another request?

I think this is the way it's implemented on Windows, but I can tell you
it is still created a huge number of threads, almost 1-1 with clients
under the most overloaded scenarios.


Thanks,

pablo


> -Gonzalo
>
>
>
>
>