Мы используем Cosmos DB SDK, версия которого 2.9.2. Мы выполняем операции Document CRUD. Обычно сквозная задержка P95 составляет 20 мс. Но иногда задержка составляет более 1000 мс. Период высокой задержки длится от 10 часов до 1 дня. Коллекция не регулируется.
Мы получили некоторую справочную информацию от: https://icm.ad.msft.net/imp/v3/incidents/details/171243015/home https://icm.ad.msft.net/imp/v3/incidents/details/168242283/home В билетах есть несколько диагностических строк.
Мы знаем, что клиент поддерживает кэш отображения логического раздела и адреса физической реплики. Это сопоставление может быть устаревшим из-за перемещения или сбоя реплик. Таким образом, клиент пытается прочитать из второй / третьей реплики. Тем не менее, эта повторная попытка оказывает существенное влияние на сквозную задержку. Мы также наблюдаем, что высокая задержка / время ожидания может длиться несколько часов, даже дней. Я ожидаю, что есть некоторый механизм обновления кеша отображения в клиенте. Но кажется, что клиент перестает посещать более одной реплики только после того, как мы повторно развернем наш сервис. Вот мои вопросы:
- Как клиент может определить, не может ли он подключиться к определенной реплике? Будет ли клиент ждать, пока тайм-аут или сервер не сообщит клиенту, что реплика недоступна?
- При каких условиях будет обновляться кэш сопоставления? Мы используем согласованность сеансов и режим TCP.
- Перезапуск нашего сервиса заставит кэш обновляться? Или обновление происходит только при перезапуске машины?
- Когда мы обнаруживаем, что реплика отключена, есть ли способ быстро устранить проблему?