Полностью остановилось получение входящих ЭВСД

Побывали вчера на конференции разработчиков, прониклись какие мы все неумехи, не можем запросы писать по бест-практис,
а оказывается с 4 часов ночи на 23 число вообще перестали приходить входящие ЭВСД. Окно 1000 (раньше работало) не проходит.
Делается 100 попыток с приличными интервалами (100 попыток занимает 23 минуты), и все равно хрен.
Окно 500 - прошло только одно окно из 10. Окно 250 - пока получено только два окна, висит по 10 минут на обработке одного окна.
Но окон должно быть 20!
Понятно, когда такие "архитекторы", которых нам вчера представили, странно что оно вообще взлетело.

и кто-то там выступил?
или все только лапшу слушали?

Оу, расскажите поподробней о встрече, очень интересно. Хоть и обещали выложить видео, но впечатление участника очень хочется услышать.

По поводу гашения входящих - подтверждаю. Со вчерашней ночи паузы и замедления.
У нас разбито на загрузку из 1С отправку автоматически по небольшим партиям заявок (накладных).
У нас схема с двумя нашими ХС, один производитель, второй продавец. Так вот чтобы отправить на контрагента, мы создаём производственные транзакции на одном ХС, смена владельца без перевозки, гашение на втором ХС и отправка контрагентам.
Так вот гашение входящих ВСД тут вообще стало работать ну очень медленно.
Вчера с 00:22 до 00:55 по Москве - пауза в попытке гашения входящих, сервер API просто не отвечал (Сибирь).
Потом с 00:55 по 02:30 было погашено 129 входящих ВСД.
И так партиями, по примерно 100 штук гасилось, но на это стало уходить около часа (час на гашение 100 штук, Карл!). А ведь мы сейчас не на полную мощность работаем. Что будет, если мы вернёмся на прежние объёмы, я не знаю, мне страшно.
Если разработчики поинтересуются, могу предоставить все логи. Вместе с ApplicationID и проч.

Разработчикам похрену. "Архитектор" судя по всему "программист от бога", раз сразу после школы
пришел лабать федеральную систему, дальше "такого быть не может" не продвинулся.

Пол встречи толкали разные продукты - шлюзы. Четверть встречи рассказывали, что виноваты во всем мы сами.
Четверть встречи - вопросы, но ответы на них были слабенькие.
Раньше у меня конспект занимал несколько листов, а сейчас два абзаца.

1) Нам были перечислены нежелательные практики:
- Опрос истории изменений делать не чаще чем каждые 15 минут, а лучше реже.
- Подбор записей журнала перед отгрузкой делать не из меркурия, а из своего регистра остатков.
- Стараться в пределах минуты делать равномерную загрузку шлюза
(регламентные задания у некоторых сваливаются все на одну секунду в запросах).
- Результат по заявке запрашивать через определенный интервал и с определенной периодичностью,
некоторые долбят сразу после отправки по 15 раз в секунду.
- По старым заявкам просят ничего не запрашивать,
через три дня они уже уходят в архив и недоступны для запроса.
- Сохранять у себя ответ по заявке, не запрашивать результат раз по 30
- Следить за объемом записей в ответе, не запрашивать новые смещения до бесконечности
- Не злоупотреблять объединениями записей и инвентаризацией,
некоторые дообъединялись до того что у них диапазон срока годности охватывают период до года.
- Анализировать системные ошибки и исправлять схему работы
- Анализировать ошибки в бизнес-логике и исправлять схему работы
- Запрет на интеграцию через автоматизацию веб-сервиса.

Далее нам пообещали, что через неделю выйдет на тестирование
отдельная очередь для тяжелых запросов, а еще через неделю выйдет официально.
Быстрые запросы будут пролетать с высшим приоритетом,
наши запросы входящих ЭВСД и остатков будут толпиться в тамбуре и умрут совсем.

Начиная с ноября месяца начнутся проводиться проверки нашей работы в Меркурий, со всеми вытекающими.

