Обмен страниц в секунду 1с

Обновлено: 08.07.2024

Для замера показателей мониторинга производительности в OS Windows мы используем performance monitor (perfmon). Добавляем необходимые счетчики мониторинга и включаем замер, через требуемый интервал времени можем проанализировать результат.

При этом для текущего просмотра загруженности оборудования, можно использовать и текущий монитор загруженности из диспетчера задач.
Мониторинг загруженности оборудования. Resource monitor Мониторинг загруженности оборудования. Resource monitor

Когда используем performance monitor

  • Для анализа текущей загруженности
  • Расследования пиков по жалобам пользователей
  • При нагрузочном тестировании.

Основные счетчики performance monitor для 1С

Мониторинг загруженности оборудования. Performance monitor Мониторинг загруженности оборудования. Performance monitor
  1. Процессор\Processor(_Total)\% Processor Time (от 0 до 100).
    \System\Processor Queue Length (не более 2).
  2. Память\Memory\Available MBytes (от 0 до общего объема).
    \Memory\Pages/sec (если более 5, то анализируем).
    \Memory\Page Faults/sec (как часто страницы RAM в нерабочем состоянии).
  3. Диск\PhysicalDisk(_Total)\Disk Read Bytes/sec (Скорость чтения)
    \PhysicalDisk(_Total)\Disk Write Bytes/sec (Скорость записи)
    \PhysicalDisk(_Total)\Avg. Disk Queue Length (не более 2 * количество дисков, работающих параллельно = RAID0).
  4. Сеть:\Network Interface(*)\Bytes Total/sec (скорость передачи)
    \Network Interface(*)\Output Queue Length (очередь пакетов, не более 2).
Для более детального мониторинга на серверах 1С или СУБД можно разбивать счетчики по процессам rphost, ragent, sqlserver и т.д. Например, счетчики будут называться так: «Process(rphost*)% Processor Time», «Process(sqlservr)% Processor Time».
Мониторинг загруженности оборудования. Анализ результатов Мониторинг загруженности оборудования. Анализ результатов

Как создать набор замеров perfomance monitor

Наборы замеров можно создавать

  1. Вручную
  2. Загружать из шаблона
  3. Создать через bat-файл.

Пример bat-файла

logman create counter Counter1C -f bincirc -c " counter1" " counter2" -si 5 -v mmddhhmm

  • create counter Counter1C – создать счетчик с именем "Counter1C"
  • -f bincirc – результат в виде бинарного файла (*.blg)
  • -c "counter1" "counter2" – какие счетчики собираем
  • -si 5 – периодичность 5с.
  • -v mmddhhmm – формат выходного файла (например, Counter1Cblg)
  • На разных версиях и локализациях Windows названия счетчиков могут различаться
  • Можно использовать русские наименования счетчиков.
  • Символ "%" необходимо экранировать таким же символом "%%".
  • Некоторые свойства приходится прописывать вручную:Корневая папка
    Формат имени вложенной папки: yyyyMMdd (или yyyyMM)
    Условия остановки/перезапуска

Показатель pages/sec

Отдельно стоит упомянуть такой показатель для оперативной памяти как pages/sec. Сложность интерпретации его показателя заключается в том, что он не имеет какого-то особого значения без связки с другими показателями.

Pages/sec показывает, сколько OS сбрасывает на жесткий диск.страниц RAM в среднем за 1 секунду. Дело в том, что OS постоянно сбрасывает страницы из RAM, и это нормальное явление, поэтому для более детального анализа, необходимо подключать показания других счетчиков.

В первой части статьи мы опишем основные шаги по подключению счетчиков и настройке загрузки данных в базу мониторинга производительности. Если же Вам лень читать и Вы любите смотреть и слушать, то можно перейти к видео-уроку и посмотреть небольшой 5 минутный ролик по выполнению необходимой последовательности действий и повторить при необходимости. Все процедуры просты и максимально прозрачны. Поехали!

1. Подключим счетчики производительности сервера под ОС windows.

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

а) Открываем командную строку и вводим "perfmon.msc".

б) Выбираем добавить и переходим на вкладку.

в) Добавляем счетчики согласно таблицы ниже.

г) В настройках указываем формат файла ".csv"

д) Можем запустить и получим уже входные данные. Но работать сбор данных будет до выхода из системы, о настройке регламентного задания см. п3.

Внимание! Пользователь под которым будут запускаться счетчики должен обладать необходимыми правами и входить в группу "Perfomance monitor group".

