[Mono-dev] Memory usage on Mono remoting

[Gonzalo Paniagua Javier]

On Wed, 2009-07-15 at 13:29 +0200, pablosantosluac at terra.es wrote:
[...]
> > 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?

Correct. If possible, Write should also be asynchronous, but as long as
the OS buffers everything, there should be no problem.
[...]
> > 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?

Correct. In fact, you don't 'wait' for an asynchronous read or write.
For instance, when you call BeginRead, the socket is added to an epoll
fd and you BeginRead call returns immediately. The callback you
provided, if any, will be called from a different thread as soon as new
data is available. Just don't spoil it by doing something like
socket.EndRead (socket.BeginRead (...)))   ;-)

> 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.

The number of threads in the current threadpool can be configured using
MONO_THREADS_PER_CPU (see mono(1)) and SetMaxThreads. I don't remember
the numbers, but if you have a dual-quad core, it means ~140 threads. I
would adjust the maximum number of threads until the performance is more
or less the same than if you add a few more threads, but this may vary
depending on what the threads are doing...

-Gonzalo