views:

793

answers:

4

i have a .net 2.0 web service running on IIS 7.0.

i consume this service from a compact framework written application (CF 2.0). The first call takes 13 seconds, all subsequent calls are super fast (under 1 sec). No data is cached.

Any ideas how to solve this?

A: 

Is it the first call at all to the IIS after it started, or the server started?
The first ever call to IIS is always slower. We used to solve it by having a script that manufactured a dummy call upon restart or IISRESET, to absorb the first call penalty.

Traveling Tech Guy
the IIS is always on. never gets restarted. the first call to the web service from the CF desk app is slow, then all subsequent calls are super fast for about 3 minutes, afterwords there is a slow call, and so on so forth.
gnomixa
It can either be you app pools restarting, as the answer below suggests, or maybe something physical with the server, such as a hard drive spinning down to conserve power. Also worth checking are caching parameters.
Traveling Tech Guy
is that normal behaviour for a web service? to be slow the first time? or should it be fast right away? Looking at the forums, I am getting conflicting opinions.
gnomixa
+3  A: 

The first call is loading the .NET Runtime and JITting the web methods called. Many shops which deploy services as such don't really care about the first time, but when they do, they'll have something make a call to it as part of deployment to get that first time out of the way. Another method is to NGEN it.

Jesse C. Slicer
more details please.1) is it installed on client? webserver?2) if on the client, does it work for WinCE, CF 2.0?
gnomixa
You will be doing this on the server. Your server-side's web service is ASP.NET 2.0 and likely doing heavy-duty chores such as getting data from a database, etc. There is most likely little time of that 17 seconds being spent on the client-side. Also check your global.asax.cs file to see if there's any set-up routines that run on first request and potentially delay some of those to spread the work around.
Jesse C. Slicer
thanks Jesse, I am putting timers on now.
gnomixa
Is there an easier solution though than learning a new tool and installing something on the web server?
gnomixa
If you want to go the NGEN route, you wouldn't be installing anything new on the web server. It comes with the .NET redistributable. You can find it (usually) in C:\Windows\Microsoft.NET\Framework\v2.0.50727 on any computer. And all you have to do is go to your application's Bin folder and do "NGEN install MyWebService.dll" (or "NGEN update MyWebService.dll" if it's already been done once). You can also make it a post-build action of your project to do it automatically.
Jesse C. Slicer
"NGEN install MyWebService.dll" - I am assuming that this is a command line command?
gnomixa
NGEN is not an option for the Compact Framework.
ctacke
Yes, it is a command-line command.
Jesse C. Slicer
A: 

Also the first time when the app is called your sql-connections are opened. If there are network problems this could take longer. After a time when the app is idle the connection could be automatically closed.

codymanix
since i test the web service with different parameters during the time when it is fast, network connection seems fine. As i said, no data is being cached, so if network were problematic, it would show every single time, wouldn't it?it seems too much of a coincidence. I think I am missing something. The question is what.
gnomixa
+3  A: 

The first call under a CF application is when all of the proxy objects on the device are created. So even if the objects, etc on the server are already spun up, the first call from each device is going to be substantially slower than any subsequent call.

A common workaround for this is to have your service expose some stub method (it can do absolutely nothing if you want) and when your application starts up, spawn a worker thread that calls this stub. This will create the service proxy objects in the background for you so when your app actually makes a call out to the service, everything is ready.

ctacke
ok, this makes more sense, thank you!one thing I do not understand then, is why every so often the call will take longer, then some fast calls, then a long call. It's almost like there is a cron job running on the thin client that removed the proxy objects.
gnomixa
can i have some control of these proxy objects?
gnomixa
my guess is that the JITTted proxies are getting pitched and have to be re-JITted. The Remote Performance Monitor could verify that - look to see if you have a pitch in the collection right before a long call. You don't really have any control over the proxy objects, they get built as needed, and like any other managed object, the code can be pitched if the GC deems it necessary.
ctacke
here is an idea: do you think that perhaps having a worker thread in the background fire off every so often and calling this stub service would be a good idea?
gnomixa
It couldn't hurt (as long as it's not called too frequently). It's definitely worht testing.
ctacke
my co-worker is using Windows Communication Foundation. It is supported for CF 3.5. Now, if I were to create a service using WCF and connect to it from my app (written in 3.5), would I still experience delay and proxy objects created on the device?
gnomixa