How to get x-ms-request-id from Azure table storage api call

Question

I getting slow behavior for my azure tablestorage api calls on a windows azure app.I need to get the request id (x-ms-request-id in the response header) for a particular call. Is there a way I can get it using the storageclient api? Does the storage client api even expose this id? If not, is there any other way to get this id?

I am using the api in the following way:

        public UserDataModel GetUserData(String UserId)
    {
        UserDataModel osudm = null;
        try
        {
            var result = (from c in GetServiceContext().OrgUserIdTable
                          where (c.RowKey == UserId)
                          select c).FirstOrDefault();

            UserDataSource osuds = new UserDataSource(this.account);
            osudm = osuds.GetUserData(result.PartitionKey, result.UserName);
        }
        catch (Exception e)
        {
        }
        return osudm;
    }

Answer 1

What you're asking here is more related to WCF Data Services than it is to Windows Azure (the storage client client API uses this). Here is some example code how you can access the response headers:

    var tableContext = new MyTableServiceContext(...);
    DataServiceQuery<Order> query = tableContext.Orders.Where(o => o.RowKey == "1382898382") as DataServiceQuery<Order>;
    IEnumerable<Order> result = query.Execute();
    QueryOperationResponse response = result as QueryOperationResponse;

    string requestId;
    response.Headers.TryGetValue("x-ms-request-id", out requestId);

So what you'll be doing first is simply create your query and cast it to a DataServiceQuery of TType . Then you can call the Execute method on that query and cast it to a QueryOperationResponse . This class will give you access to all headers, including the x-ms-request-id .

Note that in this case you won't be able to use FirstOrDefault , since this doesn't return an IQueryable and you can't cast it to a DataServiceQuery of TType (unless there's an other way to do it using WCF Data Services).

Note: The reason why the call is so slow might be caused by your query. When you query the OrgUserIdTable table, you only filter based on the RowKey. I don't know how much data or partitions you have in that table, but if you don't use the PartitionKey this might have a significant performance impact. You have to know that, by not including the PartitionKey, you'll force a search on all partitions (possibly over multiple servers) which might be causing the call being so slow.

I suggest you take a look at the following real world guidance to get a better insight on how and why partitioning relates to performance in Windows Azure Storage: Designing a Scalable Partitioning Strategy for Windows Azure Table Storage