.Net Remoting performance issue

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Fred - 04 Sep 2007 12:54 GMT

We are currently facing an issue with .Net Remoting connected application,
here is the situation:

We have a central server running some windows services who host some
components exposed with .Net Remoting.

One of them receive lot of calls, an average of 50 calls per second; it
seems that when we go over that amount, it’s an average, the service stop
responding to the client’s requests. We receive the following message “No
connection could be made because the target machine actively refused it” just
like when a service is not running or badly configured.

It’s important to know that when we receive the error message, the CPU usage
of
the server is no more than 50% meaning the CPU isn’t overloaded.

We have tried to increase the thread pool maximum count but that has no
effect.
Its look like the .Net Remoting call queue is full and cannot accept more
requests.

Is there somebody knowing if there is a limit in term of calls to a .Net
remoting?

Can we change that limit? Or something that can help us ?

Many Thanks

Fred

Reply to this Message

Doug Semler - 04 Sep 2007 19:34 GMT

> We are currently facing an issue with .Net Remoting connected application,
> here is the situation:
[quoted text clipped - 25 lines]
>
> Fred

Remoting calls are serviced on the threadpool, and I have seen thread
starvation before. That being said, I can't remember if there was a
hard limit for the number of simultaneous remoting calls.

That being said, If your service is receiving 50 calls per second, it
sounds like your remoting interface is a little chatty. (unless, of
course, you have 50 clients accessing it at one call per second <g>)

Reply to this Message

Fred - 05 Sep 2007 09:12 GMT

> Remoting calls are serviced on the threadpool, and I have seen thread
> starvation before. That being said, I can't remember if there was a
[quoted text clipped - 3 lines]
> sounds like your remoting interface is a little chatty. (unless, of
> course, you have 50 clients accessing it at one call per second <g>)

We have currently more than 400 clients concurrently connected to the
service and sometimes we go over 70 calls second. It's a huge amount clearly
but before starting a split of the services i want to know if I m really
reaching a limit or if I still have something to do to solve the current
issue. I had myself not see a limit somewhere in the doc and before we reach
that huge amount of clients we had never facing that kind of issue (hopefully
for us, the amount of clients still increasing ;-) ).

Reply to this Message

Doug Semler - 05 Sep 2007 17:02 GMT

> > Remoting calls are serviced on the threadpool, and I have seen thread
> > starvation before. That being said, I can't remember if there was a
[quoted text clipped - 11 lines]
> that huge amount of clients we had never facing that kind of issue (hopefully
> for us, the amount of clients still increasing ;-) ).

I would watch the .NET CLR performance counters and the TCP
performance counters (and maybe your Process's counters) to see if
there's anything that sticks out to you.

Also, run a netstat -a the machines. I'm wondering if you haven't hit
the limit of socket connections, and you have a bunch that are in the
TIME_WAIT state...I can't remember offhand the socket allocation
that .NET uses for remoting, but the default limit is something like
4000, and the default TIME_WAIT timeout is something like 120 seconds,
which means that once you hit the limit you can basically start
openning about 33 connections per second...

(more info: http://support.microsoft.com/kb/Q149532)

Reply to this Message

Yuancai (Charlie) Ye - 07 Sep 2007 02:33 GMT

You got performance problem?

See SocketPro for super performance at
http://www.udaparts.com/document/articles/fastsocketpro.htm

> We are currently facing an issue with .Net Remoting connected application,
> here is the situation:
[quoted text clipped - 28 lines]
>
> Fred

Reply to this Message

.Net Remoting performance issue

Free Magazines