Таблицу с основными на наш взгляд счетчиками приведем таблицу в этой статье. Если нужно больше информации, то к вашим услугам всемирная сеть и возможно кто-то из комментаторов к статье приведет какие-либо предложения и факты.

2. Подключим счетчики производительности SQL сервера под ОС windows.

Если у вас SQL и службы 1С стоят на одном сервере, то вы можете совместить настройки логов в один проект или в общую папку.

Операции те же самые, что и в п.1. + добавляем таблицу для счетчиков SQL сервера.

Таблица счетчиков для SQL сервера (синонимы по русски иногда это нечто).

Показатель Группа Синоним Описание Значение
Table Lock Escalations/sec Access Methods Методы доступа\Укрупнений блокировок таблиц в секунду Количество раз, когда блокировки таблицы были укрупнены Стремящееся к 0
Page life expectancy Buffer Manager Диспетчер буфера\Время без ссылки для страницы расширения Количество секунд, в течение которых страница остается в буферном пуле без ссылок на нее Не менее 300 с
Buffer cache hit ratio Buffer Manager Диспетчер буфера\Коэффициент обращений к буферному кэшу Процент найденных в буферном пуле страниц, что исключило необходимость чтения с диска Стремящееся к 100%
Average Latch Wait Time (ms) Latches Latches\Среднее время ожидания кратковременной блокировки Среднее время ожидания (мс) для запросов кратковременной блокировки Стремящееся к 0 мс
Average Wait Time (ms) Locks Locks\Время ожидания блокировки (мс) Среднее время ожидания (в миллисекундах) для всех ждавших запросов блокировки Стремящееся к 0 мс
Lock Waits/sec Locks Locks\Запросов блокировок в секунду Количество запросов блокировки, которые не были выполнены немедленно и ожидали предоставления блокировки Стремящееся к 0
Lock Timeouts/sec Locks Locks\Превышений времени ожидания блокировки в секунду Количество запросов блокировки, время ожидания которых истекло, включая запросы блокировок NOWAIT. Стремящееся к 0
Number of Deadlocks/sec Locks Locks\Количество взаимоблокировок в секунду Количество запросов блокировки, приведших к взаимоблокировкам Стремящееся к 0
Cache Hit Ratio Plan Cache Plan Cache\Коэффициент попадания в кэш Соотношение между попаданиями в кэш и обращениями к кэшу Стремящееся к 100%
Longest Transaction Running Time Transactions Transactions\Время выполнения самой длинной транзакции Наиболее продолжительное время выполнения какой-либо транзакции в секундах Для OLTP систем не должно быть высоким
Transactions Transactions Transactions\Транзакции Общее количество активных транзакций.

3. Настроим планировщик заданий для автоматического запуска счетчиков.

а) Открываем командную строку и вводим "taskschd.msc"

б) Переходим по следующему пути: "Microsoft\Windows\PLA"

в) Добавляем задание. Указываем способ запуска "при старте системы", запускать при ошибках и сохраняем.

4. Добавим задание загрузки данных в базу мониторинга.

а) Открываем базу мониторинга производительности

б) Переходим в подсистему "Анализ ТЖ" и открываем журнал "Замеры"

в) Добавляем новый замер и указываем:
- путь к каталогу с логами счетчиков;
- тип "Perfomance monitor";
- загружать online и время работы регламентного задания;
- можем указать имя сервера - реквизит оборудование.

г) все готово и первые замеры скоро появятся в базе.


5. Анализируем результат операций.

Теперь просмотреть данные можно в журнале "События замера" в форме таблицы или графически АРМ "Графики Perfomance monitor".



Видео-урок.

В этом видео-уроке мы с вами проведем необходимые настройки и посмотрим результаты на примере искусственных ситуаций.

Использование System Monitor для диагностики проблем производительности

System Monitor представляет собой стандартное средство для диагностики проблем производительности операционной системы, различных компонент приложений и используемого оборудования. С его помощью можно измерять производительность как локального компьютера, так и других компьютеров в сети. System Monitor является основным инструментом для идентификации узких мест в системе.

Компоненты анализируемой системы интерпретируются как объекты, параметры которых представляются в виде набора счетчиков, при этом для каждого объекта определен свой набор счетчиков. Некоторые приложения в процессе установки расширяют системный набор своими, специфическими объектами и счетчиками, характеризующими производительность этого приложения. Например, при установке Microsoft SQL Server к стандартному набору объектов и счётчиков операционной системы добавляются специфические объекты и счётчики сервера баз данных.

Потенциальные узкие места

