>Hi all,
>
>I am working on an application that uses Web Services for all data access. I am noticing the original developer used a timer to issue a call to the web service as sort of a "Ping" every 10 seconds to keep track if the service is alive. Interestingly they don't really do anything with that when it fails or succeeds. If a required call the web service is made, another Ping call is made to verify the service is available first but again, nothing is done except to throw a handled exception and then retry.
>
>The performance of this application is poor and I have through using DotTrace narrowed most of it down to the Web Service calls and the slowness has nothing to do with the time it takes for the web service to respond with data.
>
>My question is why might one need to use any kind of "Keep Alive" on a web service?
>Thanks
>Tim

A few reasons (although most of them aren't all that great). On is if you want to monitor the health of the other system calling your web service. If you don't receive the heartbeat within the expected period of time you know something may have failed on the other side. I wonder if they planned on doing something with that information but never got around to it (for example, send off a notification e-mail on failure).

Or they might do something like log into the site initially and get an expiring cookie (that's set for, lets say 20 minutes). The keep alive keeps this cookie from expiring (it hits the server then gets a new cookie w/a new expiration time). Honestly, in that example case you'd probably set the keep alive heartbeat to a few minutes. I've also seen web calls fail on the first call, then work on the second one. That usually has more to do with timing than anything else (ex. expiration/timeouts of calls before everything in the connection stack has had time to set things up). A ping is kind of a weird way to handle that, though - just retry the call like you said they're already doing.