Готовится кнопка блокировки получения товара/возврата от поставщиков с пониженным компартментом,
а также от тех, кто работает в интерфейсе 1.4.

Все остальное - больше похоже на отмазки.

Спасибо.
Короче ясно, света в конце тоннеля нет. Или это другой приближающийся поезд.
Кнопку они там придумывают. Проверку работы мутят. Что-то я вдруг стал уверен, что выйду я из этой неблагодарной темы, гори оно всё конём.

Своей слабой реализацией они добились того что нагрузка на базу идет паразитная (без конечного результат), которой могло бы и не быть.
Я гарантирую что если я буду делать 1 запрос в день у меня он не отработает, даже 2 запроса в день, где балансер в этом случае находится?
Прально нигде ибо его нет.
А то что мы во всем виноваты это конечно, у них 20 кратный запас прочности был а в итоге и в 2 раза не смогли увеличить поток документов.

sup wrote:Своей слабой реализацией они добились того что нагрузка на базу идет паразитная (без конечного результат), которой могло бы и не быть.
Я гарантирую что если я буду делать 1 запрос в день у меня он не отработает, даже 2 запроса в день, где балансер в этом случае находится?
Прально нигде ибо его нет.
А то что мы во всем виноваты это конечно, у них 20 кратный запас прочности был а в итоге и в 2 раза не смогли увеличить поток документов.

Ну, это все видели, что что вы ждете от поколения майкрософт.
Хотя нет, это уже дети андроид. Избыточность видна любому, у кого есть глаза и желание.

Добрый день!
А не рассказали когда же наконец закроют возможность присылать ВСД без гуида номенклатуры через веб?

Обещали дать возможность погасить документы которые не гасятся, а потом синхронизировать правила:
сейчас выписать дает, а погасить - нет.
Про строковые названия не говорили.

TWAIN wrote:
1) Нам были перечислены нежелательные практики:
- Опрос истории изменений делать не чаще чем каждые 15 минут, а лучше реже.

А это - у кого как идут изменения. У кого-то один раз вечером все пришедшее погасить, а у кого-то постоянно идут исходящие, входящие и производственные! Или рассчитывали на 2 ларька на всю страну?

TWAIN wrote:
- Стараться в пределах минуты делать равномерную загрузку шлюза

Как как? Они там сугубо альтернативно-одаренные личности? У них не 2 источника запросов! О законе больших чисел никогда не слышали? Само равномеризуется, если источников много. Даже при синхронизации времени на источниках запросов по атомным часам и из интернета, все равно, разная пропускная способность и загрузка каналов между источниками запросов и шлюзом равномеризует нагрузку (в пределах секунд, конечно, а не суток).

TWAIN wrote:
- По старым заявкам просят ничего не запрашивать, через три дня они уже уходят в архив и недоступны для запроса.

О! Наконец-то озвучено время, которое заявка может быть in_progress!

TWAIN wrote:
- Анализировать системные ошибки и исправлять схему работы
- Анализировать ошибки в бизнес-логике и исправлять схему работы

Пожелания самим себе.

TWAIN wrote:- Запрет на интеграцию через автоматизацию веб-сервиса.

А вот это - вряд ли. Они ещё нам будут указывать, какой рукой мышку держать, когда по их сайту ходим!

TWAIN wrote:Пол встречи толкали разные продукты - шлюзы. Четверть встречи рассказывали, что виноваты во всем мы сами.

Кстати, я подозреваю что API просаживается именно от этих продуктов, которые они и толкают. Поскольку нетиповые решения занимают значительно меньшую часть рынка.

Владимир Игнатов wrote:

TWAIN wrote:
1) Нам были перечислены нежелательные практики:
- Опрос истории изменений делать не чаще чем каждые 15 минут, а лучше реже.

А это - у кого как идут изменения. У кого-то один раз вечером все пришедшее погасить, а у кого-то постоянно идут исходящие, входящие и производственные! Или рассчитывали на 2 ларька на всю страну?

