[Mono-dev] An asynchronous System.Runtime.Remoting.Channels.Tcp
Hi all Attached is a patch to add an optional asynchronous path for the TCP remoting channel server. The main benefit we see with this change is in reliability; when a single server is servicing many clients at once (we test with over 100) with large data transfers the standard synchronous channel will often drop connections. We tracked this down to the Accept() call in TcpServerChannel.cs not being able to get to incoming connections quickly enough. I was hoping that throughput of large transfers might be improved by using the threadpool's asynchronous sockets support, but it turns out that performance is pretty much the same as the current implementation. Any comments/suggestions for improvement? - Dick remoting.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] An asynchronous System.Runtime.Remoting.Channels.Tcp
Hello, I like this patch very much, and I like that the way to enable it is through the new "run_async" configuration option. My only feedback is that I believe this is a nice enough feature that it deserves at least: * A blog entry announcing it, linking to: * A page on the Wiki with an explanation of what it does, and how to use it. Miguel. > Hi all > > Attached is a patch to add an optional asynchronous path for the TCP > remoting channel server. > > The main benefit we see with this change is in reliability; when a > single server is servicing many clients at once (we test with over > 100) with large data transfers the standard synchronous channel will > often drop connections. We tracked this down to the Accept() call in > TcpServerChannel.cs not being able to get to incoming connections > quickly enough. > > I was hoping that throughput of large transfers might be improved by > using the threadpool's asynchronous sockets support, but it turns out > that performance is pretty much the same as the current implementation. > > Any comments/suggestions for improvement? > > - Dick > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] An asynchronous System.Runtime.Remoting.Channels.Tcp
My suggestion would be using a separate ThreadPool for the channel than the one used by the system, since Dick is aware race conditions can happen (deadlocks) between code using the System ThreadPool in the process and the channel. Diff. ThreadPools will fix it. pablo Miguel de Icaza wrote: Hello, I like this patch very much, and I like that the way to enable it is through the new "run_async" configuration option. My only feedback is that I believe this is a nice enough feature that it deserves at least: * A blog entry announcing it, linking to: * A page on the Wiki with an explanation of what it does, and how to use it. Miguel. Hi all Attached is a patch to add an optional asynchronous path for the TCP remoting channel server. The main benefit we see with this change is in reliability; when a single server is servicing many clients at once (we test with over 100) with large data transfers the standard synchronous channel will often drop connections. We tracked this down to the Accept() call in TcpServerChannel.cs not being able to get to incoming connections quickly enough. I was hoping that throughput of large transfers might be improved by using the threadpool's asynchronous sockets support, but it turns out that performance is pretty much the same as the current implementation. Any comments/suggestions for improvement? - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] An asynchronous System.Runtime.Remoting.Channels.Tcp
Hi, Dick and I were talking about the possible race conditions (we've found one on our code) that the system ThreadPool can have when used from the channel and the code (remember the *current* tcp channel does not use the system threadpool but a custom and really simple one). Would it be possible to use two different thread pools instantiating the system ones? Also, would it be possible to commit this code? Another related idea: it is possible (I think) to greatly improve the current TcpChannel by returning threads to the pool when they're waiting at PlasticTcpClientConnection.ProcessMessages. The problem right now is that each client connection will create a thread on the server and the thread won't be returned to the pool until the client closes the connection, even if it's just waiting for data. This is not good for high-perf environments were many requests must be processed, since a huge number of threads could be potentially spawned. My idea would be: we already have a thread for the "socket accept", create a new one for Socket.Select, so that threads are returned to the pool (and its socket passed to the Socket.Select call) and then the method ProcessMessages would be called again when "select" returns. It's not like a full asynch channel but I think it can be even better on most situations (less overhead) and it will greatly improve responsiveness. pablo www.plasticscm.com Dick Porter wrote: > Hi all > > Attached is a patch to add an optional asynchronous path for the TCP > remoting channel server. > > The main benefit we see with this change is in reliability; when a > single server is servicing many clients at once (we test with over 100) > with large data transfers the standard synchronous channel will often > drop connections. We tracked this down to the Accept() call in > TcpServerChannel.cs not being able to get to incoming connections > quickly enough. > > I was hoping that throughput of large transfers might be improved by > using the threadpool's asynchronous sockets support, but it turns out > that performance is pretty much the same as the current implementation. > > Any comments/suggestions for improvement? > > - Dick > > > > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
