Remoting calls MUCH slower than OLEDB calls

[Ron L]

I am working on an application that is a front-end for a SQL database.
While it is not an immediate requirement, the application will probably be
required to be able to connect via the internet at a later date, so we are
implementing the data connections via remoting. The remoting is implemented
via the HTTP channel, with the binary formatter. We have noticed, however,
that the remoting calls seemed to be much slower that the OLEDB calls, so I
wrote a standalone test app and checked. In the test app, the OLEDB calls
get 11583 records in 5 seconds on average, while it takes the remoting over
47 seconds to get the same data. Both the OLEDB and the remoting are
calling the exact same stored procedure with the exact same parameters.

Can anyone tell me why the remoting is so much slower, and how I can make it
faster?

TIA
Ron L.

 

[Keenan Newton]

If I read this right, you are probably still using OLEDB within the
object making the data call, even if you are remoting. Hence I don't
think you will ever get as fast as just the straight OLEDB call.

Remoting will never be as fast as a straight call. My two best
suggestions are bulk load data were possible, and use the TCP channel

 

[Ron L]

Keenan

Thanks for your response. I can understand that remoting will add *some*
overhead to the data request, but it seems odd that it should be 8x. As to
using the TCP channel, we are concerned with portability and firewall
issues. By keeping the HTTP channel we should always be able to get through
the firewall, and we should not have a problem when we are told that we have
to piggyback our server onto an existing windows server.

If the channel will make that much difference in timing, we may have to
re-evaluate our decision, though. Do you have any feel for the difference
in speed between the TCP and HTTP channels?

Ron L

 

[jabailo]

I am working on an application that is a front-end for a SQL database.
While it is not an immediate requirement, the application will probably be
required to be able to connect via the internet at a later date, so we are
implementing the data connections via remoting. The remoting is implemented
via the HTTP channel, with the binary formatter. We have noticed, however,
that the remoting calls seemed to be much slower that the OLEDB calls, so I
wrote a standalone test app and checked. In the test app, the OLEDB calls
get 11583 records in 5 seconds on average, while it takes the remoting over
47 seconds to get the same data. Both the OLEDB and the remoting are
calling the exact same stored procedure with the exact same parameters.

Can anyone tell me why the remoting is so much slower, and how I can make it
faster?

TIA
Ron L.

When you say "get the data" do you mean put the records into the
database? Or are you timing exactly when the data appears at the
remoting server?

If so, there could be many other factors which account for the latency.

 

[Steve Long]

Ron, I've written a remoting app or two using the TCP channel with good
results. I didn't test it against the HTTP channel but even the docs say
that it's going to be slower. If going through a firewall, a VPN should be a
secure bet.

HTH
Steve

 

[nobody]

See this site http://www.udaparts.com/articles/fastsocketpro.htm. Don't send
a large size dataset or table over remoting.

 

[Inge Henriksen]

Make sure that TCP/IP is specified in the connection string, and not Named
Pipes. Named Pipes should not be used over the Internet as it is slow.

Example of TCP/IP (DBMSSOCN) connection string:
"Provider=sqloledb;Data Source=155.200.100,1433;Network
Library=DBMSSOCN;Initial Catalog=pubs;User ID=sa;Password=letmein;"

 

[Cor Ligthert [MVP]]

Ron,

You make me curious, AFAIK a part of the development from Net started with
the idea around the webservice, which seems to be the ultimate solution for
your problem.

Why did you not choose that (although it will as well be slower than a
straigh forward retrieve on your Lan)

Cor

 

[Ron L]

Cor

Thanks for your response. At the risk of (fully) revealing my ignorance, I
simply don't see much of a difference between the two (remoting and web
services). That said, our decision to go with remoting was to be able to
use the binary formatter. I am coming to suspect that the slow down we are
seeing is introduced by IIS as it serves up the HTTP responses with the
data, do you have any input on that?

We currently have an application which is a MS-SQL back-end with an ASP (not
..Net) front end. This application is currently used in a LAN environment.
We have had the application on-line for 5 years, and are starting to see
response time problems as the volume of data has been increasing over time.
Since we cannot reduce the data volume appreciably, we are looking at
rewriting the front-end in VB.Net. We had been working on the assumption
that much of our response time problem was due to the time required to
render the data in IE. In addition, we forsee a need in the near future
(1-2 years) for users to be able to access our data across the internet.
This last requirement is what pushed us into exploring remoting, as it could
ride on the HTTP channel and significantly ease WAN connectivity issues. We
do not think that we will be able to setup VPNs to each of the users who
will need access to our product.