Память

  • Недостаток объема оперативной памяти, установленной на компьютере, оказывает негативное влияние на производительность всех компонент 1С:Предприятия 8 и Microsoft SQL Server.
  • При увеличении количества пользователей и объема информационной базы требования к этому ресурсу со стороны сервера 1С:Предприятия 8 и Microsoft SQL Server возрастают.
  • Нехватка памяти приводит к увеличению интенсивности страничного обмена между файлом подкачки и физической памятью, что существенно снижает производительность системы.

Процессоры

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

Дисковые операции

Производительность дисковой подсистемы является одним из решающих факторов, определяющих производительность Microsoft SQL Server. На производительность сервера 1С:Предприятия 8 влияния, как правило, не оказывает.

Конфликты блокировок Microsoft SQL Server

Один из основных факторов снижения производительности в многопользовательском режиме

Идентификация узких мест

В таблице приведен перечень основных объектов и счетчиков, используемых при анализе проблем с производительностью.

Объект Основные счетчики Описание Основные признаки наличия проблемы Варианты решения проблемы Память Memory \ Pages/sec Характеризует интенсивность обмена между дисковой подсистемой и оперативной памятью. Обращение к дисковой системе происходит из-за того, что запрашиваемые страницы отсутствуют в оперативной памяти. Нормальное значение этого счетчика должно быть близко к нулю. Увеличение показания этого счетчика свыше 20 страниц в секунду говорит о необходимости увеличения объема оперативной памяти.

Увеличение объема оперативной памяти, установленной на компьютере.

Перенос приложений, интенсивно использующих оперативную память, на отдельный компьютер. Например, установка сервера 1С:Предприятия 8.0 и Microsoft SQL Server на разных компьютерах.

Процессор Processor \ %Processor Time Время, которое процессор тратит на выполнение полезной работы, в процентах от общего системного времени. Если среднее значение величины утилизации процессора превышает 85%, значит, процессор – узкое место в системе.

Замена процессоров на более быстродействующие.

Увеличение количества процессоров.

Перенос приложений, интенсивно использующих процессор на отдельный компьютер . Например, установка сервера 1С:Предприятия 8.0 и Microsoft SQL Server на разных компьютерах.

System \ Processor Queue Length Длина очереди к процессору. Если в течение длительного времени средняя длина очереди превышает значение 2, то это говорит о том, что процессор является узким местом. Дисковая система Physical Disk \ %Disk Time Процент времени, которое диск был занят, обслуживая запросы чтения или записи. Снижение утилизации процессоров сервера

Установка более быстрых дисков.

Использование дисков с интерфейсом SCSI.

Использование аппаратного RAID - контроллера.

Увеличение количества дисков в RAID - массиве.

Physical Disk \ Avg. Disk Queue Length Показывает эффективность работы дисковой подсистемы. Представляет собой среднюю длину очереди запросов к диску. Увеличение очереди запросов к дисковой подсистеме Сетевой интерфейс Network Interface \ Bytes Total/sec Скорость, с которой происходит получение или посылка байт через сетевой интерфейс Значение этого счётчика не должно превышать 65% величины пропускной способности сетевого адаптера.

Установка сетевого адаптера с более высокой пропускной способностью (если позволяют параметры сети).

Установка дополнительного сетевого адаптера.

Блокировки SQL Server: Locks \ Lock Wait Time (ms) Показывает общее время ожидания (в миллисекундах) выполнения запросов на блокировку за последнюю секунду Среднее значение общего времени ожидания не должно превышать заданного времени отклика системы умноженного на количество активных пользователей

Сокращение времени выполнения транзакции.

Обеспечение единого порядка доступа ко всем ресурсам.

Оптимизация запросов в прикладном решении.

Правильная установка признаков индексирования у реквизитов объектов конфигурации позволяет существенно сократить диапазон блокировок.

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

Например, обращаемся из Базы2 в веб-сервису Базы1
По замеру времени отработка вебсервиса на стороне Базы1 = 0,5сек.
Общая длительность обращения по замеру в Базе2 = 1,7 сек.

В каких-то случаях вообще обращение 5 секунд. Не могу отловить закономерность.

Т.е. от 3/4 времени работы вебсервиса тратится на инициализацию подключения.

При этом каждое обращение это новая авторизация, новая потеря времени.

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

