| Groups | Blog | Home |
dotnet performance : TCP/Binary Remoting and Perf Problems
Our deployement consists of web server (dual processor) and application
server (dual processor). The ASP.NET web application makes remoting (Tcp/Binary) calls into a window service (our own) hosted on application server. During our load testing, we found that there is huge gap in time during cross machine call. We made sure the appliction server is not really taking all the time to servicing the request. We used .NET profiler to find out this. Now the question is what is going on between two machines that is causing this delay. We checked the network pipe between two machines. It is not being used to the capacity. This really did not make sense. So we moved window service to the web server and tested again. The problem persisted. The CPU time stayed below 70% and we don't see any I/O or page faults. Has any come across this kind of problems? I would appreciate any comments or suggestions. Thanks. Raghu/..
[quoted text, click to view] "Raghu" <Raghu@nospamzzzqcsi.com> wrote in message news:ODbHgOp5DHA.1368@TK2MSFTNGP10.phx.gbl... > Our deployement consists of web server (dual processor) and application > server (dual processor). The ASP.NET web application makes remoting > (Tcp/Binary) calls into a window service (our own) hosted on application > server. During our load testing, we found that there is huge gap in time > during cross machine call. We made sure the appliction server is not really > taking all the time to servicing the request. We used .NET profiler to find > out this. Hmm. A web server _is_ an application server. Are you under the impression that using remoting to communicate between your aspx pages and your business components is a normal thing to do? Do you think that remoting is magical and free? Looking at your performance counters, what is the rate of -.NET CLR Remoting/Remote Calls/sec? -System/Context Switches/sec? -ASP .NET Apps v1.1.14322/Requests/sec? When you run your application components inside aspnet_wp what do these metrics look like? What is your target for Requests/sec? What does the interface for your remote objects look like? David Use these metrics to figure out: how many
How big is the gap you are talking about?
Nat [quoted text, click to view] "Raghu" <Raghu@nospamzzzqcsi.com> wrote in message news:ODbHgOp5DHA.1368@TK2MSFTNGP10.phx.gbl... > Our deployement consists of web server (dual processor) and application > server (dual processor). The ASP.NET web application makes remoting > (Tcp/Binary) calls into a window service (our own) hosted on application > server. During our load testing, we found that there is huge gap in time > during cross machine call. We made sure the appliction server is not really > taking all the time to servicing the request. We used .NET profiler to find > out this. > > Now the question is what is going on between two machines that is causing > this delay. We checked the network pipe between two machines. It is not > being used to the capacity. This really did not make sense. So we moved > window service to the web server and tested again. The problem persisted. > The CPU time stayed below 70% and we don't see any I/O or page faults. > > Has any come across this kind of problems? I would appreciate any comments > or suggestions. > > Thanks. > Raghu/.. > >
On average, we are seeing about 3.5 seconds.
[quoted text, click to view] "Nat" <asd@asd.com> wrote in message news:uhLgQEu5DHA.2692@TK2MSFTNGP09.phx.gbl... > How big is the gap you are talking about? > > Nat > > "Raghu" <Raghu@nospamzzzqcsi.com> wrote in message > news:ODbHgOp5DHA.1368@TK2MSFTNGP10.phx.gbl... > > Our deployement consists of web server (dual processor) and application > > server (dual processor). The ASP.NET web application makes remoting > > (Tcp/Binary) calls into a window service (our own) hosted on application > > server. During our load testing, we found that there is huge gap in time > > during cross machine call. We made sure the appliction server is not > really > > taking all the time to servicing the request. We used .NET profiler to > find > > out this. > > > > Now the question is what is going on between two machines that is causing > > this delay. We checked the network pipe between two machines. It is not > > being used to the capacity. This really did not make sense. So we moved > > window service to the web server and tested again. The problem persisted. > > The CPU time stayed below 70% and we don't see any I/O or page faults. > > > > Has any come across this kind of problems? I would appreciate any comments > > or suggestions. > > > > Thanks. > > Raghu/.. > > > > > >
Well, it can be application server, if you architect it that way. We simply
chose not to. We know for sure is that ASP.NET requests are not being backed up. This tells us that it is not the bottle neck or we are not putting enough stress on it. We sort of follow the IDispatch methodology (don't ask me why, I am not the author). The request type along with parameters is passed into a dataset as shown below: Public DataSet IDatasetRequest(DataSet ds); The service simply implements the interface with this method and returns dataset based on the request type. "David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in message news:etu4lhu5DHA.1664@TK2MSFTNGP11.phx.gbl... [quoted text, click to view] > > "Raghu" <Raghu@nospamzzzqcsi.com> wrote in message > news:ODbHgOp5DHA.1368@TK2MSFTNGP10.phx.gbl... > > Our deployement consists of web server (dual processor) and application > > server (dual processor). The ASP.NET web application makes remoting > > (Tcp/Binary) calls into a window service (our own) hosted on application > > server. During our load testing, we found that there is huge gap in time > > during cross machine call. We made sure the appliction server is not > really > > taking all the time to servicing the request. We used .NET profiler to > find > > out this. > > Hmm. A web server _is_ an application server. Are you under the impression > that using remoting to communicate between your aspx pages and your business > components is a normal thing to do? Do you think that remoting is magical > and free? > > Looking at your performance counters, what is the rate of > > -.NET CLR Remoting/Remote Calls/sec? > > -System/Context Switches/sec? > > -ASP .NET Apps v1.1.14322/Requests/sec? > > When you run your application components inside aspnet_wp what do these > metrics look like? > > What is your target for Requests/sec? > > What does the interface for your remote objects look like? > > > > David > > > > > Use these metrics to figure out: how many > >
Hi,
Remoting DataSets is most likely where you are having your performance problems. Regardless of the Channel/Formatter DataSets are always serialized in XML format and for untyped DataSets the XSD is serialized along with it. Hope this helps -- Chris Taylor http://dotnetjunkies.com/WebLog/chris.taylor/ [quoted text, click to view] "Raghu" <Raghu@nospamzzzqcsi.com> wrote in message news:%23PBf6pz5DHA.2656@TK2MSFTNGP11.phx.gbl... > Well, it can be application server, if you architect it that way. We simply > chose not to. We know for sure is that ASP.NET requests are not being backed > up. This tells us that it is not the bottle neck or we are not putting > enough stress on it. > > We sort of follow the IDispatch methodology (don't ask me why, I am not the > author). The request type along with parameters is passed into a dataset as > shown below: > > Public DataSet IDatasetRequest(DataSet ds); > > The service simply implements the interface with this method and returns > dataset based on the request type. > > "David Browne" <davidbaxterbrowne no potted meat@hotmail.com> wrote in > message news:etu4lhu5DHA.1664@TK2MSFTNGP11.phx.gbl... > > > > "Raghu" <Raghu@nospamzzzqcsi.com> wrote in message > > news:ODbHgOp5DHA.1368@TK2MSFTNGP10.phx.gbl... > > > Our deployement consists of web server (dual processor) and application > > > server (dual processor). The ASP.NET web application makes remoting > > > (Tcp/Binary) calls into a window service (our own) hosted on application > > > server. During our load testing, we found that there is huge gap in time > > > during cross machine call. We made sure the appliction server is not > > really > > > taking all the time to servicing the request. We used .NET profiler to > > find > > > out this. > > > > Hmm. A web server _is_ an application server. Are you under the > impression > > that using remoting to communicate between your aspx pages and your > business > > components is a normal thing to do? Do you think that remoting is magical > > and free? > > > > Looking at your performance counters, what is the rate of > > > > -.NET CLR Remoting/Remote Calls/sec? > > > > -System/Context Switches/sec? > > > > -ASP .NET Apps v1.1.14322/Requests/sec? > > > > When you run your application components inside aspnet_wp what do these > > metrics look like? > > > > What is your target for Requests/sec? > > > > What does the interface for your remote objects look like? > > > > > > > > David > > > > > > > > > > Use these metrics to figure out: how many > > > > > >
Hello!
We had a performance problem with remoting, where using the hostname of the target server would yield approx. 4 seconds delays. Entering the IP address directly eliminated the delay. Not sure this related to your problem, but I suggest you give it a try. We found this to be related to the internal DNS setup. -- venlig hilsen / with regards anders borum --
Hi Anders and others,
take a look at this, it may help you solve your problem: http://www.genuinechannels.com/Content.aspx?id=20&type=1 Sunny In article <ez9Yvck6DHA.696@tk2msftngp13.phx.gbl>, na@na.na says... [quoted text, click to view] > Hello!
> > We had a performance problem with remoting, where using the hostname of the > target server would yield approx. 4 seconds delays. Entering the IP address > directly eliminated the delay. > > Not sure this related to your problem, but I suggest you give it a try. We > found this to be related to the internal DNS setup. >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |