Does ExecuteQuery have a cache/timeout/etc?

Question

I wasn't sure how to phrase the title, forgive me. I'm running into an issue with the CSOM (SharePoint 2010, but likely in 2013 as well), where my initial ExecuteQuery() statement takes upwards of 20 seconds, and successive requests take less than a second. If a minute or two lapses between requests, the first ExecuteQuery() request after the lapse will take another 20+ seconds. See below for my sample code and data results.

void Main()
{
    var listId = new Guid("60558323-bd04-45b7-946f-b70709e6a001");
    var listItemId = 15629;
    for (int i = 0; i < 25; i++)
    {
        Debug.WriteLine("Waiting " + i*10 + "s...");
        Thread.Sleep(i*10*1000);
        var sw = new Stopwatch();
        sw.Start();
        var listItemUrl = GetServerRelativeListItemUrl(listId, listItemId);
        sw.Stop();      
        Debug.WriteLine("Request took " + sw.ElapsedMilliseconds.ToString() + " ms.");
    }   
}

public string GetServerRelativeListItemUrl(Guid listId, int listItemId)
{
  using (var clientContext = this.GetClientContext())
  {
      var web = clientContext.Web;
      clientContext.Load(web);

      var list = web.Lists.GetById(listId);
      clientContext.Load(list);

      var listItem = list.GetItemById(listItemId);
      clientContext.Load(listItem);
      clientContext.Load(listItem.File);
      clientContext.ExecuteQuery();

      var listItemUrl = listItem.File.ServerRelativeUrl;
      return listItemUrl;
  }
}

protected ClientContext GetClientContext()
{
    var clientContext = new ClientContext("http://{url redacted}");
    clientContext.Credentials = CredentialCache.DefaultCredentials;
    return clientContext;
}

And my output:

    Waiting 0s...
    Request took 693 ms.
    Waiting 10s...
    Request took 37 ms.
    Waiting 20s...
    Request took 390 ms.
    Waiting 30s...
    Request took 39 ms.
    Waiting 40s...
    Request took 35 ms.
    Waiting 50s...
    Request took 357 ms.
    Waiting 60s...
    Request took 39 ms.
    Waiting 70s...
    Request took 350 ms.
    Waiting 80s...
    Request took 343 ms.
    Waiting 90s...
    Request took 340 ms.
    Waiting 100s...
    Request took 347 ms.
    Waiting 110s...
    Request took 688 ms.
    Waiting 120s...
    Request took 690 ms.
    Waiting 130s...
    Request took 689 ms.
    Waiting 140s...
    Request took 24592 ms.
    Waiting 150s...
    Request took 21804 ms.
    Waiting 160s...
    Request took 21765 ms.
    Waiting 170s...
    Request took 21784 ms.
    Waiting 180s...
    Request took 21766 ms.
    Waiting 190s...
    Request took 23854 ms.
    Waiting 200s...
    Request took 21772 ms.
    Waiting 210s...
    Request took 21763 ms.
    Waiting 220s...
    Request took 21979 ms.
    Waiting 230s...
    Request took 24496 ms.

Note that the first request doesn't take the full 20+ seconds because I had run an ExecuteQuery immediately prior to that. Had it been first run, it would've taken the full time.

Is there some kind of internal cache or timeout in the SharePoint Client Object Model that would be causing this delay when there are no requests for 140ish+ seconds? I can't find any documentation pointing to this, but I can definitely see it in action.

Answer 1

I know in the JavaScript Client Object Model executeQueryAsync is performed using an XmlHttpRequest, the results of which are cached by default. I would assume the managed client object model requests data using the same method 'under the covers'

As for how long the cached request is valid, it appears to be dependent upon the user's browser configuration.

If you inspect an executeQuery response (in Fiddler, for example) you'll see that no 'cache lifetime' information is specified in the response. If you look at the cache tab in Fiddler, it will tell you this:

This response does not specify explicit HTTP Cache Lifetime information and does not specify a Last-Modified date. Heuristic expiration is typically based on Last-Modified date. Lacking Last-Modified, this response may be revalidated on every use or once per browsing session, depending on the browser configuration.

Which complies with the W3 HTTP 1.1 caching specification.

You'll also notice that the executeQuery responses will not contain a last modified time or etag -- which are other common methods of telling a browser when it should request new information.

Each browser behaves differently in regard to what they decide to cache -- most allow the user to provide some configuration on what happens when no server values are present: For example, IE allows you to specify 'Every time I visit the web page', 'Every time I start Internet Explorer', 'Automatic', or 'Never' for when it caches http responses and modifies its behavior according to the user's specification. 'Automatic' causes IE to use an algorithm to determine how often it should refresh content (based on how often it thinks that the content changes). This example information applies specifically to IE9, but as far as I know works similarly across all versions later than 6.0.

So in summary, I'd like to tell you 'the default cache timeout is xx seconds' but the answer really is that it depends...

Answer 2

Don't know if it helps, but ClientContext object has a timeout property

clientContext.RequestTimeout = Timeout.Infinite;

However, you'll be tight to the timeout in the Webserver (IIS). No idea about Cache, but John-o reply seems very good to me.