Optimizing webservice call which are returning datasets

[sameer]

Hi all,

Application environment :
VB.Net desktop application,.NET 1.1 Framework, VS 2003.
communicates between the database and the application is done over
webservices using ADO.NEt Datasets.
Returned dataset is Gzip compressed and is then decompressed on the
receiving side.

Every thing works good, the problem is that it takes a lot of time for the
webservice to return my data filled dataset even if there is not much data, i
thnk the reson being 1. serilization of dataset is expensive 2. datset is all
XML and so even XML tags add to the space as well. Even though this is all
compressed but even then it is taking long and their always is room for
improvment, can any one out there tell me
the best strategy for trasferring the data over the webservice i.e should I
replace the dataset with another object for transmiting it over the
webservice OR is there any other way to make sure datasets are tranmitted
faster.

thanks

Sameer

[Ken Cox - Microsoft MVP]

Maybe the delay is caused by the compression or fetching the data rather
than the transmission size/time?
"sameer" <sa****@discussions.microsoft.com> wrote in message
news:0B**********************************@microsof t.com...

Hi all,

Application environment :
VB.Net desktop application,.NET 1.1 Framework, VS 2003.
communicates between the database and the application is done over
webservices using ADO.NEt Datasets.
Returned dataset is Gzip compressed and is then decompressed on the
receiving side.

Every thing works good, the problem is that it takes a lot of time for the
webservice to return my data filled dataset even if there is not much
data, i
thnk the reson being 1. serilization of dataset is expensive 2. datset is
all
XML and so even XML tags add to the space as well. Even though this is all
compressed but even then it is taking long and their always is room for
improvment, can any one out there tell me
the best strategy for trasferring the data over the webservice i.e should
I
replace the dataset with another object for transmiting it over the
webservice OR is there any other way to make sure datasets are tranmitted
faster.

thanks

Sameer

[sameer]

Ken , thanks for your reply,
nope, if not for compression it takes a long time, like if with compression
it takes 1 minutes then without cmpression it takes 3-4 minutes. And there
really is not that much data in the dataset, so again i am trying to blame
XML tags for incresing the size of the data. So does any one out there know a
better alternative to passing data over the webservice instead of passing a
dataset.

thanks

"Ken Cox - Microsoft MVP" wrote:

Maybe the delay is caused by the compression or fetching the data rather
than the transmission size/time?
"sameer" <sa****@discussions.microsoft.com> wrote in message
news:0B**********************************@microsof t.com...

Hi all,

Application environment :
VB.Net desktop application,.NET 1.1 Framework, VS 2003.
communicates between the database and the application is done over
webservices using ADO.NEt Datasets.
Returned dataset is Gzip compressed and is then decompressed on the
receiving side.

Every thing works good, the problem is that it takes a lot of time for the
webservice to return my data filled dataset even if there is not much
data, i
thnk the reson being 1. serilization of dataset is expensive 2. datset is
all
XML and so even XML tags add to the space as well. Even though this is all
compressed but even then it is taking long and their always is room for
improvment, can any one out there tell me
the best strategy for trasferring the data over the webservice i.e should
I
replace the dataset with another object for transmiting it over the
webservice OR is there any other way to make sure datasets are tranmitted
faster.

thanks

Sameer

[Ken Cox - Microsoft MVP]

Remoting is an excellent way to transfer data efficiently. It doesn't have
the overhead of SOAP but it isn't as universal.

http://msdn.microsoft.com/library/de...ngoverview.asp

"sameer" <sa****@discussions.microsoft.com> wrote in message
news:F6**********************************@microsof t.com...

Ken , thanks for your reply,
nope, if not for compression it takes a long time, like if with
compression
it takes 1 minutes then without cmpression it takes 3-4 minutes. And there
really is not that much data in the dataset, so again i am trying to blame
XML tags for incresing the size of the data. So does any one out there
know a
better alternative to passing data over the webservice instead of passing
a
dataset.

thanks

"Ken Cox - Microsoft MVP" wrote:

Maybe the delay is caused by the compression or fetching the data rather
than the transmission size/time?
"sameer" <sa****@discussions.microsoft.com> wrote in message
news:0B**********************************@microsof t.com...

