Improving first access to a web service

[murphy]

I'm programming a site that displays info from AWS Commerce Service
4.0. At each change of the asp.net application the first load of a
page that uses the web service takes 30 seconds. Subsequent calls are
snappy. From what I've learned this overhead is for processing the
wsdl file (which has of course not changed). The file is large, 2200
lines.

Is there a way to use this file locally on the web server or cache the
result of the read? It would really speed my development iterations.

Sorry if I'm missing something basic or am asking the question with the
wrong terms. I suspect that's why I'm not finding the answer quickly
in the newsgroups.

Thanks!

 

[Olorin]

hmmm...
from what I heard the problem with the first call regards not only the
WSDL but also the serialization/deserialization of the
parameters/objects passed between your web service and consumer app.
The XMlSerializer, in fact, uses reflection (slow) on the first call to
figure out how to serialize/deserialize stuff as needed.

I've heard .NET Framework 2.0 + Visual Studio 2005 should let you
deploy your app with a pre-compiled (or pre-something) version of the
code needed to do this serialization/deserialization and should
therefore get around the slowness of the first calls.

Hope this will help you, assuming you can wait for .NET Fwork 2.0 to
come out.

F.O.R.

 

[Joey]

Hi,

Above your web service you can put a cache duration(in
seconds). Not sure if this can help

[WebService(Namespace="http://abc/webservices/",
Description="ABC Web Service",
CacheDuration = 30)]


Joey

 

[Alvin Bruney [MVP]]

cache duration has nothing to do with initial access.

About the best you can do with the current technology is to encourage your
users to sit and wait . If you are anal like me, you can write a little
utility that simply fires a webrequest periodically to keep the application
warm and toasty. That will change for ASP.NET 2.0 so sit tight.

I'd say that 30 seconds is unusually long for startup but I'm not all that
familiar with your implementation.

From what I've learned this overhead is for

processing the

Not really, the startup cost is a feature (or fault) of .NET
--
Regards,
Alvin Bruney [Microsoft MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://www.lulu.com/owc
----------------------------------------------------------

Hi,

Above your web service you can put a cache duration(in
seconds). Not sure if this can help

[WebService(Namespace="http://abc/webservices/",
Description="ABC Web Service",
CacheDuration = 30)]


Joey

-----Original Message-----
I'm programming a site that displays info from AWS Commerce Service
4.0. At each change of the asp.net application the first load of a
page that uses the web service takes 30 seconds. Subsequent calls are
snappy. From what I've learned this overhead is for processing the
wsdl file (which has of course not changed). The file is large, 2200
lines.

Is there a way to use this file locally on the web server or cache the
result of the read? It would really speed my development iterations.

Sorry if I'm missing something basic or am asking the question with the
wrong terms. I suspect that's why I'm not finding the answer quickly
in the newsgroups.

Thanks!

.

 

[murphy]

Thank you all.

So its the serialization/deserialization of the objects and parameters
that is the issue I guess. This must be done each time the application
is loaded at the invocation of the first method. Amazon's interface
spans 2200 lines and so is larger perhaps than most web services. My
actual timing shows the first call is more like 70 seconds long. Can
anyone point me to documentation that describes what is actually
happening during this operation? Serialization/deserialization sounds
like changing something from one format to another. The processor on
the web server is idle during this time. Where is the wait occurring?
On the web server waiting for a response from Amazon? Downloading the
wsdl itself is near instant. At this point, I'm just trying to get
educated about how this is working.

Thanks again for the info about asp.net 2.0. It looks like it has lots
of good stuff to look forward to.

-Mark

 

[Alvin Bruney [MVP]]

This may help.
About middle of the page down.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/dotnetperftechs.asp
I swear i learn something new everytime i read that article!

--
Regards,
Alvin Bruney [Microsoft MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://www.lulu.com/owc

 

[murphy]

Thanks for the pointer on the article. I'm not sure if I see the web
service answer, but there are definitely some other juicy morsels!

Mark

 

[Olorin]

Here's my current understanding of this 'first-invokation' problem.
Please correct me if I'm wrong.

in .NET apps we have compilation on-demand. We commonly say we're
'compiling' our projects in Visual Studio (or through the command line
equivalents), but truly we are just *building* the app. That means the
app is converted to MSILanguage.
When the app is first called, the Just-In-Time (JIT) compiler takes the
MSIL and actually compiles it.
On subsequent invokations to the same code, the JIT compiler recognizes
the compilec code is already available and does not re-do it all.

This happens for all .NET apps, but we notice it more in Web APps
becaise, as the JIT compiler compiles a web app or a web service, it
must compile the code needed to serialize/deserialize all the data
types exposed by the web app or web service public API.

So, if your web service has a
[WebMethod]
public DataSet GetCustomers()

API, the JIT compiler recognizes it will have to compile the code to
serialize a DataSet. That means it calls the CoapSerializer or
HttpSerializer or XmlSerializer in action.
The serializers, as far as I know, use Reflection to figure out how
they should serialize/deserialize something.
Reflection is admittedly a bit on the slow side, since it deals with a
lot of meta-data.

That is where, I think, we get the performance hit.

As I said, if anyone here has a better understanding of the situation,
please enlighten me.

BTW, I've been running performance comparisons on this stuff. I don't
have a definitive bottom-line yet ('cause I gathered too much
data...about 24 000 trials), but so far this 'first invokation' hit
seems the biggest performance hit in the whole system.

Which leads me to say:
while we wait for .NET 2.0 (where apparently this will be alleviated or
resolved), one should include a round of automated unit tests
exercising the whole code as part of one's .NET web-apps deployment (or
update) process.
Ah, yes, we already knew we should do that as a good practice, but now
we have another good reason, right?

Cheers,
F.O.R.

 

[Derek Harmon]

Here's my current understanding of this 'first-invokation' problem.
Please correct me if I'm wrong. : :
This happens for all .NET apps, but we notice it more in Web APps
becaise, as the JIT compiler compiles a web app or a web service, it
must compile the code needed to serialize/deserialize all the data
types exposed by the web app or web service public API.

For a WebMethod, the Framework:
1.) Reflects against the types appearing in the signature of the method using
reflection to get all their properties (and reflects against those properties'
types if necessary, i.e. if the property had a compound type).
2.) Writes C# source code to serialize and deserialize them and saves
this into a file in your temp directory (cleans it up too, unless you set a
certain diagnostic switch instructing it to leave it there).
3.) Launches the C# compiler to compile that source code.
4.) Loads the dynamically generated assembly into memory and starts using
its serialization/deserialization class to handle the XML.

For an ASP.NET application it's a little different:
1.) Reads and parses the .ASPX file, which is a 'template' describing the
hierarchy of controls on the page and their initial settings.
2.) Writes C# source code to create the control hierarchy that fills the Page
and saves this into a file deep beneath your Temporary ASP.NET Files
directory.
3.) Launches the C# compiler to compile that source code.
4.) Saves the dynamically generated assembly alongside the source file.

It's machines writing programs for themselves and then loading systems
software like you or I would do that's the slow part.

These processes aren't known to the JIT compiler. The Serialization
process affecting WebMethods happens after code has been JIT into
machine code, only as it executes to the point where an XmlSerializer
object gets constructed for a given Type the first time. Conversely,
the ASP.NET process happens before the JIT even sees the IL in
an assembly (because the ASP.NET process is responsible for
producing the assembly the JIT receives when it doesn't already
exist or is out-of-date).


Derek Harmon