Request rate is large

Question

Im using Azure documentdb and accessing it through my node.js on express server, when I query in loop, low volume of few hundred there is no issue. But when query in loop slightly large volume, say around thousand plus

I get partial results (inconsistent, every time I run result values are not same. May be because of asynchronous nature of Node.js) after few results it crashes with this error

body: '{"code":"429","message":"Message: {\"Errors\":[\"Request rate is large\"]}\r\nActivityId: 1fecee65-0bb7-4991-a984-292c0d06693d, Request URI: /apps/cce94097-e5b2-42ab-9232-6abd12f53528/services/70926718-b021-45ee-ba2f-46c4669d952e/partitions/dd46d670-ab6f-4dca-bbbb-937647b03d97/replicas/130845018837894542p"}' }

Meaning DocumentDb fail to handle 1000+ request per second? All together giving me a bad impression on NoSQL techniques.. is it short coming of DocumentDB?

Answer 1

As Gaurav suggests, you may be able to avoid the problem by bumping up the pricing tier, but even if you go to the highest tier, you should be able to handle 429 errors. When you get a 429 error, the response will include a 'x-ms-retry-after-ms' header. This will contain a number representing the number of milliseconds that you should wait before retrying the request that caused the error.

I wrote logic to handle this in my documentdb-utils node.js package. You can either try to use documentdb-utils or you can duplicate it yourself. Here is a snipit example.

createDocument = function() {
   client.createDocument(colLink, document, function(err, response, header) {
        if (err != null) {
            if (err.code === 429) {
                var retryAfterHeader = header['x-ms-retry-after-ms'] || 1;
                var retryAfter = Number(retryAfterHeader);
                return setTimeout(toRetryIf429, retryAfter);
            } else {
                throw new Error(JSON.stringify(err));
            }
        } else {
            log('document saved successfully');
        }
    });
};

Note, in the above example document is within the scope of createDocument. This makes the retry logic a bit simpler, but if you don't like using widely scoped variables, then you can pass document in to createDocument and then pass it into a lambda function in the setTimeout call.