Re: Invoking Web Service from WinForm App VERY slow first call

[=?Utf-8?B?SmltIE93ZW4=?=]

Hi John,

Hopefully this post will find its way back to you - or perhaps be answered
by someone else. As I mentioned in my last post on the earlier portion of
this thread, changing the serialization settings for the build handled the
initial slows we encountered when invoking the web service.

Since that time, we ported the original VB.net code over to C# - this was
done to make it cleaner easier to include the project in the rest of the C#
solution.

The problem is that the initial slows have re-appeared despite ensuring
the serialization option in the project were set to "On" and trying every
combination that we could think of.

We're using VS2008 Team Suite with the 3.5 framework. The web
references are still defined as web references rather that service references.

Any ideas what this might be at this time?

Regards,

Jim

"John Saunders [MVP]" wrote:

>

"Jim Owen" <ji**@online.nospamwrote in message
news:25**********************************@microsof t.com...

As far as we can tell, no. This is a remote service with dozens of users
invoking services continually. There does not appear to be issues with
other
clients. (We have three different development locations, each with the
same
issue, so it does not appear to be network or connection related.)

We have not yet found the exact cause, but we're looking into the
initialization process.

Jim

"densial" wrote:

On Mar 27, 6:36 am, Jim Owen <[e-mail]:
Thanks for the reply.

We've narrowed it down to something that is occurring on our client
side but
have not totally sorted it out. It appears that there is significant
overhead when it is first invoked, but what is generated appears to be
cached
for some period after generation.

To test this, we wrote a small console app that simply invokes the web
service through a class then prints out the elapsed time on the
console.
When the exe is first executed, the entire process requires 15 - 18
seconds.
Executing the same executable a second time cuts the elapsed time to
3-4
seconds. Executing again produces the same results. However, if you
wait 10
minutes or so and execute the program again, elapsed time again shoots
up to
15-18 seconds.

There's obviously initialization going on behind the scene that we're
not
seeing. We'd like to eliminate that init when first called or at least
minimize it.

Thanks,
Jim

"Jeff" wrote:
I had a similar problem with .NET Remoting in the past. This may or
may not
be the same issue for you. In our case the remote object was loading
a lot of
data as it was initialized. It turns out that with .NET Remoting the
remote
object is not actually created until the client application invokes a
method
or property. So the client program would start up and create the
proxy and
you think everything is great. Then when a user tried to invoke it
they had
to wait for intitialization. It was really a matter of understanding
the
lifetime of a remote object and getting the architecture correct.

I would start by looking at the initialization code and finding out
if that
is the slow down.

"Jim Owen" wrote:

Hi,
We have been putting together a Win Forms application that consumes
a web
service to obtain item information for a client. We've found that
the first
call to the web service from the application, no matter what the
call is,
takes way, way too long. We've timed it at over 15 seconds, but
the second
call from within the same app takes 4-500 milliseconds.

We've found a couple of references to things that might decrease
the initial
time, but nothing definite.

Anyone have suggestions on handling this? The classes handling the
web
service calls were written in VB.NET using 3.5 framework and using
Web
Services references rather than Service References. Using VS 2008.

Thanks,

Jim

it's not the server rebuilding is it? IIS isn't shutting down and
restarting? you could recycle the app pool and see if it gives the
same lag after the recycle.

you could also try invoking the same web service from another app on
another machine, see what that does.

This sounds like the serialization assemblies being created at runtime. Try
changing the settings of the Serialization Assembly dropdown at the bottom
of the Build pane of the properties window for the project.
--
--------------------------------------------------------------------------------
John Saunders | MVP – Windows Server System – Connected System Developer

[kessler.mike]

On May 4, 4:14*pm, Jim Owen <[e-mail]:

Hi John,

* Hopefully this post will find its way back to you - or perhaps be answered
by someone else. *As I mentioned in my last post on the earlier portion of
this thread, changing the serialization settings for the build handled the
initial slows we encountered when invoking the web service.

* Since that time, we ported the original VB.net code over to C# - this was
done to make it cleaner easier to include the project in the rest of the C#
solution.

* The problem is that the initial slows have re-appeared despite ensuring
the serialization option in the project were set to "On" and trying every
combination that we could think of.

* We're using VS2008 Team Suite with the 3.5 framework. * *The web
references are still defined as web references rather that service references.

* Any ideas what this might be at this time?

* Regards,

* Jim

"John Saunders [MVP]" wrote:

"Jim Owen" <[e-mail] in message
news:25**********************************@microsof t.com...

As far as we can tell, no. *This is a remote service with dozens of users
invoking services continually. *There does not appear to be issues with
other
clients. *(We have three different development locations, each with the
same
issue, so it does not appear to be network or connection related.)

We have not yet found the exact cause, but we're looking into the
initialization process.

Jim

"densial" wrote:

>On Mar 27, 6:36 am, Jim Owen <[e-mail]:
Thanks for the reply.

We've narrowed it down to something that is occurring on our client
side but
have not totally sorted it out. *It appears that there is significant
overhead when it is first invoked, but what is generated appears tobe
cached
for some period after generation.

To test this, we wrote a small console app that simply invokes the web
service through a class then prints out the elapsed time on the
console.
When the exe is first executed, the entire process requires 15 - 18
seconds.
Executing the same executable a second time cuts the elapsed time to
3-4
seconds. *Executing again produces the same results. *However, if you
wait 10
minutes or so and execute the program again, elapsed time again shoots
up to
15-18 seconds.

There's obviously initialization going on behind the scene that we're
not
seeing. *We'd like to eliminate that init when first called or atleast
minimize it.

Thanks,
Jim

"Jeff" wrote:
I had a similar problem with .NET Remoting in the past. This may or
may not
be the same issue for you. In our case the remote object was loading
a lot of
data as it was initialized. It turns out that with .NET Remoting the
remote
object is not actually created until the client application invokes a
method
or property. So the client program would start up and create the
proxy and
you think everything is great. Then when a user tried to invoke it
they had
to wait for intitialization. It was really a matter of understanding
the
lifetime of a remote object and getting the architecture correct.

I would start by looking at the initialization code and finding out
if that
is the slow down.

"Jim Owen" wrote:

Hi,
We have been putting together a Win Forms application that consumes
a web
service to obtain item information for a client. We've found that
the first
call to the web service from the application, no matter what the
call is,
takes way, way too long. *We've timed it at over 15 seconds, but
the second
call from within the same app takes 4-500 milliseconds.

We've found a couple of references to things that might decrease
the initial
time, but nothing definite.

Anyone have suggestions on handling this? *The classes handling the
web
service calls were written in VB.NET using 3.5 framework and using
Web
Services references rather than Service References. *Using VS2008.

Thanks,

Jim

>it's not the server rebuilding is it? IIS isn't shutting down and
>restarting? you could recycle the app pool and see if it gives the
>same lag after the recycle.

>you could also try invoking the same web service from another app on
>another machine, see what that does.

This sounds like the serialization assemblies being created at runtime. Try
changing the settings of the Serialization Assembly dropdown at the bottom
of the Build pane of the properties window for the project.
--
---------------------------------------------------------------------------*-----
John Saunders | MVP – Windows Server System – Connected System Developer- Hide quoted text -

- Show quoted text -

I'm having the exact same issue with VS 2008 Team System with C# .net
3.5 XML web services.
Changing the Serialization Assembly worked to speed up the development
box, but did not help the IIS on 2k3 box.
Does anyone have something else to try? Along with this, it seems
that giving the app a 3-5 minute break between calls will cause the
same thing. The next call will take 15+ seconds to complete when it
had been doing them in a half second or less. Is there something to
set that can help keep the objects "alive"?

Thanks,

[=?Utf-8?B?SmltIE93ZW4=?=]

Hi Mike,
We eventually solved the issue although I'm not totally sure exactly what
we changed to make it work correctly.

In this particular solution, we have about 8 projects, most of which
access the web service and do so through a set of wrapper classes in one of
the projects.

We went though ALL of the projects and ensured that the Generate
Serialization Assembly was set to On for all projects. We then rebuilt the
entire solution and set the XMLSerialization dll's to read-only access.

After doing various repititions of the above, it began working as
expected. I suspect that the read-only file attribute was not necessary, but
we did get it working.