(2) omut, если у нее обен на пхп, там сложнее.. там скрипт выполнился - все объекты освободились.. придется что то придумывать, а так да, поддерживаю..
(1) ekaruk, добавлю от себя что в случае пхп, в SoapClient есть кэши.. вполне возможно он у вас выключен, тогда у вас каждый раз получается схема данных, что разумеется время.. а вообще расскажите подробнее что с чем обменивается и на каких языках написано, тогда и ответ будет подробнее (2) omut, Использовать одно и то же логично.
Но насколько я понимаю, соединение будет жить только в пределах вызова сервера. На клиент и потом обратно его не передашь.
(3) Serginio, Насколько я понимаю, установка параметров сеанса для веб-сервисов выполняется в модуле сеанса, который общий для всех. Определить в нем, что вызван сеанс для конкретного веб-сервиса не получится.
(4) AllexSoft, получение данных между двумя 1С.
(5) omut, Да, нужно смотреть, на чем замедление.
(7) spezc, Интерактивные действия пользователя при работе с формой. Обращение одно, но лишних пару секунд критично. С учетом того что получение и обработка данных 0,5секунд. Между ХТТП-сервисами и SOAP-вебсервисами разница в скорости подключения почти в 2 раза. Достаточно прилично, на мой взгляд. Интересно, чего не делает ХТТП из того, что делает SOAP. (9) ekaruk, Модуль управляемого приложения.. он живет постоянно, делаем там переменную (экспортную), инициализируем веб-сервис (подключаемся), контекст соединения передаем в переменную.. и теперь можем использовать эту переменную чтобы обращаться к веб сервису без подключений (он будет подключен 1 раз при старте)
ПС: если у вас живут базы на одном сервере, и они клиент-серверные то я бы на вашем месте посмотрел бы внешние источники.. (13) AllexSoft, беда там есть. Соединение закроется через определённое время, если не будет использоваться (5 минут вроде как будет жить). (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.
Другое дело, что бы не было лишней инициализации обычная практика держать соединение. (24) Serginio, про файл не знал. Спасибо за идею. И правда Есть смысл так поступать. Я, правда, пошел немного по другому пути. Вообще отказывался от пакетов и все делал кодом на стороне сервера и так же клиента. Удобно, конечно, свернуть и развернуть все автоматом. Но редко это надо. Во всяком случае в моих задачах такой необходимости не было.

Либо сократить только до используемых типов и методов

(9) Получить вроде можно через ПредставлениеПриложения

И устанавливай для Вэб сервисов только самые необходимые.

(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, Да, либо так. Но в любом случае это не решает Ваш вопрос, так как я понял не нравиться именно время установления ws-соединения

(30) ekaruk, Еще не совсем понял про объем данных, в (0) написали 3/4 на установление соединения, сейчас пишите что не разобрались где затраты по времени, но если запросы небольшие то всегда время будет уходить на инициализацию библиотеки и запуск сеанса, причем куда большее чем на установление самой связи, на это платформа 1с требует определенных ресурсов от сервера.

И величина это будет всегда плавающая особенно если используется сервер где есть пиковые загрузки проца.

(33) Zixxx, Мне не нравится, что суммарное время обращения к веб-сервису в несколько раз больше времени получения и обработки данных внутри веб-сервиса. И еще больше мне не нравится нестабильность времени выполнения обращения к веб-сервису. Для аналогичного обращения время может отличаться в разы.
Я понимаю, что в любом случае какое-то время тратится на установку соединения и мне бы хотелось его минимизировать.

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

(34) ekaruk, В суммарном обращении к веб-сервису сколько раз выполняются отправляются soap или другие запросы?

Даже если сам объект соединения использовать повторно, все равно во второй базе заново инициализация сеанса выполняется.

(59) ekaruk, я как раз вчера экспериментировал с REST. Полный перечень физических лиц из ЗУПа вывелся с вполне приемлимой скоростью. Просмотр данных элемента справочника происходит практически моментально - визуальных задержек не обнаружено (60) oldfornit, под ее задачи REST будет тормознее.. он не для обмена сделан

Сейчас в моде архитектура Rest
Введение в службы RESTful с использованием WCF
Есть только один минус это аналог WSDL в SOAP
REST vs SOAP

Да и SOAP есть куча возможностей которые 1С вэб сервисы не используют
Например WS-ReliableMessaging
WS-Security

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

у меня обмен так реализован.
Выполняется подключение.
Потом переменная с подключением первым параметром передается в каждую процедуру обмена.
В среднем на подключение по 3G 3-5 секунд. Обмен уже по ходу дела от 1 до 15 минут. Проблем особых не было.

я про мобильное приложение. С тонкого клиента все быстрее на порядок.

Кстати скорость зависит от пакета XDTO который используется в Web-сервисе, от количества Операций, типов возвращаемых параметров

На практике следующее:
В web-сервисе пакетом-XDTO по умолчанию установил какой-то с типогово. Подключение выполнялось больше 1 минуты. Удалил - пару секунд.
Получается что при подключении анализируется весь вебсервис (можно в xml-ке подключения посмотреть). А при плохом интернете даже 2 мб играет большую роль.

(11) dj_serega, В вебсервисе передается в обе стороны ХранилищеЗначений, в ХТТП - сервисе строка.
Т.е. простейшие типы стандартного пространства имен.
Данные каждый раз разных типов, просто сериализуются в текст при передаче. просто. используйте хттп. определите среднее время на подключение и получение ответа (не считая время обработки на стороне самого сервиса) и возьми ее за константу и всю дальнейшую работу ведите с учетом этой константы. ну еще можете поиграться с хостингом, каналом сервера, которые возможно влияют на скорость отклика. у нее на одном сервере обе базы.. так что передача там мгновенная.. проблема в постоянной инициализации сеанса как я говорил выше

(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-соединения.

А вот если бы соединение не закрывалось бы после передачи данных, то пользователи бы ничего и не заметили, внутри базы получение и вывод номенклатуры такой же почти по времени.

(42) Zixxx, почему вы решили что соединение с веб сервисом закрывается после каждого вызова ? (43) AllexSoft, Так написано, проверяли, вернули ответ и соединение автоматом закрывается.

(44) Zixxx, да, проверил.. похоже это реализация SOAP-по 1с-ному..
Определение = Новый WSОпределения(Server, User, Pass); - это раз подключение к базе.. (для получения схемы сервиса)

Прокси = Новый WSПрокси(Определение, "http://****.ru", "SiteExchange", "SiteExchangeSoap");
прокси.выполнитьчтото(); - это второе подключение, для выполнения..

самое печальное что действительно WSПрокси отключается сразу после отработки метода сервиса (( все таки постоянное подключение создать не удастся с веб-сервисами от 1С, можно попробовать использовать какой нибудь внешний драйвер от MS например для чтения данных.
хотя может не париться и сделать через старый добрый COM ? постоянный коннект там можно 100%

Раннее я уже писал о Системном мониторе и Сборщиках данных загруженности оборудования в операционных системах семейства Windows. В данной статье на примере работы программ системы «1С:Предприятие» версии 8 рассмотрим, где и какие счетчики необходимо включать в замер производительности, а также попробуем проанализировать полученную информацию и сделать соответствующие выводы (данная статья будет полезна не только в случае анализа работы системы «1С:Предприятие» на текущем оборудовании, но и в целом для мониторинга загруженности серверов под управлением Windows).

0. Оглавление

1. Где и зачем вести мониторинг?

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

В случае анализа загруженности серверов, на которых работают компоненты системы «1С:Предприятие» прежде всего необходим мониторинг:

  • Сервера баз данных
  • Серверов, на которых запущен кластер серверов «1С:Предприятия»
  • В редких случаях сервера терминалов, если такой имеет место быть

2. Основные счетчики производительности

Приведем примеры основных счетчиков производительности, разбив их по типу исследоваемого оборудования (для разных версий Windows названия счетчиков могут немного отличаться).

2.1 Процессоры

Для анализа загруженности процессоров системы, как правило, достаточно 2 счетчиков производительности:

Для того, чтобы точно оценить, достаточно ли процессорных мощностей на сервере, может также понадобиться счетчик потоков.

2.2 Оперативная память

Для анализа достаточности / нехватки оперативной памяти на рабочем сервере, как правило, применяют 2 следующих счетчика:

2.3 Жесткие диски

2.4 Сетевые интерфейсы

Для каждого из используемых сетевых адаптеров на сервере можно скорость передачи данных через сеть с помощью следующего счетчика:

Смотрите также:

При попытке установить типовую конфигурацию системы «1С:Предприятие» 7.7 в 64-разрядных операционных системах вместо необходимых каталогов с информационными базами увидим ошибку: «Версия этого файла несовместима с используемой версией Windows. С помощью сведений о…

Установка платформы 1С:Предприятие 7.7 на 64-х битную операционную систему сопряжена с некоторыми трудностями. Дело в том, что установить 1С через обычный установщик не получится, даже если запускать программу в режиме…

По умолчанию поиск в Windows (в данном примере в Windows 7) ищет файлы по имени. Содержимое учитывает только в проиндексированных расположениях. Чтобы поиск искал по содержимому всех документов, нужно изменить…

Читайте также: