В Bitrix24 есть ограничение на количество запросов к API, там примерно 2 запроса в секунду. Если превысить этот лимит, система вернет ошибку 503 QUERY_LIMIT_EXCEEDED. Короткие всплески запросов допустимы, но постоянная высокая нагрузка не пройдет.
С файлами лимиты достигаются реже. Их загрузка происходит медленнее, а размер файла увеличивается после кодирования в base64, поэтому запросы обычно не превышают допустимую частоту. Перечитывать файлы стоит только для особо важных данных, а для обычной синхронизации достаточно проверять ответ API.
При загрузке большого количества файлов основная проблема в размере передаваемых данных и таймауты. Десяток фотографий легко превышают 50 МБ, поэтому файлы лучше отправлять по одному.
Важно помнить, что лимит API общий для одного IP-адреса. Если несколько интеграций работают с одного сервера, они делят этот лимит между собой.
Для обработки большого потока данных лучше использовать очередь задач с отдельным воркером. При получении ошибки 503 стоит настроить повторные попытки с увеличением интервала. Для нефайловых данных можно отправлять группы до 50 команд за раз (батчем). Для файлов такой подход неэффективен из-за ограничений на размер тела запроса.
Подробную информацию о лимитах можно найти в документации: apidocs.bitrix24.ru/limits.html.
Поисковики на это не опираются. В сайтах зашит robots.txt - по сути это разрешение от сайта, что и в каком объёме индексировать.И поисковик не замещает источник, тк он отдаёт сниппет со ссылкой и возвращает читателя на площадку. В той же 1335.1 ключевое ограничение звучит как «необоснованное ущемление интересов изготовителя базы», а поисковик их наоборот обслуживает. Плюс у поисковиков есть отдельный статус информационного посредника (1253.1 ГК) со своим режимом ответственности, а это вообще другая правовая конструкция, чем извлечение материалов пользователем.
Вашу гипотезу проверил. Длинные статьи (3000+ слов) в будни дают медианный рейтинг 10, в выходные 9, разница незначима (p=0.65). Короткие: 6 против 4, тоже незначимо. Утро против вечера также, ни для длинных, ни для коротких значимой разницы нет. длина работает одинаково во все дни. Интересно то, что длинные стабильно берут выше коротких (8–11 против 3–7), и это держится и в понедельник, и в субботу. То есть взаимодействия день x длина нет, есть просто эффект длины сам по себе.
Также воскресенье проваливает всё подряд независимо от длины (рейтинг 3–4), а суббота даёт лучший охват, но скорее всего это просто потому что публикаций в этот день вдвое меньше и конкуренция за ленту ниже.
Расширение не обходит никакой защиты. Оно читает открытые статьи через сессию самого пользователя, держит полторы секунды между запросами и замолкает на три минуты по первому же 429. Сохраняет локально, с указанием автора и ссылкой на оригинал, никуда не публикует.
По ГК на личное использование обнародованного есть 1273 и 1335.1, а соглашение Хабра само делает исключение для личного некоммерческого сохранения с сохранением атрибуции. Так что герру майору показывать особо нечего :)
По цифрам соглашусь, как отдельный ESP оно зарплату не отбивает :) И не задумывалось так. Это часть связки своих сервисов, которой пользуемся сами и предлагаем клиентам с данными в РФ. Экономика не от объёма писем, а от достроенного куска своего продукта.
Мы просто сделали сервис полностью попадающий под 152-ФЗ и данные в РФ. Тк согласно текущему законодательству сервисы типа Postmark и подобных, которые не из РФ, компаниям использовать нельзя
Да, вы правы, но я в статью это решил не добавлять, тк раздел был про записи в своей зоне, а PTR ставится на стороне провайдера IP. Но по важности пункт того же порядка, соглашусь. У нас он проставлен и совпадает с HELO.
Формулировка немного неточная. DMARC не третья проверка в ряд, а политика поверх SPF и DKIM: хватает одного выровненного механизма. По Mail.ru и Яндексу логика та же, они отличаются только весами.
Спасибо, замечания справедливые. С колонками я действительно накосячил: сравнил разные Y. Перепроверил на одинаковом рейтинге - знаки всё равно меняются, так что вывод остался тем же, но показать это сразу было бы честнее.
С log тоже верно: я обрезал отрицательные рейтинги до нуля. Это не лучшая обработка данных. Если использовать рейтинг как есть, качество модели было бы даже ниже.
На главный вывод это не влияет: форма статьи объясняет очень мало. Но оформить и объяснить методику стоило аккуратнее. Учту на будущее.
Вы правы, на обложке визуализация того, что написано в тексте, а не реальный scatter по датасету. Я чуть позже сделаю график и пришлю вам сюда, чтобы вы могли ознакомиться :)
Про разные скорости вы точно сформулировали то, что у меня в статье осталось между строк: рейтинг набирается в первые сутки-двое и потом почти замирает, а охват копится месяцами через поиск и внешние ссылки. Это две отдельные метрики с разной динамикой, и оптимизируются они тоже по-разному: рейтинг через форму и первое впечатление на день публикации, охват же через тему, которую ищут годами. Ваша "FullHD vs 4K с integer scaling" и "освещённость рабочего места" - это то, что будет тянуть трафик из поиска ещё долго, даже с рейтингом 3 и 12.
Про формат не обязательно поздно, я не знаю точно, реагирует ли алгоритм на смену метки уже опубликованного материала, но в интерфейсе она меняется. Если поменяете "Туториал" на "Кейс", то интересно будет посмотреть через недельку, сдвинется ли что-то. Если да, то это будет полезное наблюдение для следующей итерации моего разбора.
Я согласен, что в интерфейсе нет порога >=7, и через неделю статью с рейтингом 7 почти не видно, вы правы. Я имел в виду, что нужно понимать, чего ожидать сразу после публикации. Если у статьи через сутки 7 плюсов, автор может посчитать это провалом, хотя это средний показатель для этой площадки. А вот то, как долго статья будет находиться в поиске, - это уже другой показатель, и там действительно нужно 10 плюсов.
Заглянул в ваши статьи. По охлаждению Mini-PC хабы у вас как раз сильные - DIY и Читальный зал, у них медианный рейтинг 18 и 14, то есть с хабами всё правильно,И 9 рейтинга при них уже нижняя часть распределения, а не провал. А вот у "3D-игр на слабой видеокарте" стоит формат "Туториал", и это как раз тот единственный формат, который по моим данным на личных блогах значимо проседает, там медиана 4 против 7 у неуказанного, p=0.018. Кейс или просто снять формат, по идее, должно тянуть вверх. Но это только гипотиза :)
В Bitrix24 есть ограничение на количество запросов к API, там примерно 2 запроса в секунду. Если превысить этот лимит, система вернет ошибку 503 QUERY_LIMIT_EXCEEDED. Короткие всплески запросов допустимы, но постоянная высокая нагрузка не пройдет.
С файлами лимиты достигаются реже. Их загрузка происходит медленнее, а размер файла увеличивается после кодирования в base64, поэтому запросы обычно не превышают допустимую частоту. Перечитывать файлы стоит только для особо важных данных, а для обычной синхронизации достаточно проверять ответ API.
При загрузке большого количества файлов основная проблема в размере передаваемых данных и таймауты. Десяток фотографий легко превышают 50 МБ, поэтому файлы лучше отправлять по одному.
Важно помнить, что лимит API общий для одного IP-адреса. Если несколько интеграций работают с одного сервера, они делят этот лимит между собой.
Для обработки большого потока данных лучше использовать очередь задач с отдельным воркером. При получении ошибки 503 стоит настроить повторные попытки с увеличением интервала. Для нефайловых данных можно отправлять группы до 50 команд за раз (батчем). Для файлов такой подход неэффективен из-за ограничений на размер тела запроса.
Подробную информацию о лимитах можно найти в документации: apidocs.bitrix24.ru/limits.html.
Да
Логи добавлю в следующем обновлении, а насчёт описания картинок спасибо, исправлю это
Сохранение присутствует, надо включить в настройках
В настройках можно включить сохранение по типу и по хабу
Вот это очень полезно, спасибо!
Поисковики на это не опираются. В сайтах зашит robots.txt - по сути это разрешение от сайта, что и в каком объёме индексировать.И поисковик не замещает источник, тк он отдаёт сниппет со ссылкой и возвращает читателя на площадку. В той же 1335.1 ключевое ограничение звучит как «необоснованное ущемление интересов изготовителя базы», а поисковик их наоборот обслуживает. Плюс у поисковиков есть отдельный статус информационного посредника (1253.1 ГК) со своим режимом ответственности, а это вообще другая правовая конструкция, чем извлечение материалов пользователем.
Прикольно сделали, спасибо, что поделились
Интересная идея, спасибо, подумаю над этим на досуге :)
Вашу гипотезу проверил. Длинные статьи (3000+ слов) в будни дают медианный рейтинг 10, в выходные 9, разница незначима (p=0.65). Короткие: 6 против 4, тоже незначимо. Утро против вечера также, ни для длинных, ни для коротких значимой разницы нет. длина работает одинаково во все дни. Интересно то, что длинные стабильно берут выше коротких (8–11 против 3–7), и это держится и в понедельник, и в субботу. То есть взаимодействия день x длина нет, есть просто эффект длины сам по себе.
Также воскресенье проваливает всё подряд независимо от длины (рейтинг 3–4), а суббота даёт лучший охват, но скорее всего это просто потому что публикаций в этот день вдвое меньше и конкуренция за ленту ниже.
Расширение не обходит никакой защиты. Оно читает открытые статьи через сессию самого пользователя, держит полторы секунды между запросами и замолкает на три минуты по первому же 429. Сохраняет локально, с указанием автора и ссылкой на оригинал, никуда не публикует.
По ГК на личное использование обнародованного есть 1273 и 1335.1, а соглашение Хабра само делает исключение для личного некоммерческого сохранения с сохранением атрибуции. Так что герру майору показывать особо нечего :)
По цифрам соглашусь, как отдельный ESP оно зарплату не отбивает :)
И не задумывалось так. Это часть связки своих сервисов, которой пользуемся сами и предлагаем клиентам с данными в РФ. Экономика не от объёма писем, а от достроенного куска своего продукта.
Мы просто сделали сервис полностью попадающий под 152-ФЗ и данные в РФ. Тк согласно текущему законодательству сервисы типа Postmark и подобных, которые не из РФ, компаниям использовать нельзя
Да, вы правы, но я в статью это решил не добавлять, тк раздел был про записи в своей зоне, а PTR ставится на стороне провайдера IP. Но по важности пункт того же порядка, соглашусь. У нас он проставлен и совпадает с HELO.
Формулировка немного неточная. DMARC не третья проверка в ряд, а политика поверх SPF и DKIM: хватает одного выровненного механизма. По Mail.ru и Яндексу логика та же, они отличаются только весами.
Спасибо, замечания справедливые. С колонками я действительно накосячил: сравнил разные Y. Перепроверил на одинаковом рейтинге - знаки всё равно меняются, так что вывод остался тем же, но показать это сразу было бы честнее.
С
logтоже верно: я обрезал отрицательные рейтинги до нуля. Это не лучшая обработка данных. Если использовать рейтинг как есть, качество модели было бы даже ниже.На главный вывод это не влияет: форма статьи объясняет очень мало. Но оформить и объяснить методику стоило аккуратнее. Учту на будущее.
Вы правы, на обложке визуализация того, что написано в тексте, а не реальный scatter по датасету. Я чуть позже сделаю график и пришлю вам сюда, чтобы вы могли ознакомиться :)
Про разные скорости вы точно сформулировали то, что у меня в статье осталось между строк: рейтинг набирается в первые сутки-двое и потом почти замирает, а охват копится месяцами через поиск и внешние ссылки. Это две отдельные метрики с разной динамикой, и оптимизируются они тоже по-разному: рейтинг через форму и первое впечатление на день публикации, охват же через тему, которую ищут годами. Ваша "FullHD vs 4K с integer scaling" и "освещённость рабочего места" - это то, что будет тянуть трафик из поиска ещё долго, даже с рейтингом 3 и 12.
Про формат не обязательно поздно, я не знаю точно, реагирует ли алгоритм на смену метки уже опубликованного материала, но в интерфейсе она меняется. Если поменяете "Туториал" на "Кейс", то интересно будет посмотреть через недельку, сдвинется ли что-то. Если да, то это будет полезное наблюдение для следующей итерации моего разбора.
Я согласен, что в интерфейсе нет порога >=7, и через неделю статью с рейтингом 7 почти не видно, вы правы. Я имел в виду, что нужно понимать, чего ожидать сразу после публикации. Если у статьи через сутки 7 плюсов, автор может посчитать это провалом, хотя это средний показатель для этой площадки. А вот то, как долго статья будет находиться в поиске, - это уже другой показатель, и там действительно нужно 10 плюсов.
Заглянул в ваши статьи. По охлаждению Mini-PC хабы у вас как раз сильные - DIY и Читальный зал, у них медианный рейтинг 18 и 14, то есть с хабами всё правильно,И 9 рейтинга при них уже нижняя часть распределения, а не провал. А вот у "3D-игр на слабой видеокарте" стоит формат "Туториал", и это как раз тот единственный формат, который по моим данным на личных блогах значимо проседает, там медиана 4 против 7 у неуказанного, p=0.018. Кейс или просто снять формат, по идее, должно тянуть вверх. Но это только гипотиза :)
Самый простой вариант - вынести AdGuard Home с роутера на любое устройство в сети (NAS, мини-ПК, старый ноутбук) и указать его как DNS в DHCP