Comments 4
Шикарный детектив получился!
С Битриксом не сталкивался, но масштаб таких граблей в статье впечатляет). История с фейковым HTTP 200, когда сервер рапортует об успехе, но файл по факту не сохраняет = жесткач. Подход с обязательным повторным запросом для проверки выглядит надежно, но, блин, из чистого любопытства хочу Вам задать вопрос: как у Битрикса сейчас дела с лимитами на API (Rate Limits)? Если с мобилок начинает лететь большой поток фото, система не начинает душить за такие двойные вызовы на каждую операцию?
В Bitrix24 есть ограничение на количество запросов к API, там примерно 2 запроса в секунду. Если превысить этот лимит, система вернет ошибку 503 QUERY_LIMIT_EXCEEDED. Короткие всплески запросов допустимы, но постоянная высокая нагрузка не пройдет.
С файлами лимиты достигаются реже. Их загрузка происходит медленнее, а размер файла увеличивается после кодирования в base64, поэтому запросы обычно не превышают допустимую частоту. Перечитывать файлы стоит только для особо важных данных, а для обычной синхронизации достаточно проверять ответ API.
При загрузке большого количества файлов основная проблема в размере передаваемых данных и таймауты. Десяток фотографий легко превышают 50 МБ, поэтому файлы лучше отправлять по одному.
Важно помнить, что лимит API общий для одного IP-адреса. Если несколько интеграций работают с одного сервера, они делят этот лимит между собой.
Для обработки большого потока данных лучше использовать очередь задач с отдельным воркером. При получении ошибки 503 стоит настроить повторные попытки с увеличением интервала. Для нефайловых данных можно отправлять группы до 50 команд за раз (батчем). Для файлов такой подход неэффективен из-за ограничений на размер тела запроса.
Подробную информацию о лимитах можно найти в документации: apidocs.bitrix24.ru/limits.html.
Благодарю за развернутый фидбэк!)) По ссылке детально изучу). Знаете, н самом деле, на контрасте со стеком n8n + amoCRM, работа с файлами в Битриксе выглядит как отдельный вид, если так сказать можно) .В amoCRM файлового API в привычном понимании долгое время вообще не было вроде как (все просто кидали ссылки во внешние облака), поэтому там связка с n8n и Redis подгружается на автомате, как базовый буфер. А вас в битриксе, получается, система пытается всё хранить внутри (в UF или диске), но из-за этого наворачивает жесткие лимиты на транспорт (те самые 2 рпс и base64). Извечный спор: монолит со своими правилами против распределенного кастомного стека...
Как я год загружал фото в Битрикс24 и собрал все грабли файлового API