По теме из базы знаний
- Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2. Переносятся документы, справочная информация и остатки
- Перепроведение документов по выбранному регистру для УТ 11.4 (КА2, УП частично). Теперь и 11.5.8
- Регистрация статусов документов для УТ 11.5, УТ 11.4, КА 2.4 и ERP 2.4 (расширение конфигурации)
- Анализ валовой прибыли, выручки и закупочной стоимости - без закрытия месяца и без расчета себестоимости - УТ 11.5, КА 2.5, ЕРП 2.5 - валовая прибыль и себестоимость по виду цен
- Неликвидные товары в ценах номенклатуры – УТ 11, КА 2, ЕРП 2
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(4) Да, спасибо. Уже знакомлюсь. Но разработчики УТ (как и, наверное, других типовых конфигураций) даже не задумывались, как конфа будет работать под большой нагрузкой. И то, какой шквал запросов серверу БД приходится переварить буквально на каждом чихе, просто поражает.
Так захламить обычный ритейл... Слов нет.
Так захламить обычный ритейл... Слов нет.
На сервере разворачиваем УТ 11.
Потом пишем обработки по заполнению НСИ.
Потом пишем обработки по заполнению основных документов за последний год 2, на основании реальных данных.
Потом смотрим - работает ли это в однопользовательском режиме.
Если ОК, то берем нагрузочное тестирование из ЦУП, или пишем на коленке имитацию работы пользователей (Скажем 50 фоновых и 2-3 документа реализации в секунду, компоненту задержки можно взять в аренду из ЦУП, или ping) и пробуем при такой нагрузке работать.
Если есть какие либо проблемы на любом этапе - включаем счетчики и ТЖ и думаем, проблема в коде или оборудовании.
Точнее такой симуляции - ничего не выйдет, все остальное - чистый субъектив.
Одно могу сказать - 500К реализаций в год в среднем по 3 строки в ней - это не так много, на Хайлоад не тянет.
Я в соседнем окне смотрю на базу в которой 300К реализаций в месяц. С оперативным контролем остатков. УПП.
И там есть проблема с эскалациями на SQL(слишком много строк в ТЧ), все остальное вполне себе тянет.
Потом пишем обработки по заполнению НСИ.
Потом пишем обработки по заполнению основных документов за последний год 2, на основании реальных данных.
Потом смотрим - работает ли это в однопользовательском режиме.
Если ОК, то берем нагрузочное тестирование из ЦУП, или пишем на коленке имитацию работы пользователей (Скажем 50 фоновых и 2-3 документа реализации в секунду, компоненту задержки можно взять в аренду из ЦУП, или ping) и пробуем при такой нагрузке работать.
Если есть какие либо проблемы на любом этапе - включаем счетчики и ТЖ и думаем, проблема в коде или оборудовании.
Точнее такой симуляции - ничего не выйдет, все остальное - чистый субъектив.
Одно могу сказать - 500К реализаций в год в среднем по 3 строки в ней - это не так много, на Хайлоад не тянет.
Я в соседнем окне смотрю на базу в которой 300К реализаций в месяц. С оперативным контролем остатков. УПП.
И там есть проблема с эскалациями на SQL(слишком много строк в ТЧ), все остальное вполне себе тянет.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот