Пробую настроить веб-сервис для получения данных из другой базы.
При работе веб-сервиса достаточно большое время уходит на инициализацию.
Например, обращаемся из Базы2 в веб-сервису Базы1
По замеру времени отработка вебсервиса на стороне Базы1 = 0,5сек.
Общая длительность обращения по замеру в Базе2 = 1,7 сек.
В каких-то случаях вообще обращение 5 секунд. Не могу отловить закономерность.
Т.е. от 3/4 времени работы вебсервиса тратится на инициализацию подключения.
При этом каждое обращение это новая авторизация, новая потеря времени.
Пробовала SOAP web-сервис и http-сервис. Http-сервис быстрее, но тоже долго.
Поделитесь опытом, как у вас по скорости работают веб-сервисы.
Может, есть какие-то настройки, чтобы сеанс не иницилизировался каждый раз заново.
(1) ekaruk, Http-сервис быстрее, да. Инициализация? Гм. Запоминайте соединение и пользуйтесь им. Вы ведь вначале его создаете, а потом посылаете запрос. Вот созданное соединение и запоминайте в переменной на то время, пока он вам нужен. Если нужен постоянно, то беда.
(2) omut, если у нее обен на пхп, там сложнее.. там скрипт выполнился - все объекты освободились.. придется что то придумывать, а так да, поддерживаю..
(1) ekaruk, добавлю от себя что в случае пхп, в SoapClient есть кэши.. вполне возможно он у вас выключен, тогда у вас каждый раз получается схема данных, что разумеется время.. а вообще расскажите подробнее что с чем обменивается и на каких языках написано, тогда и ответ будет подробнее
(4) AllexSoft, я так понял, что раздел указывает на взаимодействие двух баз. Если пхп, то однозначно нужно выбирать http-запросы. Их появление очень порадовало именно в плане взаимодействия со сторонними веб-ресурсами (1С в роли сервера само собой).
По собственному опыту могу сказать, что замедление быстродействия сервисов не велико. 5 секунд говорит скорее всего о низкой производительности сервера, на котором выполняется 1С. Нужно рыть в сторону веб-сервера (проубуйте открыть корневую страницу, что будет?) и быстродействия самой 1С на сервере. Тут проверить по логам 1С. В процедуре сервиса добавьте строку записи любого сообщения в журнал регистрации, сделайте запрос, посмотрите по логам веб-сервера и 1С когда что произошло: запрос к веб-серверу, начало сеанса в 1С, строка, сформированная в коде сервиса, завершение сеанса. Так увидите, на каком этапе у вас происходит длительная операция.
(2) omut, Использовать одно и то же логично.
Но насколько я понимаю, соединение будет жить только в пределах вызова сервера. На клиент и потом обратно его не передашь.
(3) Serginio, Насколько я понимаю, установка параметров сеанса для веб-сервисов выполняется в модуле сеанса, который общий для всех. Определить в нем, что вызван сеанс для конкретного веб-сервиса не получится.
(4) AllexSoft, получение данных между двумя 1С.
(5) omut, Да, нужно смотреть, на чем замедление.
(7) spezc, Интерактивные действия пользователя при работе с формой. Обращение одно, но лишних пару секунд критично. С учетом того что получение и обработка данных 0,5секунд. Между ХТТП-сервисами и SOAP-вебсервисами разница в скорости подключения почти в 2 раза. Достаточно прилично, на мой взгляд. Интересно, чего не делает ХТТП из того, что делает SOAP.
(9) ekaruk, Модуль управляемого приложения.. он живет постоянно, делаем там переменную (экспортную), инициализируем веб-сервис (подключаемся), контекст соединения передаем в переменную.. и теперь можем использовать эту переменную чтобы обращаться к веб сервису без подключений (он будет подключен 1 раз при старте)
ПС: если у вас живут базы на одном сервере, и они клиент-серверные то я бы на вашем месте посмотрел бы внешние источники..
(14) Xatori111, сделать фоновое задание которое будет выполнять запрос раз в 5 минут =) какой нибудь самый примитивный.. ну и проверять есть или нет соединение или нет, если нет то подключать заново
(15) AllexSoft, как вариант, у меня крутятся несколько обработок с таким методом получением данных, да отчёт есть собирающий данные с разных баз, но мне не критично 3-5 секунд на инициализацию соединения. А так да, но про 5 минут я могу ошибаться, это я примерно сказал, знаю что не долго.
(13) AllexSoft, Базы на одном сервере и клиент-серверные.
Думали про подключение к данным второй базы как к внешним источникам.
Там запросы к РН с большим объемом данных. Насколько я понимаю, при подключении внешних источников я не смогу нормально использовать таблицы итогов и виртуальные таблицы. Дублировать стандартные механизмы работы с данными я полноценно не смогу. При обращении изнутри базы с учетом использования итогов и индексов работает почти мгновенно. При обращении снаружи скорее всего будет дольше, чем через веб-сервис.
Ну и плюс дополнительная морока с таблицами, ссылками, типизацией данных. Объем работ и сложность поддержке на порядок выше. Лучше, когда 1С-запросы исполняются в родной среде.
Насколько я понимаю, при подключении внешних источников я не смогу нормально использовать таблицы итогов и виртуальные таблицы
ну смотря что считать "полноценным", виртуальные таблицы это просто таблицы в базе данных, к ним тоже можно подключиться.. но там надо учитывать механизм рассчета остатков на произвольную дату, так что как вы правильно заметили
Объем работ и сложность поддержке на порядок выше
А вот
при обращении снаружи скорее всего будет дольше, чем через веб-сервис.
тут не согласен.. прямым запросом к СУБД будет быстрее (по сравнению с обычным запросом языком запросов в 1С, он же еще промежуточный этап проходит через 1С:Сервер, а напрямую всегда быстрее будет).. хоть и ненамного, дополнительная работа с типизацией и тд и тп.. хотя в 8.3.5 по этому плану много что сделали чтобы облегчить наши муки ) По быстродействию вы учитывайте что на стороне веб сервиса небходимо не только получить результат но и: загрузить его в хранилище значения -> сериализовать хранилище -> передать сериализованный ответ (он в виде текста в формате XML) -> получить ответ на клиенте -> десериализовать -> распаковать из хранилища.. )
Кстати, а зачем вам хранилище значения то, раз у вас обмен между базами 1С? можно использовать обычные типы для передачи.. ну скажем передать сразу таблицу значения или что вам там надо, никакого хранилища значений не надо
Ну если все же хотите веб-сервисы то в я (13) все расписал что куда и как получить чтоб 1 раз подключаться, только вот что то мне думается что там на сериализацию ответа тратится достаточно большое время (1С любит использовать для сериализации темпы)
ну смотря что считать "полноценным", виртуальные таблицы это просто таблицы в базе данных, к ним тоже можно подключиться.. но там надо учитывать механизм рассчета остатков на произвольную дату, так что как вы правильно заметили
Объем работ и сложность поддержке на порядок выше
Можно использовать реальные таблицы + таблицы итогов. Виртуальные таблицы, насколько понимаю, это подзапросы, сильно зависящие от набора полей, периода запроса, периода расчета итогов. + связи по ссылкам (тип + УИД), + смещение дат. На самом деле я достататочно высоко оцениваю тот механизм по работе с данными, который разработатли в 1С. Не думаю, что я в состоянии его корректно продублировать даже частично с приемлемыми трудозатратами.
По быстродействию вы учитывайте что на стороне веб сервиса небходимо не только получить результат но и: загрузить его в хранилище значения -> сериализовать хранилище -> передать сериализованный ответ (он в виде текста в формате XML) -> получить ответ на клиенте -> десериализовать -> распаковать из хранилища.. )
Как ни странно, вся сериализация/десериализация работает достаточно шустро. Ее скростью можно пренебречь по сравнению со скоростью веб-сервиса.
Кстати, а зачем вам хранилище значения то, раз у вас обмен между базами 1С? можно использовать обычные типы для передачи.. ну скажем передать сразу таблицу значения или что вам там надо, никакого хранилища значений не надо
Типы данных отличаются. Банальные ссылки на справочники в любом случае нужно сериализовать при передаче. Хотя об этом тоже можно подумать. Через ХТТП вроде таблицы не передаются. Только строки или файлы. Только через SOAP.
Не думаю, что я в состоянии его корректно продублировать даже частично с приемлемыми трудозатратами.
ну и там надо бы глубокое знание структуры таблиц остатков и реальной таблицы движений регистра.. в принципе в целом я с вами согласен, если нет человека кто возьмется за внешние источники, то лучше через веб-сервисы делать
Как ни странно, вся сериализация/десериализация работает достаточно шустро. Ее скростью можно пренебречь по сравнению со скоростью веб-сервиса.
тогда скорее действительно проблема в частой инициализации сеанса.. тогда вариант в (13) для вас
Через ХТТП вроде таблицы не передаются. Только строки или файлы. Только через SOAP.
(19) ekaruk, JSON (http как альтернатива SOAP) сериализует вам все, что угодно. SOAP и XDTO удобны для обмена между совершенно разными системами. Но, как показывает практика, это совсем не обязательно. Как вы правильно заметили, прописывать в пакетах всю сериализацию очень накладно. Кстати, если после установления подключения посмотрите файл описания, то можете быть неприятно удивлены его объемом. Все пространства имен, которые вы подлючили будут передаваться полностью на клиента. Т.е. даже один примитивный тип 1С потянет за собой полное описание. А там.... можете через браузер подключиться и проверить.
(23) Не обязательно. Например в C# сгенерятся один раз классы. В 1С тоже статически создадутся WS-ссылки.
Даже при динамической загрузке можно использовать файл сохраненный на компьютере
(24) Serginio, про файл не знал. Спасибо за идею. И правда Есть смысл так поступать. Я, правда, пошел немного по другому пути. Вообще отказывался от пакетов и все делал кодом на стороне сервера и так же клиента. Удобно, конечно, свернуть и развернуть все автоматом. Но редко это надо. Во всяком случае в моих задачах такой необходимости не было.
(23) omut, Именно JSON и использую. Таблицы значений и структуры, сериализованные в текст через эту библиотеку http://infostart.ru/public/308198/. Т.е. никаких дополнительных описаний типов. Через сервисы уходит и приходит чистая строка. Упаковывается в типах одной базы, десериализуется уже в типах второй базы. Сама сериализация по скорости работает нормально.
(27) ekaruk, тогда переходите на http, зачем вам навороты SOAP, если их возможности все равно не используете :) Ну и, возвращаясь к вашему вопросу, удалось ли выявить узкое место в скорости ответа? Может элементарно веб-сервер тормозит? Кстати, а какой используете?
(9) ekaruk, соединение будет жить на клиенте. ПОсмотрите код вызова: сначала инициализация соединения С СЕРВЕРОМ, потом вызов сервиса. ВЫзов сохранять смыла нет. А соединение можно и запомнить на весь период работы. Т.е. если у вас вызываются разные процедуры сервиса, то вы после инициализации соединения его сохраняете, а вызовы делаете все уже через него.
(1) ekaruk,
1. Скорость инициализации уменьшиться если wsdl читать не с сервиса, а из файла. После подключения параметры подключения сохраняем в переменную
2. ws-cоединение закрывается сразу после передачи ответа, поэтому никак, каждый раз тратиться от 0,2-0,4 сек на простой запрос (в зависимости от производительности сервера).
Поэтому если мы начинаем передавать например установленные типы цен, и сначала хотим получить от сторонней базы какие цены она может принять, то у нас будет 2 (две) отправки запроса и на каждый запрос у нас будет создано новое ws-соединение и на каждое соединение уйдет 0,2-0,4 сек, т.е. 0,4-0,8 сек.
Печально но по другому никак не выйдет
Использование ХранилищеЗначений хороший вариант, сам использую такой же подход, сжимаю по максимуму в коэффициенте (9). Например у меня передача номенклатуры 10 тыс позиций занимает время чуть больше чем отправка простого запроса.
Единственное жалко что пакеты XDTO не читаются из хранилища значений в удаленной базе
(29) Zixxx, Вообще-то, насколько я понимаю, именно для этого и существуют WS-ссылки.
Т.е. система и так не перечитывает каждый раз при обращении wdsl-описание сервиса, а обращается к данным сохраненной в конфигурации WS-ссылки.
(28) omut, ТОже думаю, что SOAP не нужен. ХТТП достаточно в этом случае. Это не промышленная эксплуатация, только проверяем варианты. По скорости еще не разобралась, где основная задержка между базами. Сервер Апач.
(30) ekaruk, Еще не совсем понял про объем данных, в (0) написали 3/4 на установление соединения, сейчас пишите что не разобрались где затраты по времени, но если запросы небольшие то всегда время будет уходить на инициализацию библиотеки и запуск сеанса, причем куда большее чем на установление самой связи, на это платформа 1с требует определенных ресурсов от сервера.
И величина это будет всегда плавающая особенно если используется сервер где есть пиковые загрузки проца.
(33) Zixxx, Мне не нравится, что суммарное время обращения к веб-сервису в несколько раз больше времени получения и обработки данных внутри веб-сервиса. И еще больше мне не нравится нестабильность времени выполнения обращения к веб-сервису. Для аналогичного обращения время может отличаться в разы.
Я понимаю, что в любом случае какое-то время тратится на установку соединения и мне бы хотелось его минимизировать.
Возможно, я где-то не совсем корректно выражаюсь, так как еще не полностью поняла механизм работы веб-сервисов. Но пытаюсь понять лучше.
(35) Zixxx, Один запрос - на него один ответ.
(36) Serginio, Интересно, как по времени работате стандартный REST интерфейс. Теоретически должен быть быстрее, хотя может и аналогично HTTP-сервисам. Пока не разбиралась с ним.
Даже если сам объект соединения использовать повторно, все равно во второй базе заново инициализация сеанса выполняется.
(59) ekaruk, я как раз вчера экспериментировал с REST. Полный перечень физических лиц из ЗУПа вывелся с вполне приемлимой скоростью. Просмотр данных элемента справочника происходит практически моментально - визуальных задержек не обнаружено
http://www.forum.mista.ru/topic.php?id=679547#4 Для многих случаев можно для вэб сервисов просто упростить УстановкаПараметровСеанса
Для HTTP сервиса тоже вроде УстановкаПараметровСеанса срабатывает.
http://v8.1c.ru/o7/201312http/index.htm Публикация HTTP-сервисов выполняется аналогично тому, как публикуются web-сервисы. Также аналогичным образом для них работает аутентификация, использование разделения данных и отладка.
в качестве эксперимента при разработке мобильного приложения перевел обмен на хттп-сервисы. в плане подключения разница в скорости чувствовалась даже на глаз. подключение присходило за доли секунды.
и встречный вопрос. раз время подключения в 1 секунду для вас критично - то скорее всего подключение у вас осуществляется много раз и время самого подключения (время работы на стороне 1С) не велико. Так как пропорция 1сек на подключение при 3 минтах на выполнение особой роли не играла.
возможно вам стоит немного изменить условие задачи, чтобы 1сек на подключение и 1сек на работу поменяла свою пропорцию?
возможно стоит сделать что то типа кэша запросов.. да хз, условие задачи нужны, что с чем обменивается и зачем, гадать решение без четкой задачи это вилами по воде. Ждем автора )
у меня обмен так реализован.
Выполняется подключение.
Потом переменная с подключением первым параметром передается в каждую процедуру обмена.
В среднем на подключение по 3G 3-5 секунд. Обмен уже по ходу дела от 1 до 15 минут. Проблем особых не было.
я про мобильное приложение. С тонкого клиента все быстрее на порядок.
Кстати скорость зависит от пакета XDTO который используется в Web-сервисе, от количества Операций, типов возвращаемых параметров
На практике следующее:
В web-сервисе пакетом-XDTO по умолчанию установил какой-то с типогово. Подключение выполнялось больше 1 минуты. Удалил - пару секунд.
Получается что при подключении анализируется весь вебсервис (можно в xml-ке подключения посмотреть). А при плохом интернете даже 2 мб играет большую роль.
(11) dj_serega, В вебсервисе передается в обе стороны ХранилищеЗначений, в ХТТП - сервисе строка.
Т.е. простейшие типы стандартного пространства имен.
Данные каждый раз разных типов, просто сериализуются в текст при передаче.
просто. используйте хттп. определите среднее время на подключение и получение ответа (не считая время обработки на стороне самого сервиса) и возьми ее за константу и всю дальнейшую работу ведите с учетом этой константы. ну еще можете поиграться с хостингом, каналом сервера, которые возможно влияют на скорость отклика.
(0) Если на однос серевере, то вообще можно воспользоваться передачей через TCP/IP
Например http://infostart.ru/public/238584/ В свое время еще на семерке делал обмен между 1С и ТСД
(40) Serginio, Сегодня могут быть на одном сервере, завтра отпочковаться в другое место. Если в сервисах присутствует частая передача данных небольшими сообщениями и для одной итерации необходимо пару - тройку раз дернуть методы, тогда вырисовывается не очень приятная картина. Постоянно создаются новые соединения и время на соединения уходит 75% а на передачу данных и ее разбор 25%. И не важно в одной сети или в разных.
(41) Ну можно через VPN соединяться. Это не проблема.
По поводу соединения как указал в (22) Нужно держать соединение между вызовами. Это обычная практика не только в 1С но например и вэб браузерах
(45) Serginio, В (22) пишут по соединение, а нужно hs и ws соединение, каким образом hs и ws соединение должно остаться в удаленной базе после того как она сделала возврат из функции. Есть примеры, что именно нужно сделать?
У нас в точности такая же история, есть некое подобие УРБД только все на сервисах. И есть обычный пример по передачи данных 5 тыс номенклатурных позиций. Время передачи 0,75 сек, и два-три раза поднимается соединение по 0,3 секунды = 0,9 сек. В итоге получаем что передать 5 тыс позиций проходит быстрее чем инициализация соединений, имеется ввиду именно время на создание ws-соединения, само подключение не в счет. Локально или удаленно базы json или xml разница небольшая по сравнению с поднятием ws-соединения.
В одно соединение никак не сделать, выше уже писал пример. Собственно в (0) таже беда постоянная трата времени на поднятие ws-соединения.
А вот если бы соединение не закрывалось бы после передачи данных, то пользователи бы ничего и не заметили, внутри базы получение и вывод номенклатуры такой же почти по времени.
(44) Zixxx, да, проверил.. похоже это реализация SOAP-по 1с-ному..
Определение = Новый WSОпределения(Server, User, Pass); - это раз подключение к базе.. (для получения схемы сервиса)
Прокси = Новый WSПрокси(Определение, "http://****.ru", "SiteExchange", "SiteExchangeSoap");
прокси.выполнитьчтото(); - это второе подключение, для выполнения..
самое печальное что действительно WSПрокси отключается сразу после отработки метода сервиса (( все таки постоянное подключение создать не удастся с веб-сервисами от 1С, можно попробовать использовать какой нибудь внешний драйвер от MS например для чтения данных...
хотя может не париться и сделать через старый добрый COM ? постоянный коннект там можно 100%
Так и говорят что подключение есть, никто не говорит что подключения нет. После прокси.выполнитьчтото(); пропадает ранее установленное ws-соединение в базе в которую мы отправляли запрос. И при каждом следующей отправки создается новое ws-соединение, а потом сразу отваливается. Само Прокси так и остается. Возможно в (47) не правильно выразились.
Прокси = Новый WSПрокси(Определение, "http://****.ru", "SiteExchange", "SiteExchangeSoap");
А вот это подключение уже к вэб сервису
в том то и дело что нет ( можешь проверить..
подключение, выполнение метода и отключение происходит одновременно только на строке
прокси.выполнитьчтото();
можешь проверить..
сама строка объявления WSПрокси ничего не занимает по времени (да и проверил по журналам регистрации никакого подключения к веб-сервису не вызывает)...
(53) Да уже разобрался в (52). Проверить пока не могу, но верю. Выход тогда только один для вэб соединения использовать определенных пользователей и для них прописывать быструю инициализацию в УстановкаПараметровСеанса
используя (21)
(54) Serginio, Непонятно как именно использовать специальных пользователей, если пользователь ws-соединение, и вообще если можно определить что это веб клиент какой-то, то все что в УстановкаПараметровСеанса можно тупо опустить
(57) Нужно посмотреть, что делают вэб сервисы. Какие вызываемые методы из общих модулейю По уму нужно опускать либо инициализировать по мере появления ошибок.
Там еще внутри вэб сервисов можно указывать для роли права доступа к методам.
(53) Насчет WSПроксти там идет просто разбор WSDL получение биндинга адреса протокола
Причем
Прокси.Пользователь = "XXXX";
Прокси.Пароль = "YY";
Идет после подключения. Просто в пуле можно было бы сохранять и пользователя.
Интересно, как там в HTTP-сервисе, по идее то же самое, что и с Web сервисами
В своё время делал обмены между базами с помощью веб-сервера. Скажу вам так - если для веб-сервера выделить отдельный сервак и его разместить "близко" к стореджу и серверу 1С, то потеря времени будет незначительной. У меня документы при проведении вызывали данные другой базы через веб-сервер. Все работало быстро. Но как только сервера развели на разные дата центры - скорость упала резко. про времени вместо 10 секунд запрос выполнялся 70 секунд. Так что смотрите в эту сторону. У меня был веб-сервер апач. Работал и с IIS, его настройка не столь ручная как в апача, настроил его под свои нужды где-то за часа 4, предварительно с ним не работав. Оно работал на вместе на одном сервере вместе с сервером 1С, так скорость выполнения была фантастическая, 2,3 секунды - и есть результат.
Видимо я "старовер". По HTTP обмен данными с web-сервером писан ручками. Отклик в пределах 17мс + пинг*2, т.е. почти мгновенно. Данные сериализуются JSON. Ах да, используется поставляемый с Windows httprequest. Аналогичные функции 1С показывают себя медлительными по сей день.
Неудобство вызывает то, что для файловой Apache не закрывает файлы базы (1Cv8.1CD, 1Cv8tmp.1CD и др.), даже при отсутствующих процессах 1cv8.exe. Нельзя обновить конфигурацию, пока не будет перезагружена служба Apache. Если кто-то знает решение, прошу написать.
(66) worker1c, не всегда так, у меня например все прекрасно обновляет и при включенном апаче.. другое дело что нужно всех пользователей выгнать, убедиться что нет зависших сеансов, а потом уже обновлять.. с зависшими сеансами не обновит разумеется (
открыть любую ветку с объектными данными (например, справочники), добавить туда новый справочник (или реквизит любого справочника), потом его сразу удалить. При обновлении предложит завершить сеансы. Соглашайтесь, обновляйтесь.
Есть опубликованные веб-сервисы на обычном Apache. Апач и сервер 1С стоят на одной машине. Используя, например, SoapUI, видно, что первый ответ от какой-либо ф-и нужно ждать долго - 2-3 секунды, затем, если запустить тот же запрос , изменив в нем даже несколько параметров, повторно - результат возвращается мгновенно.
(69) Maxisussr, Из написанного как будто следует, что SoapUI будет лучше работать если связать Apache и 1C. Либо видно не через SoapUI а через Fiddler?
(70) raskol, Смысла сохранять нет, так как соединение поднимается за 0,2 секунды, автор и спрашивает почему соединение поднимается 2-3 секунды. Да потому что сервер убит, либо пиковые нагрузки часто
(75) AlexanderKai, Насколько я понимаю, на оба технически лицензия не тратится.
Возможно, в момент вызова, но это можно не учитывать.
Но юридически, с точки зрения лицензионной политики, количество лицензий должно совпадать с количеством пользователей, реально одновременно работающих с системой. В том числе с веб-сервисами.
Добрый всем.
Внимательно перечитал обсуждение. Решения не увидел (((
У меня такая ситуация: IP-телефония от CISCO. Шлет REST запросы. JSON.
Я ей в ответ тоже REST.
Система асинхронная.
Интервал между тем как я отправил запрос, до того как получила киска - 0,2 сек
Между тем как отправила киска, получила 1С 2-2,5 сек. Это ОЧЕНЬ долго.
УстановкаПараметровСеанса() действительно выполняется перед каждым получением REST, но задержка до того, как выполняется УстановкаПараметровСеанса(). Сама Установка... 0,02 секунды.
1С 8.3.10, УНФ 1.6, Апач 2.2
Где рыть?
1. Настройки апача
2. Параметры 1С
3. Настройки публикации