Имеем: OLSpro (последняя версия) + Пос-терминал VT-01 + штрих.
После обновления базы до 19-ой версии резко увеличилось время сетевого запроса на ПОСе. Как с этим можно бороться?
Уточните пожалуйста номер сборки именно кассового сервера (версия файла в свойствах файла). Увеличилось время всех сетевых запросов, или каких то конкретных? Я имею ввиду, что у нас была похожая ситуация (которую мы уже устраняли), когда было большое время сетевого запроса только при закрытии чека, но в то же время запрос по коду/шк работал нормально.
Увеличилось время сетевого запроса КАЖДОГО товара!!! Кассиры жалуются что при большом стечении народа они быстро проводят товар через сканер, а в ПОС он не попадает. Сам смотрел - это происходит когда сетевой запрос от предыдущей покупки еще висит в ПОСе, а они уже проводят следующий товар. ПОС (или сервер?) не успевает отрабатывать.
И такой еще вопрос: раньше а АРМ менеджера можно было свернув приходную накладную работать со справочником товаров, а теперь (версия АРМ менеджера 2.7.101.466) это стало не возможно. Просто бывает такая ситуация когда я забиваю большую приходную накладную, в это время приходит поставщик и мне надо посмотреть что и как по его товарам.
Протестировали прохождение запросов на присланной вами БД. Ситуация у нас не повторяется. Использовали кассовый сервер 2.7.97, версию АРМ кассира терминала 2.36. Запросы и по коду и по ШК (с их набором через клавиатуру и через сканер) обрабатываются менее 1 сек.
Уточните:
1. Какая версия АРМ'a установлена на вашем терминале?
2. О каких временных интервалах задержек идет речь в вашем случае - 1 сек или более. Эти задержки не изменяются от сканирования к сканированию?
3. Задержки наблюдаются при считывании только штрих-кода, или по коду тоже?
4. Задержки наблюдаются при работе только со сканером или независимого от этого?
5. Пришлите нам файлы CashServer.log и CashServerPOSVT01_x.log, которые создаются при включенной трассировке в каталоге <TraceLog> рабочего каталога касс. сервера.
Также надо уточнить влияет ли на ситуацию подключенный к терминалу фискальный регистратор. Для этого надо отключить от терминала ФР. Запустить АРМ на терминале, при этом программа войдет в тренировочный режим (о чем сообщит). В этом режиме надо проверить время прохождения запросов.
Также в вашей БД зарегистрировано 4 терминала. Задержка при запросах наблюдается на всех терминалах? Наблюдается ли задержка, если все терминалы включены и с ними есть связь? При выключении одного из терминалов (особенно на втором ПК, где оба терминала подключены на один COM-1) на другом могут наблюдаться подобные задержки, т.к. сервер продолжает тратить время на выключенный терминал.
1. Версия АРМа - armk2_35.vte
2. Временные задержки более 1 сек. Задержки от сканирования к сканированию изменяются только в большую сторону - из 100 сканирований 100 задержек и все более 1 сек.
3. По коду товара мы не работаем - только штрих-код.
4. Задержки есть не зависимо от того работаем со сканером или вводим штрих-код вручную. И в том, и в том случае задержки более 1 сек.
5. Файл CashServer.log я выслал на почту anton@vtsoft.ru, а файл CashServerPOSVT01_x.log не ведется.
Фискальный регистратор не влияет на работу терминала - что с ним, что без него задержки более 1 сек по КАЖДОЙ позиции.
В нашей БД зарезервировано 4 терминала, но фактически работают только 2. Задержки одинаковые на обоих терминалах, не зависимо от того вместе они работают или один из них выключен. Оба терминала на одном СОМ-порту т.к. это RS-485. RS-232 был исключен по причине "слабой" земли.
"Торможение" так же наблюдается в АРМ-менеджера после того, как мы поискали товар в справочнике по штрих-коду (Сервис-поиск). Любая последующая операция (открытия справочника товаров, закрытие его, открытие накладной и т.д. - ЛЮБАЯ)в АРМ-менеджера выполняется в 5 раз!!! дольше обычного. Если какое-то время вообще не трогать АРМ-менеджера (5-7 мин.), то все опять работает в привычном режиме.
Я вам уже сообщал письмом от 17.02.2009 о результатах анализа присланного лог-файла.
Еще раз повторюсь, что показания Вашего лог-файла и тестирование нами системы с теми же компонентами (Ваша БД, такая же версия кассового сервера, такая же версия ПО терминала, и по RS-232 и по RS-485) не дают у нас описываемых Вами задержек. Все временные характеристики работы в норме.
Также, дополнительные данные для анализа может дать CashServerPOSVT01_x.log. Непонятно почему Вы его не можете найти? Убедитесь еще раз, что в настройке кассового сервера включен режим трассировки. Он должен быть, либо в рабочем каталоге кассового сервера, либо там же, в подкаталоге <TraceLog> (не на POS’е).
Еще можно рассмотреть вариант, что данная ситуация зависит от ПК, на котором установлен SQL-сервер, БД и кассовый сервер? Вы не пробовали установить зависимость от ПК?
Также, еще раз подчеркну, что между версиями БД 18 и 19 (и соотв. им версий кассового сервера) никаких принципиальных изменений, которые могли бы дать такие задержки - не было. Была устранена чем то похожая ситуация в версии 2.7.96 кассового сервера (но это было связано с закрытием чека, а не с запросом).
Так и остается открытым вот этот вопрос: раньше а АРМ менеджера можно было свернув приходную накладную работать со справочником товаров, а теперь (версия АРМ менеджера 2.7.101.466) это стало не возможно. Просто бывает такая ситуация когда я забиваю большую приходную накладную, в это время приходит поставщик и мне надо посмотреть что и как по его товарам.
В версии 2.7.101 эта возможность была отключена, т.к. могла приводить к ошибкам в работе программы. Подобная функциональность реализована правильно в VT: Магазин. АРМ менеджера. Развитие АРМ менеджера из состава OLS Prof, как и самого OLS Prof в целом, остановлено.
Здравствуйте.
На сервере увеличили объем памяти до 1 Gb. Торможение при работе с АРМ Менеджера исчезло, а вот время запроса-отклика на ПОС терминале осталось тоже. Я не хочу сказать что оно более 1 сек. (где-то 1 сек и есть), но при работе с большим объемом товара это не удобно (раньше, до обновления запрос-ответ был моментальным). Возникают моменты что например из 3-х товаров второй в чек не попадает - не успевает отрабатываться запрос...