Once we started implementing our front-end, we have noticed that the
response time has not increased as dramatically as we had expected, so that
was when we started testing the data load times of Remoting vs OLEDB calls.
I am hoping that there is some way of speeding up the remoting calls so that
we can see something closer to the OLEDB access times.

Thank you,
Ron L

 

[Cor Ligthert [MVP]]

Ron,

A simple answer, not including security because that you have in every
system outside the office.

A webservice is so easy to make programs for in VB.Net (and very
maintainable)

It is by instance just in your windowforms programs something as
dim ds as dataset = myWebservice.DatasetX

And than in the webservice the normal statements as if you would be if it
was local to your program to fill and update with an extra class for that

In my opinion is simplicity and all benefits from that be a major decision
value.

However just my thought,

Cor

 

[Ron L]

Inge

Thanks for your response. I tried the following connect string, and saw no
appreciable change

Provider=SQLOLEDB;Network Library=DBMSSOCN;Data Source=Dev-Net;Initial
Catalog=Nitss2kDev;Integrated Security=SSPI;Trusted_Connection=yes

I assume that the Network Library portion of the string is what you were
referring to.

Ron L

 

[Ron L]

jabailo

Thanks for the response. I am measuring the time from when I issue the
remoting call to the time it returns. As far as I can tell, this is
analogous to timing the OLEDB command and dataAdapter.fill times. My issue
is not really which part of the call is taking the time as much as the fact
that there is a factor of 6-8 difference in the two methods. This makes it
very difficult to justify using the remoting calls to retrieve my data.

Ron L

 

[Beth Massi [Architect MVP]]

Hi Ron,

It sounds like our product employs the exact server architecture you
describe (difference is we have a Windows forms smart client). I'm assuming
that your .NET components use the SQLClient, not OleDB, to connect to your
SQL-Server database (?)

Remoting over HTTP with the binary formatter hosted in IIS has comparable
speed as web services if you are serializing small objects. However, once
you start serializing large objects the performance gain is in the decreased
network latency because of the smaller package size. However, if you are
passing datasets and using the 1.1 framework those datasets will not
serialize as binary, they are actually serializing as XML.

To serialize the datasets as binary you have to use a surrogate class. (Look
here for a link to the code
http://bethmassi.blogspot.com/2004/12/binary-serialization-of-datasets.html).
If you use the surrogate class, make sure you change the
typeFilterLevel="full" in the formatter element in the channel section of
your web.config. Keep in mind though that if you have an extremely fast
network and very large datasets, using the surrogate class may be slower
(depending on CPU speed of the computers) because of the time it takes to
wrap up the dataset into byte arrays and back again. However, this method
will dramatically help with network latency over congested WANs or the
internet.

If you are using version 2.0 of the .NET framework, set the
Dataset.RemotingFormat property equal to SerializationFormat.Binary. There
has also been major performance improvements with 2.0 so if you can use it,
do it.

A couple other things to verify/try:

1. Make sure your remote components activation method is single-call for the
best scalability.
2. Make sure the components are local to the database (on the same computer
or LAN)
4. Try disabling HTTP-Keep Alives on the IIS remoting host
3. Depending on the size of your application and scalability requirements,
try not to call the components via remoting from your ASP.NET application,
put them together on the same computer. (A local call will ALWAYS be faster
than a remote call) You can still expose them as remote components to other
remote callers if you need to.

HTH,
-B

 

[Beth Massi [Architect MVP]]

Hi Cor (Congrats on MVP!)

Remoting can be just as object transparent (even more so) than a web
service. Additionally, remoting can offer many more activation methods and
transport protocols than web services as well as better performance in some
cases because of the ability to use the binary formatter. The difference is
that Microsoft didn't put a "Configure Remoting Wizard" in the product so it
doesn't *seem* easy like web services.

When you expose remote objects using IIS as the host and single-call
activation then you can easily expose the same objects as web-services (even
at the same time).

-B