Все приведенные примеры анализировались на основе указанной обработки. Более того, прежде чем анализировать сеть обязательно необходимо спроектировать такое маленькое тестовое приложение. Например, последовательный запуск одного и того же отчета (напр. в Отчет для ПФР) анализировать трудно, так как он использует разные методы работы, одни из которых грузят ресурсы рабочей станции и сервера, а другие сети. Отделить одно от другого в этом случае очень трудно. Поэтому в случае 1С первым шагом предлагается быть следующее:
А) Анализ проблемного отчета и обработки через инструмент замера производительности кода (он отображает информацию о времени исполнения фрагментов кода 1С)
Б) С помощью Perfomance Monitor выделяем фрагменты, которые наиболее активно работают сетью
В) Создаем моделирующее приложение, для анализа сети, а далее с помощью него идем по изложенной стратегии.
Другой взгляд на работу сети.
По вышесказанному может сложится впечатление, что на самом деле виновата не сеть, а то как разработчики 1С создавали (или разработчики библиотек которые используются 1C для работы с данными ). Действительно, обработка основной информации на компьютере пользователя влечет за собой большое количество прогоняемых через сеть данных. Аналогичную ситуацию можно получить, если обрабатывать результаты запроса (курсора) на локальном ПК в независимости от приложения в двухзвенной архитектуре.
Что же - спасение в трехзвенной архитектуре (где мы будем получать только изображение данных на экран, но ничего не обрабатывать на ПК пользователя)?
Выделим два вопроса
А) Трехзвенная архитектура и сеть
Б) Классическая двухзвенная архитектура.
Примером хорошей трехзвенной архитектуры является SAP. Приложение SAP GUI занимается фактически только выводом на экран. Большие списки лимитируются просмотром 500 строк, используются другие ухищрения. Да, это приложение может работать и на самой плохой сети. С другой стороны ей требуются дорогие серверные кластеры, так как обработка данных идет на сервере. Так как у SAP используется свой язык программирования для финансовой логики, это налагает повышенные требования на количество процессоров и т.д. Но попробуйте использовать такое приложение по глобальным сетям с одной центральной базой. При текущем состоянии дел скорости 2-3Кбайт в секунду SAP GUI может оказаться недостаточно. И потом, обработку данных в режиме запрос-ответ никто не отменял, примером может быть листание списков, больших отчетов и другие накладные расходы сложного интерфейса. Проблемы возникнут ровно такие же, а так как время двойного пробега в WAN на порядок больше, то анализ сети проводить все-таки придется.
Какой выход? Можно использовать Citrix, но при сложном интерфейсе он может не спасти (см например анализ производительности от компании Citrix ). Для сокращения трафика печати в Citrix необходимо использовать Thin Print Client, который имеет свои "особенности".
В классической двухзвенной архитектуре можно многое улучшить, например, писать больше запросов, которые исполняются на MS SQL сервере и т.д. Однако, сейчас явно видна тенденция создания для прикладных приложений своих прикладных интерпретируемых языков (1С, MS Visual Basic For Application, ABAP for SAP). Прикладные интерпретируемые языки необходимы для скорости разработки, но для двухзвенной архитектуры они создают проблемы при работе с сетью, так как процедурная обработка идет на ПК пользователя. Если интерпретатор перенести на сервер, то это уже будет трехзвенная архитектура.
В общем, нам нужны хорошие LAN и WAN, а для этого надо иметь средство для идентификации проблем (это сеть или что-то другое?)
Исходя из вышесказанного, можно предложить следующую модель приложения (далее анализатор) которое это делает:
А) Сначала анализатор ведет перехват трафика и записывает размеры отправленных и принятых пакетов (почти как Sniffer, но только сокращает потом информации), при работе нашего приложения. Фиксируется время отправки пакетов с ПК и Сервера.
Б) Далее анализатор устанавливается на сервере и ПК и осуществляет эмуляцию работы приложения. При этом делаются замеры времени передачи пакетов. Это позволит смотреть только на работу сети, и не учитывать загрузку других компонентов ПК и Сервера.
В) Далее осуществляется сравнение результатов работы приложения на реальном ПК и Сервере с результатами на системе соединенной кросскабелем.
Вопросы к размышлению.
Достаточно мало изложено информации о работе с сетью на прикладном уровне (т.е. подобной методике, которая изложена в статье) и анализе работы приложений в сети. Буду благодарен тем, кто пришлет интересные ссылки.
Может кто-нибудь встречал анализатор протоколов с функциями прикладного анализатора, изложенного выше?
По опыту общения с сетевыми администраторами я прихожу к пониманию, что анализ работы сети на прикладном уровне придется выполнять тем, кто внедряет прикладные приложения. По крайней мере внедренец может показать, что мешает работе приложения (например, задержки в сети), а системный администратор уже будет искать причину. С другой стороны это влечет повышение уровня знаний внедренцев ПО. Может будут другие мнения?
Заключение.
В дальнейшем я предполагаю, дополнить статью примерами анализа SAP+Citrix, 1C + Citrix, где методика учитывает другие факторы. Возможно на это повлияют отклики читателей, ведь статья писалась не только как систематизация опыта для коллег, друзей, но и для более широкой аудитории.
Селиванов Сергей. selis76@mail.ru
