15.09.2010

Оптимизация клиент-серверного взаимодействия прикладных решений

Интерфейс 1С:Предприятия в режиме "Управляемое приложение" ориентирован на возможность работы не только в обычной локальной сети, но и на возможность работы через Интернет, в том числе по низкоскоростным каналам связи, например, GPRS, Dial-up. Платформа содержит большое количество механизмов, которые автоматически оптимизируют работу системы в этих условиях. Кроме того, существует специальный параметр запуска "Низкая скорость соединения", включающий работу дополнительных средств оптимизации. Однако, оптимизация не может быть полностью выполнена платформой без участия разработчиков конфигураций. При разработке прикладных решений необходимо придерживаться определенных методик для того, чтобы обеспечить эффективную работу конфигураций при использовании низкоскоростных каналов связи. В этой статье описывается общий подход к тому, как вести разработку и оценивать эффективность работы. Особенности работы конкретных механизмов платформы и их оптимизации описываются в других материалах.

Существует два основных предмета оптимизации:

1. Количество вызовов.
2. Объем передаваемых данных (трафика).

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

В платформе существуют следующие инструменты для оптимизации и оценки работы системы:

1. Показатели производительности.
   Механизм выдает в режиме 1С:Предприятия общую информацию о количестве вызовов и объеме передаваемых данных по каждому интерактивному действию пользователя. Он удобен  тем, что выдает информацию в процессе работы и не требует специальных действий. С помощью него можно не только проводить целенаправленный анализ, но и "присматривать" по ходу разработки за  этими показателями.
2. Замер производительности в конфигураторе.
   Позволяет оценивать количество вызовов сервера по отдельным строчкам кода выполняемых модулей.
3. Имитация задержки при вызовах сервера.
   Позволяет при разработке визуально оценить, как будет вести себя система в условиях работы на низкоскоростных каналах связи.

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

Основная стратегия оптимизации работы платформы построена  на минимизации передаваемой на клиента информации по количеству вызовов и объему данных. Для этого платформа действует по следующей методике:

• Передает на клиента только то, что нужно на клиенте.
• Передает не всю информацию сразу, а, по возможности, реализует принцип передачи "по требованию", чтобы не передавать большие объемы данных.
• Передает информацию определенным порциями, чтобы не делать большого количества вызовов сервера.
• Использует многоуровневое кэширование, чтобы не передавать повторно информацию, уже переданную на клиента.

Легко заметить, что некоторые  пункты методики противоречат друг другу. Это естественно, так как нужно оптимизировать работу системы и по объемам и по количеству вызовов. Соответственно, в работе платформы реализуются компромиссные решения.

Остановимся чуть подробнее  на механизмах кэширования. Можно выделить следующие основные уровни кэширования:

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

Для разных механизмов платформы используются разные уровни кэширования. Заметим, что на самом деле механизмы кэширования имеют более сложное деление, а здесь уровни описаны в упрощенном виде.

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

Для проверки разработанного решения следует подобрать правильные сценарии проверки.

При оптимизации прикладных решений важно учитывать необходимость проверки типичных сценариев работы. Поэтому при проверках нужно ориентироваться на максимально реалистичные объемы данных и последовательность действий пользователя. Например, работу с табличной частью нужно проверять при наличии в табличной части ожидаемого количества строк. При этом желательно проверить работу как на типичном (среднем) количестве строк, так и на ожидаемых редких ситуациях, чтобы проверить, не будет ли недопустимого снижения производительности.

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

Можно выделить три  уровня испытаний:

1. Первое  действие после изменения конфигурации
2. Первое  действие в сеансе, если в предыдущем сеансе уже выполнялось аналогичное действие
3. Повторное действие в сеансе, если в этом сеансе уже выполнялось аналогичное действие

В приведенных уровнях мы не указали случай смены версии платформы. Предлагается этот случай  не учитывать, так как он редкий и оптимизировать для него конфигурацию не представляется целесообразным.

Для уровня 1) замеры провести можно, но в большинстве случаев ими можно пренебречь, так как это не очень частый случай и в нем количество вызовов, и объем данных будут существенно выше, чем в двух последующих.

Наибольший  интерес представляют уровни 2) и 3). Их имеет смысл проверять отдельно. При наличии ограниченного времени на анализ и оптимизацию следует отдать приоритет уровню 3. Хотя здесь важно учитывать реалистичные сценарии. Например, может быть типичная ситуация, при которой пользователи будут запускать систему для выполнения одного действия (визирования заявки). В этом случае, критичным  становится уровень 2).

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

Таким образом, основные принципы – максимальное приближение тестового прогона сценария к реальной жизни. Допустим, мы будем замерять работу системы по вводу заказа в уровне 3). Для этого нужно запустить систему, ввести, например, два заказа с разными данными, потом завершить сеанс. В новом сеансе (от лица того же пользователя), снова ввести первый заказ и только при вводе второго заказа выполнить необходимые замеры. Это позволит замерить самый частотный случай – ввод не в первом сеансе и не первого документа в сеансе, но ввод с новыми данными, которые не использовались в этом сеансе.

Для оценки работы системы можно использовать все три, перечисленных выше, инструмента.

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

Режим имитации задержек при вызове сервера имеет смысл применять отдельно. То есть дополнительно к обычным проверкам. При этом в нем нет смысла проводить анализ количества вызовов, так как он не должен отличаться от работы без режима имитации. В режиме имитации имеет смысл оценить комфортность действий пользователя, замеряя время выполнения операции и по ощущениям.

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

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

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

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

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

Анализ серверных вызовов в коде модулей, можно, разумеется, выполнять с помощью режима замера производительности в конфигураторе. Однако, нужно учитывать, что этот режим показывает только вызовы, которые выполняются непосредственно в ходе выполнения модулей и не показывает вызовы, которые выполняются платформой вне выполнения модулей.

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

Другой методикой может являться фиксация в виде нормативного документа некоторых показателей для самых критичных сценариев и анализ изменения этих показателей по мере развития конфигурации.

Приведем некоторые показатели количества вызовов, которые характерны для наиболее типичных сценариев.

Таблица приведена  для уровня 3). Значения для уровня 2) приведены в скобках там, где они отличаются от уровня 3). Данные для тонкого клиента и для веб-клиента на этих операциях не отличаются

Разумеется, эти методики позволяют найти только "подозрительные" места и возможные участки для оптимизации.

Проведя интерпретацию результатов  тестов можно переходить к выработке решений по оптимизации. При оптимизации следует ориентироваться на минимизацию количества вызовов и снижение объема передаваемых данных. Для этого используются различные методики: объединение нескольких вызовов в один вызов, исключение лишних вызовов, применение функций  повторно используемых возвращаемое значение и т.д.. Способы оптимизации зависят от конкретных механизмов и описываются в других материалах. Рекомендуется исходить из подхода: "Можно ли обойтись в этом действии без этого вызова и можно ли обойтись без передачи этого объема  информации?".  При этом очевидно, что структура кода конфигурации должна будет быть обусловлена не прикладными соображениями, а соображениями клиент-серверного взаимодействия. Например, с  точки зрения разделения функциональности на части можно было бы при запуске конфигурации выполнять вызовы сервера для получения некоторых начальных данных, требуемых клиенту, отдельно по каждой подсистеме. Но, исходя из особенности клиент-серверной разработки, необходимо реализовать получение необходимой информации в одном вызове.

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