I will try to post my findings optimizing the Tcp Channel.

Basically, a huge boost is possible, under heavy load (>100 concurrent
connections, tested with 1200, 1500 and so on), making the initial read
async, so you decouple conns from server threads, even if the rest of
the message reading is sync. This is step one.

Next is clearly limiting the number of worker threads: do not attend the
request on the same IOCP thread or threadpool thread but with an
specific pool of worker threads, so you're attending all requests with
2,3 threads per core, not more. A server with 300-400 or more threads is
only making things even worse.

On 16/03/2012 19:08, gelin yan wrote:
> 
> 
> On Sat, Mar 17, 2012 at 2:03 AM, [email protected]
> <mailto:[email protected]> <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     Ok: the problem is that I was wrapping the NetworkStream with a
>     BufferedStream, and BufferedStream is not async in Mono, while it is
>     async in .NET
> 
>     :(
> 
> 
> 
>     On 16/03/2012 16:57, [email protected]
>     <mailto:[email protected]> wrote:
>     > Hi,
>     >
>     > I'm working on some changes to make the TcpChannel work in async mode.
>     >
>     > Instead of changing all the reads and writes to async, I'm just
>     > modifying the intial message status read to async, so instead of
>     having
>     > a pile of threads waiting for IO on the server (waiting for clients to
>     > call or disconnect), there will be only as few threads as running
>     methods.
>     >
>     > It works great on Windows even under huge load (I'm testing on a
>     > 100-nodes cluster on EC2).
>     >
>     > But, now, trying on Linux simply fails because this call:
>     >
>     > networkStream.BeginRead(buffer, 0, 6, callback, null);
>     >
>     > where networkStream is System.Net.Sockets.NetworkStream
>     >
>     > locks.
>     >
>     > What it actually does is to block and then invoke the callback, but it
>     > doesn't go through until the callback finishes, which I think is
>     not the
>     > desired behavior.
>     >
>     > I'm running:
>     > Mono JIT compiler version 2.10.2 (tarball Mon Apr 18 15:12:52 UTC
>     2011)
>     > Copyright (C) 2002-2011 Novell, Inc and Contributors.
>     www.mono-project.com <http://www.mono-project.com>
>     >     TLS:           __thread
>     >     SIGSEGV:       altstack
>     >     Notifications: epoll
>     >     Architecture:  amd64
>     >     Disabled:      none
>     >     Misc:          debugger softdebug
>     >     LLVM:          yes(2.9svn-mono)
>     >     GC:            Included Boehm (with typed GC and Parallel Mark)
>     >
>     > It fails with older monos too.
>     >
>     > Obviously I'm doing something wrong.
>     >
>     > Is there a way I can fix it?
>     >
>     > Thanks,
>     >
>     > pablo
>     > _______________________________________________
>     > Mono-devel-list mailing list
>     > [email protected]
>     <mailto:[email protected]>
>     > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>     >
>     _______________________________________________
>     Mono-devel-list mailing list
>     [email protected]
>     <mailto:[email protected]>
>     http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 
> Hi.. Is it possible to post some benchmarks for that once you fixed your
> bugs.  I am interested in using async socket with mono on Linux..thx.
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> [email protected]
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Reply via email to