Не работает меркурий

Ооооооочень долго грузится продукция в журнал при гашении ЭВСД!!!!!!Так невозможно работать!!!!

AlexeyAv wrote:

Марья Юрьевна wrote:Да не возможно работать с веб.. машина стоит, уже 40 минут... ничего не падает на склад, не грузится.. всплывают надписи а-ля "При выполнении операции произошел конфликт, так как другой пользователь уже изменил данные, которые вы редактировали (удаляли)". Шлюз тупит, но хоть по чуть фурычит....Пишут на час работы, в итоге пол дня тупит( Это очень не серьезно...((

Я Вас расстрою, "на час" это завтра.

Эх..Лишь бы завтра подобного не было. Уже Пугает надпись "В четверг, 12 сентября, в период с 10:00 до 11:00 (МСК) доступ к веб-интерфейсу компонента Меркурий будет планово ограничен для всех пользователей на 1 час.".У нас завтра отгрузка в Таможенный союз, а там уже за простои машины штрафы в Евро.

Интересно, хоть кто-нибудь выставлял претензии к РСХН в связи с некорректной работой меркурия?

https://vetrf.ru/vetrf-forum/posts/list/0/9258.page#84435

Техподдержка, ау, может, все-таки хватит совести прокомментировать последние пару страничек топика, а?

Private wrote:Техподдержка, ау, может, все-таки хватит совести прокомментировать последние пару страничек топика, а?

Здравствуйте!

По Вашему обращению в службу технической поддержки сообщаем следующее.

В период пиковой нагрузки при работе в компоненте «Меркурий» через веб-интерфейс у части пользователей могут возникать трудности, связанные с задержками в отображении списков.
При этом, обращаем Ваше внимание, все совершаемые в системе действия фиксируются сразу.

Указанные ситуации возникают в связи с проведением нагрузочного тестирования (ссылка: http://fsvps.ru/fsvps/news/31827.html ).

Крестьянинов Иван wrote:При этом, обращаем Ваше внимание, все совершаемые в системе действия фиксируются сразу.

Интересно, какая польза от знания этого должна быть пользователям слоукурия?

Крестьянинов Иван wrote:В период пиковой нагрузки при работе в компоненте «Меркурий» через веб-интерфейс у части пользователей могут возникать трудности, связанные с задержками в отображении списков.
При этом, обращаем Ваше внимание, все совершаемые в системе действия фиксируются сразу.

Указанные ситуации возникают в связи с проведением нагрузочного тестирования (ссылка: http://fsvps.ru/fsvps/news/31827.html ).

"у части пользователей"??? Простите, я представитель интегратора, который успешно реализовал ~50 проектов интеграции учетных систем клиентов с Меркурием, для которых сейчас мы сами оказываем техническую поддержку, так вот на этой неделе не было ни одного клиента, кто не столкнулся бы как минимум со значительной задержкой отображения журнала продукции, а в большинстве - с пустыми ответами на актуализацию стока. Причем все это не "через веб-интерфейс", а именно через ВетИС.API. Обращения, направленные в адрес api@vetrf.ru, остаются без ответа, т.е. техподдержка придерживается принципа "сделаем вид, что ничего не получали, авось, само рассосется", так?

Крестьянинов Иван wrote:

Private wrote:Техподдержка, ау, может, все-таки хватит совести прокомментировать последние пару страничек топика, а?

Здравствуйте!

По Вашему обращению в службу технической поддержки сообщаем следующее.

В период пиковой нагрузки при работе в компоненте «Меркурий» через веб-интерфейс у части пользователей могут возникать трудности, связанные с задержками в отображении списков.
При этом, обращаем Ваше внимание, все совершаемые в системе действия фиксируются сразу.

Указанные ситуации возникают в связи с проведением нагрузочного тестирования (ссылка: http://fsvps.ru/fsvps/news/31827.html ).

Скажите это сетям, которые не видят наши эВСД и разворачивают авто

А ведь ноябрь ещё не наступил.
То ли ещё будет.

Ну так для справки.

Актуализация классификаторов в типовой 1С сделана так. По каждому справочнику запрашиваются изменения с даты последней синхронизации. Т.е. запрашиваются изменения по всей России. С настройками по умолчанию это запускается каждый час. Дальше изменения по тем объектам. которые есть в ИБ, соответственно загружаются эти объекты.

Если учет не поддерживался в актуальным состоянии (например попробовали интеграцию, не понравилось или не потребовалось и это регламентное задание отключили). Потом понадобилось - будет "догонять" справочник до текущего состояния именно так.
3 самых крупных справочника (продукция, ХС, предприятия).
У меня был реальный опыт когда в базе 1С включили интеграцию, бросили а потом через 1.5 месяца решили использовать. И вот: номенклатуры заведено 300 позиций. Вместо того чтобы опросить эти 300 позиций, 1С же добросовестно запрашивала изменения за 1.5 месяца, а это было около 1 миллиона записей. За неделю справочник до актуального состояния довела. И это только справочник продукции. Мерк отдает по 1000 записей за раз, вечером и в выходные это работало, а днем нет. Задержки при запросах дальних периодов истории от 40 секунд, когда больше 60 секунд Мерк уже выдавал ошибку, пришлось количество в запросе уменьшать до 200.

То есть вместо запроса 300 записей 1С запросила 1 млн, а это, минуточку, в 3 тысячи раз больше чем надо. Причем запросы к истории для Меркурия как я видел, были намного тяжелее запросов к актуальным данным. Потому что по мере того, как даты запросов подходили к текущей, время ответа уменьшалось. И это только продукция.

Когда я столкнулся с аналогичной проблемой следующий раз (опять несколько сотен элементов в справочнике продукции, но классификатор был годичной давности, что означало что только на актуализацию справочник номенклатуры она запросит около 9 миллионов записей, и это займет пару месяцев), я уже так делать не стал и конечно написал свою обработку, которая эти 3 справочника опросила поэлементно (т.е только то что нужно в базе), на что ушло 2 минуты.

Но даже в текущем рабочем режиме когда запрос изменений идет каждый час, по справочнику продукции приходит в среднем 1000 изменений. 24 тыс. за день, 9 млн. за год. Реально нужно за год от силы 200 шт. Вот и считайте сами куда ресурсы серверов уходят.

И это типовая 1С (т.е. то что используется массово, т.е. десятки тысяч ХС).

Я бы на месте технической службы Меркурий обратил бы внимание на такие вещи и потребовал бы переделать по уму.

Afanasiev.Vitaly wrote:Ну так для справки.

Актуализация классификаторов в типовой 1С сделана так. По каждому справочнику запрашиваются изменения с даты последней синхронизации. Т.е. запрашиваются изменения по всей России. С настройками по умолчанию это запускается каждый час. Дальше изменения по тем объектам. которые есть в ИБ, соответственно загружаются эти объекты.

Если учет не поддерживался в актуальным состоянии (например попробовали интеграцию, не понравилось или не потребовалось и это регламентное задание отключили). Потом понадобилось - будет "догонять" справочник до текущего состояния именно так.
3 самых крупных справочника (продукция, ХС, предприятия).
У меня был реальный опыт когда в базе 1С включили интеграцию, бросили а потом через 1.5 месяца решили использовать. И вот: номенклатуры заведено 300 позиций. Вместо того чтобы опросить эти 300 позиций, 1С же добросовестно запрашивала изменения за 1.5 месяца, а это было около 1 миллиона записей. За неделю справочник до актуального состояния довела. И это только справочник продукции. Мерк отдает по 1000 записей за раз, вечером и в выходные это работало, а днем нет. Задержки при запросах дальних периодов истории от 40 секунд, когда больше 60 секунд Мерк уже выдавал ошибку, пришлось количество в запросе уменьшать до 200.

То есть вместо запроса 300 записей 1С запросила 1 млн, а это, минуточку, в 3 тысячи раз больше чем надо. Причем запросы к истории для Меркурия как я видел, были намного тяжелее запросов к актуальным данным. Потому что по мере того, как даты запросов подходили к текущей, время ответа уменьшалось. И это только продукция.

Когда я столкнулся с аналогичной проблемой следующий раз (опять несколько сотен элементов в справочнике продукции, но классификатор был годичной давности, что означало что только на актуализацию справочник номенклатуры она запросит около 9 миллионов записей, и это займет пару месяцев), я уже так делать не стал и конечно написал свою обработку, которая эти 3 справочника опросила поэлементно (т.е только то что нужно в базе), на что ушло 2 минуты.

Но даже в текущем рабочем режиме когда запрос изменений идет каждый час, по справочнику продукции приходит в среднем 1000 изменений. 24 тыс. за день, 9 млн. за год. Реально нужно за год от силы 200 шт. Вот и считайте сами куда ресурсы серверов уходят.

И это типовая 1С (т.е. то что используется массово, т.е. десятки тысяч ХС).

Я бы на месте технической службы Меркурий обратил бы внимание на такие вещи и потребовал бы переделать по уму.

Лайк!

Shmel wrote:

Afanasiev.Vitaly wrote:Ну так для справки.

Актуализация классификаторов в типовой 1С сделана так. По каждому справочнику запрашиваются изменения с даты последней синхронизации. Т.е. запрашиваются изменения по всей России. С настройками по умолчанию это запускается каждый час. Дальше изменения по тем объектам. которые есть в ИБ, соответственно загружаются эти объекты.

Если учет не поддерживался в актуальным состоянии (например попробовали интеграцию, не понравилось или не потребовалось и это регламентное задание отключили). Потом понадобилось - будет "догонять" справочник до текущего состояния именно так.
3 самых крупных справочника (продукция, ХС, предприятия).
У меня был реальный опыт когда в базе 1С включили интеграцию, бросили а потом через 1.5 месяца решили использовать. И вот: номенклатуры заведено 300 позиций. Вместо того чтобы опросить эти 300 позиций, 1С же добросовестно запрашивала изменения за 1.5 месяца, а это было около 1 миллиона записей. За неделю справочник до актуального состояния довела. И это только справочник продукции. Мерк отдает по 1000 записей за раз, вечером и в выходные это работало, а днем нет. Задержки при запросах дальних периодов истории от 40 секунд, когда больше 60 секунд Мерк уже выдавал ошибку, пришлось количество в запросе уменьшать до 200.

То есть вместо запроса 300 записей 1С запросила 1 млн, а это, минуточку, в 3 тысячи раз больше чем надо. Причем запросы к истории для Меркурия как я видел, были намного тяжелее запросов к актуальным данным. Потому что по мере того, как даты запросов подходили к текущей, время ответа уменьшалось. И это только продукция.

Когда я столкнулся с аналогичной проблемой следующий раз (опять несколько сотен элементов в справочнике продукции, но классификатор был годичной давности, что означало что только на актуализацию справочник номенклатуры она запросит около 9 миллионов записей, и это займет пару месяцев), я уже так делать не стал и конечно написал свою обработку, которая эти 3 справочника опросила поэлементно (т.е только то что нужно в базе), на что ушло 2 минуты.

Но даже в текущем рабочем режиме когда запрос изменений идет каждый час, по справочнику продукции приходит в среднем 1000 изменений. 24 тыс. за день, 9 млн. за год. Реально нужно за год от силы 200 шт. Вот и считайте сами куда ресурсы серверов уходят.

И это типовая 1С (т.е. то что используется массово, т.е. десятки тысяч ХС).

Я бы на месте технической службы Меркурий обратил бы внимание на такие вещи и потребовал бы переделать по уму.

Лайк!

Только и платформу 1С бы переделать тоже, чтобы фигню не запрашивала.
Мы в своей системе (не 1С) сразу оптимизировали запросы в Меркурий и сделали бизнес-процессы так, чтобы лишнего не запрашивать, а только то, что нужно. Такие запросы, как запросить изменения с прошлого века сразу убрали, а где нужно перенастроили на адекватный период - за сутки, за час и т.п.

Оверквотинг, слышали такое? Вот вы сами на форуме ровно то же делаете, что и Меркурий.
Нечего не зеркало пенять, коли рожа крива

Shmel wrote:Только и платформу 1С бы переделать тоже, чтобы фигню не запрашивала.

Лайк
Архитектура 1С была актуальна лет 15 назад, поэтому она не подходит для современных реалий. Когда на каждое рабочее место надо справочники загружать.