Ну, исходящие вы знаете ID и запрашиваете конкретно по ID, производственные - тоже.
Речь идет о синхронизации больших списков.

Владимир Игнатов wrote:

TWAIN wrote:
- Стараться в пределах минуты делать равномерную загрузку шлюза

Как как? Они там сугубо альтернативно-одаренные личности? У них не 2 источника запросов! О законе больших чисел никогда не слышали? Само равномеризуется, если источников много. Даже при синхронизации времени на источниках запросов по атомным часам и из интернета, все равно, разная пропускная способность и загрузка каналов между источниками запросов и шлюзом равномеризует нагрузку (в пределах секунд, конечно, а не суток).

Тут тоже понятно что хотят. В 1С все задания любят сбрасываться на 1 секунду.
30 регламентных заданий, а запускаются все одновременно.

Владимир Игнатов wrote:

TWAIN wrote:
- По старым заявкам просят ничего не запрашивать, через три дня они уже уходят в архив и недоступны для запроса.

О! Наконец-то озвучено время, которое заявка может быть in_progress!

Уже второй раз озвучена. Сначала было 10 минут. Потом увеличили до часа, кажется. Сейчас - полчаса.
Мы и сами эмпирически получали и они сказали.

Vladimir2017 wrote:

TWAIN wrote:Пол встречи толкали разные продукты - шлюзы. Четверть встречи рассказывали, что виноваты во всем мы сами.

Кстати, я подозреваю что API просаживается именно от этих продуктов, которые они и толкают. Поскольку нетиповые решения занимают значительно меньшую часть рынка.

Да, это озвучено давно. Виноваты на 70% 1С, которые выпустили поддержку меркурий 15 июня.
Через 10 дней все запустили обновление списков и с 25 числа мы фиксируем проблемы.

TWAIN wrote:

Владимир Игнатов wrote:

TWAIN wrote:
1) Нам были перечислены нежелательные практики:
- Опрос истории изменений делать не чаще чем каждые 15 минут, а лучше реже.

А это - у кого как идут изменения. У кого-то один раз вечером все пришедшее погасить, а у кого-то постоянно идут исходящие, входящие и производственные! Или рассчитывали на 2 ларька на всю страну?

Ну, исходящие вы знаете ID и запрашиваете конкретно по ID, производственные - тоже.

А зачем? Я все равно синхронизирую все, и свои и чужие, поэтому все по get...changes... Зачем организовывать 2 очереди, 2 обработчика и т.д.? Забираем все от времени последнего изменения, все обрабатываем. Проще, линейнее обработка.

TWAIN wrote:

Владимир Игнатов wrote:

TWAIN wrote:
- Стараться в пределах минуты делать равномерную загрузку шлюза

Как как? Они там сугубо альтернативно-одаренные личности? У них не 2 источника запросов! О законе больших чисел никогда не слышали? Само равномеризуется, если источников много. Даже при синхронизации времени на источниках запросов по атомным часам и из интернета, все равно, разная пропускная способность и загрузка каналов между источниками запросов и шлюзом равномеризует нагрузку (в пределах секунд, конечно, а не суток).

Тут тоже понятно что хотят. В 1С все задания любят сбрасываться на 1 секунду.
30 регламентных заданий, а запускаются все одновременно.

И поедут разными пакетами по Интернету. И наложатся на 1000 еще таких же, даже в ту же секунду сработавших, но из других городов и весей. И при приходе к их шлюзу все запросы сами расползутся на несколько секунд.

Объясню проще. Допустим у многих идет работа по расписанию.
Думаю, половина запускает раз в 15 минут, четверть раз в полчаса, четверть раз в час.
В результате в 12:00 к ним валится несколько тысяч запросов списков
от всех интеграторов и все получают дружную 12-ю ошибку.

с 1С не совсем так, но там тоже не все хорошо.