aboutsummaryrefslogtreecommitdiffstats
path: root/cloud_mdir_sync/gmail.py
diff options
context:
space:
mode:
authorJason Gunthorpe <jgg@mellanox.com>2020-06-12 16:36:38 -0300
committerJason Gunthorpe <jgg@nvidia.com>2020-06-22 20:24:18 -0300
commitc87f4221dc92c18a9d193ddeae60218f83282b96 (patch)
tree35dd099392530840097611cea4b41d07ecef49bc /cloud_mdir_sync/gmail.py
parente241f83acb481c08881050d8b07717be7784bcc3 (diff)
downloadcloud_mdir_sync-c87f4221dc92c18a9d193ddeae60218f83282b96.tar.gz
cloud_mdir_sync-c87f4221dc92c18a9d193ddeae60218f83282b96.tar.bz2
cloud_mdir_sync-c87f4221dc92c18a9d193ddeae60218f83282b96.zip
O365: Use batching during modification
For whatever reason this week the concurrency limit in Graph went way down for modify, this event impacts the batches. It turns out graph is crazy. You can put up to 20 requests in a batch, but during execution they can fail with throttling and need retry. Experiments suggest 3 is the right number to avoid throttling on modify, for some reason. Documentation seems wrong, and probably something broke recently. Implement batching, run the batch break up sequentially, and limit the batches to 3. Use batching only for modify operations. GET can still use a concurrency limit of 5. Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Diffstat (limited to 'cloud_mdir_sync/gmail.py')
0 files changed, 0 insertions, 0 deletions