The issue is that the framework will generate the XML serialization
assembly for the call to the web service unless it is told to generate them
in advance. That compilation eats up the time.

Hope this helps,

- Jim
"ke**********@gmail.com" wrote:

On May 4, 4:14 pm, Jim Owen <[e-mail]:

Hi John,

Hopefully this post will find its way back to you - or perhaps be answered
by someone else. As I mentioned in my last post on the earlier portion of
this thread, changing the serialization settings for the build handled the
initial slows we encountered when invoking the web service.

Since that time, we ported the original VB.net code over to C# - this was
done to make it cleaner easier to include the project in the rest of the C#
solution.

The problem is that the initial slows have re-appeared despite ensuring
the serialization option in the project were set to "On" and trying every
combination that we could think of.

We're using VS2008 Team Suite with the 3.5 framework. The web
references are still defined as web references rather that service references.

Any ideas what this might be at this time?

Regards,

Jim

"John Saunders [MVP]" wrote:

"Jim Owen" <[e-mail] in message
>news:25**********************************@microso ft.com...
As far as we can tell, no. This is a remote service with dozens of users
invoking services continually. There does not appear to be issues with
other
clients. (We have three different development locations, each with the
same
issue, so it does not appear to be network or connection related.)

We have not yet found the exact cause, but we're looking into the
initialization process.

Jim

"densial" wrote:

On Mar 27, 6:36 am, Jim Owen <[e-mail]:
Thanks for the reply.

We've narrowed it down to something that is occurring on our client
side but
have not totally sorted it out. It appears that there is significant
overhead when it is first invoked, but what is generated appears to be
cached
for some period after generation.

To test this, we wrote a small console app that simply invokes the web
service through a class then prints out the elapsed time on the
console.
When the exe is first executed, the entire process requires 15 - 18
seconds.
Executing the same executable a second time cuts the elapsed time to
3-4
seconds. Executing again produces the same results. However, if you
wait 10
minutes or so and execute the program again, elapsed time again shoots
up to
15-18 seconds.

There's obviously initialization going on behind the scene that we're
not
seeing. We'd like to eliminate that init when first called or at least
minimize it.

Thanks,
Jim

"Jeff" wrote:
I had a similar problem with .NET Remoting in the past. This may or
may not
be the same issue for you. In our case the remote object was loading
a lot of
data as it was initialized. It turns out that with .NET Remoting the
remote
object is not actually created until the client application invokes a
method
or property. So the client program would start up and create the
proxy and
you think everything is great. Then when a user tried to invoke it
they had
to wait for intitialization. It was really a matter of understanding
the
lifetime of a remote object and getting the architecture correct.

I would start by looking at the initialization code and finding out
if that
is the slow down.

"Jim Owen" wrote:

Hi,
We have been putting together a Win Forms application that consumes
a web
service to obtain item information for a client. We've found that
the first
call to the web service from the application, no matter what the
call is,
takes way, way too long. We've timed it at over 15 seconds, but
the second
call from within the same app takes 4-500 milliseconds.

We've found a couple of references to things that might decrease
the initial
time, but nothing definite.

Anyone have suggestions on handling this? The classes handling the
web
service calls were written in VB.NET using 3.5 framework and using
Web
Services references rather than Service References. Using VS 2008.

Thanks,

Jim

it's not the server rebuilding is it? IIS isn't shutting down and
restarting? you could recycle the app pool and see if it gives the
same lag after the recycle.

you could also try invoking the same web service from another app on
another machine, see what that does.

This sounds like the serialization assemblies being created at runtime. Try
changing the settings of the Serialization Assembly dropdown at the bottom
of the Build pane of the properties window for the project.
--
---------------------------------------------------------------------------Â*-----
John Saunders | MVP – Windows Server System – Connected System Developer- Hide quoted text -

- Show quoted text -

I'm having the exact same issue with VS 2008 Team System with C# .net
3.5 XML web services.
Changing the Serialization Assembly worked to speed up the development
box, but did not help the IIS on 2k3 box.
Does anyone have something else to try? Along with this, it seems
that giving the app a 3-5 minute break between calls will cause the
same thing. The next call will take 15+ seconds to complete when it
had been doing them in a half second or less. Is there something to
set that can help keep the objects "alive"?

Thanks,