By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,360 Members | 3,011 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,360 IT Pros & Developers. It's quick & easy.

Remoting calls MUCH slower than OLEDB calls

P: n/a
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.
Nov 21 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
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

Nov 21 '05 #2

P: n/a
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
"Keenan Newton" <ka*********@yahoo.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
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

Nov 21 '05 #3

P: n/a
Ron L wrote:
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.
Nov 21 '05 #4

P: n/a
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

"Ron L" <ro**@bogus.Address.com> wrote in message
news:eK**************@TK2MSFTNGP12.phx.gbl...
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
"Keenan Newton" <ka*********@yahoo.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
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


Nov 21 '05 #5

P: n/a
See this site http://www.udaparts.com/articles/fastsocketpro.htm. Don't send
a large size dataset or table over remoting.
"Ron L" <ro**@bogus.Address.com> wrote in message
news:u4**************@TK2MSFTNGP12.phx.gbl...
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.

Nov 21 '05 #6

P: n/a
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;"
"Ron L" <ro**@bogus.Address.com> skrev i melding
news:u4**************@TK2MSFTNGP12.phx.gbl...
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.


Nov 21 '05 #7

P: n/a
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
Nov 21 '05 #8

P: n/a
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]" <no************@planet.nl> wrote in message
news:%2******************@TK2MSFTNGP12.phx.gbl...
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

Nov 21 '05 #9

P: n/a
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
Nov 21 '05 #10

P: n/a
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
"Inge Henriksen" <in************@booleansoft.com> wrote in message
news:GO***************@fe23.usenetserver.com...
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;"
"Ron L" <ro**@bogus.Address.com> skrev i melding
news:u4**************@TK2MSFTNGP12.phx.gbl...
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.


Nov 21 '05 #11

P: n/a
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

<ja*****@texeme.com> wrote in message
news:eJ********************@speakeasy.net...
Ron L wrote:
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.

Nov 21 '05 #12

P: n/a
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/1...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

"Ron L" <ro**@bogus.Address.com> wrote in message
news:OT**************@TK2MSFTNGP09.phx.gbl...
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]" <no************@planet.nl> wrote in message
news:%2******************@TK2MSFTNGP12.phx.gbl...
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


Nov 21 '05 #13

P: n/a
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

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:ub**************@TK2MSFTNGP09.phx.gbl...
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

Nov 21 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.