dotnet remoting: Best Practices -- dotnet remoting

Re: Best Practices

Allen Anderson
3/29/2004 9:56:46 AM

dotnet remoting:

Use a single service to host all of your objects. You won't get any
performance benefit from multiple services hosting objects. However,
if several services would be easier to manage (although I can't
imagine why) then you can go in that direction as there is really no
performance problem doing it this way.

Allen Anderson
http://www.glacialcomponents.com
mailto: allen@put my website url here.com

On Mon, 29 Mar 2004 10:40:56 +0200, "Mark" <M.Brouwers@NoSpam.lag.be>
[quoted text, click to view]

Best Practices

Mark
3/29/2004 10:40:56 AM

Hi,

I'm working onan enterprise application and I wondering what the best way is
to implement remoting hosted by windows services. Should I use 1 service
that hosts all my remote objects or should I divide the remoting of object
over several windows services ? I know that I must keep in mind the aspect
of managebility, scalability and performance. Several services is easier to
manage, but what with the performance and stability ? Are serveral services
more stable than one ? I personal think that using more services results in
a more stable system. Is this correct?
Has anyone got any experience implemeting such scenario?

TIA,
Mark

Re: Best Practices

Mark
3/30/2004 10:06:15 AM

Allen, thanks for the reply.
The reason that I want to split up my services is the fact that it seems
that one of my service crashes (stops working) when it reaches +/- 1100
calls/sec (in the performance monitor the graph drops down to 0). When I
have only one service, the whole of my application would stop working.
Maybe you can help me explain why the service stops handling remote calls.
I'm using single call objects, added a lease.
Is it the number of threads from the threadpool, ...?
Any help would be much appreciated.

Mark
[quoted text, click to view]

Re: Best Practices

Ice
3/31/2004 8:28:50 AM

I disagree with Allen's blanket statement. I think you need to evaluate
your situation. Multiple hosts allow you to more flexible in areas of
deployment and scalability. Fault-tolerance is also something that should
be taken into consideration. If the service goes down, should the entire
system also go down? There is a finite number of threads per process. You
can theoretically exhaust the threads available for your use.

You need to weigh the above with penalty you suffer from out-of-proc calls.
These can get quite expensive.

I am not campaigning for multiple services, but I think you need to decide
how many you need based on certain criteria. Best practices are not an
island, they are dependant on the situation.

ice
[quoted text, click to view]

Re: Best Practices

Allen Anderson
3/31/2004 10:01:10 AM

hey Mark, getting up to that number of connections and calls per
second I'm not sure remoting is the best answer. I don't think I've
tested a singlecall server/service where I was dealing with more than
200 or so calls per second. Maybe some other community member might
have used this scenario that could shed some light on this.

If you are really pushing performance and you don't want to start
clustering servers you might want to consider switching to sockets and
overlapped IO.

Allen Anderson
http://www.glacialcomponents.com
mailto: allen@put my website url here.com

On Tue, 30 Mar 2004 10:06:15 +0200, "Mark" <M.Brouwers@NoSpam.lag.be>
[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet remoting group.