> Hi all,
>
> Application environment :
> VB.Net desktop application,.NET 1.1 Framework, VS 2003.
> communicates between the database and the application is done over
> webservices using ADO.NEt Datasets.
> Returned dataset is Gzip compressed and is then decompressed on the
> receiving side.
>
> Every thing works good, the problem is that it takes a lot of time for
> the
> webservice to return my data filled dataset even if there is not much
> data, i
> thnk the reson being 1. serilization of dataset is expensive 2. datset
> is
> all
> XML and so even XML tags add to the space as well. Even though this is
> all
> compressed but even then it is taking long and their always is room for
> improvment, can any one out there tell me
> the best strategy for trasferring the data over the webservice i.e
> should
> I
> replace the dataset with another object for transmiting it over the
> webservice OR is there any other way to make sure datasets are
> tranmitted
> faster.
>
> thanks
>
> Sameer
>

[sameer]

could be very well possible, but this application is pretty huge and is
already done, i am just optimizing it, i would want to get suggestions
considering webservices only.
let me know if you got one.

thanks

"Ken Cox - Microsoft MVP" wrote:

Remoting is an excellent way to transfer data efficiently. It doesn't have
the overhead of SOAP but it isn't as universal.

http://msdn.microsoft.com/library/de...ngoverview.asp

"sameer" <sa****@discussions.microsoft.com> wrote in message
news:F6**********************************@microsof t.com...

Ken , thanks for your reply,
nope, if not for compression it takes a long time, like if with
compression
it takes 1 minutes then without cmpression it takes 3-4 minutes. And there
really is not that much data in the dataset, so again i am trying to blame
XML tags for incresing the size of the data. So does any one out there
know a
better alternative to passing data over the webservice instead of passing
a
dataset.

thanks

"Ken Cox - Microsoft MVP" wrote:

Maybe the delay is caused by the compression or fetching the data rather
than the transmission size/time?
"sameer" <sa****@discussions.microsoft.com> wrote in message
news:0B**********************************@microsof t.com...
> Hi all,
>
> Application environment :
> VB.Net desktop application,.NET 1.1 Framework, VS 2003.
> communicates between the database and the application is done over
> webservices using ADO.NEt Datasets.
> Returned dataset is Gzip compressed and is then decompressed on the
> receiving side.
>
> Every thing works good, the problem is that it takes a lot of time for
> the
> webservice to return my data filled dataset even if there is not much
> data, i
> thnk the reson being 1. serilization of dataset is expensive 2. datset
> is
> all
> XML and so even XML tags add to the space as well. Even though this is
> all
> compressed but even then it is taking long and their always is room for
> improvment, can any one out there tell me
> the best strategy for trasferring the data over the webservice i.e
> should
> I
> replace the dataset with another object for transmiting it over the
> webservice OR is there any other way to make sure datasets are
> tranmitted
> faster.
>
> thanks
>
> Sameer
>

[Marc Gravell]

When you say GZip'd - do you mean in the transport protocol (i.e. your
[WebMethod] returns a DataSet), or are you explicitely serializing the
object to a GZip stream yourself? If the latter, this could be part of the
problem, as a: 1.1 DataSets have really bad binary serialization (i.e. it's
just the same xml written in binary...), plus the lack of MTOM means you
will be (base-64?) encoding the binary on top. Is this a possiblilty?

Marc

[sameer]

Marc, i am not explicity serializing it, also IIS 6.0 compresses the dataset
and all i do is uncompress it, this is only increasing the performance and
not decreasing it.
Any other Suggestions of transfering the data over webservices instead of
using a sending a data.

thanks.

"Marc Gravell" wrote:

When you say GZip'd - do you mean in the transport protocol (i.e. your
[WebMethod] returns a DataSet), or are you explicitely serializing the
object to a GZip stream yourself? If the latter, this could be part of the
problem, as a: 1.1 DataSets have really bad binary serialization (i.e. it's
just the same xml written in binary...), plus the lack of MTOM means you
will be (base-64?) encoding the binary on top. Is this a possiblilty?

Marc

[Marc Gravell]

OK, scratch that idea then... it was worth a shot.

Beyond that... my only real advice in this scanario is to minimise what you
are transferring... are there any columns with lots of text in them that the
client doesn't need? Do you really need all the rows or could you use
paging? That sort of thing.

Your original post doesn't give any indication of what sort of size /
complexity of DataSet we are talking about; if this is returning 15
DataTables (with complex relations) each with 40 columns and 10000 rows then
yes, it will take a while. If you genuinely need all of the data at the
client (and you can't cache it locally for whatever reason) then I'm not
sure there are many alternatives under 1.1 and [WebMethod].

If you were in 2.0, you could consider using a GZip'd binary serialization
of the dataset transferred via MTOM (WSE3) - this should (theoretically)
take a lot less bandwidth. But according to the original post, you're not.

<stumped/>

Marc