В репозитории dicechess-sync частота запросов истории партий регулируется на двух уровнях: на уровне индивидуальных сетевых запросов к API dicechess.com (для избежания блокировок и HTTP 429) и на уровне периодичности проходов планировщика/демона.
Все настройки задаются в config.ts.
1. Интервал между сетевыми запросами (Rate Limiter)
Все запросы к API (получение списка партий игрока getPlayerHistory и ходов конкретной партии getMoveHistory) проходят через единый RateLimiter. Запросы выполняются строго последовательно в один поток со следующей задержкой:
- Базовая задержка (
minDelayMs): по умолчанию 3000 мс (3 секунды). Регулируется переменной окруженияREQUEST_MIN_DELAY_MS. - Случайный шум / джиттер (
jitterMs): по умолчанию 1500 мс (1.5 секунды). Регулируется черезREQUEST_JITTER_MS. - Итоговый интервал в штатном режиме: случайное значение в диапазоне от 3 до 4.5 секунд.
- При блокировках (
cooldownMs): при получении ошибок403,429или5xxлимитер удваивает время ожидания (экспоненциальный бэкафф, начиная с 5 секунд и до 5 минут). - Лимит в час (
maxPerWindow): опционально можно ограничить максимальное число запросов в час переменной окруженияMAX_REQUESTS_PER_HOUR(по умолчаниюInfinity).
2. Периодичность работы демона синхронизации (crawl-service.ts)
Если crawler запущен как долгоиграющий демон (sync-crawl / crawl-service):
- Он обрабатывает очередь игроков пачками (батчами):
batchPlayers(по умолчанию 25 игроков) иbatchFetch(по умолчанию 200 партий) за один проход. - Пауза между проходами (
interPassMs): по умолчанию 0 мс (переходит к следующей пачке сразу же). Задается черезINTER_PASS_MS. - Период ожидания при пустой очереди (
idleMs): если новых игроков для синхронизации нет, демон засыпает на 300 000 мс (5 минут) перед повторной проверкой. Регулируется переменнойIDLE_MS. - Повторная синхронизация (
resyncAfterMs): по умолчанию отключена (0). Если задать черезRESYNC_AFTER_MS(в миллисекундах), то игроки, синхронизированные ранее этого времени, будут повторно отправляться в очередь на обновление.