mirror of
https://github.com/facebook/sapling.git
synced 2024-10-06 23:07:18 +03:00
6ac0c26e06
Summary: Limits on concurrent calls are a bit hard to reason about, and it's not super obvious what a good limit when all our underlying limits are expressed in QPS (and when our data sets don't have peak concurrency - instead they have completion time + # blob accesses). Considering our past experience with ThrottledBlob has been quite positive overall, I'd like to just use the same approach in ContextConcurrencyBlobstore. To be safe, I've also updated this to be driven by tunables, which make it easier to rollout and rollback. Note that I removed `Debug` on `CoreContext` as part of this because it wasn't used anywhere. We can bring back a meaningful implementation of `Debug` there in the future if we want to. That triggered some warnings about unused fields, which for now I just silenced. Reviewed By: farnz Differential Revision: D21449405 fbshipit-source-id: 5ca843694607888653a75067a4396b36e572f070 |
||
|---|---|---|
| .. | ||
| cacheblob | ||
| chaosblob | ||
| context_concurrency_blobstore | ||
| delayblob | ||
| factory | ||
| fileblob | ||
| if | ||
| memblob | ||
| multiplexedblob | ||
| prefixblob | ||
| readonlyblob | ||
| redactedblobstore | ||
| samplingblob | ||
| sqlblob | ||
| src | ||
| test | ||
| throttledblob | ||
| Cargo.toml | ||