Microsoft SharePoint 2010: Профилирование и упаковка кода для работы в «песочнице»

При создании веб-решения масштаба предприятия на базе SharePoint 2010 важной частью цикла разработки является настройка и тестирование производительности. Если в вашем решении много нестандартного кода, это не просто важно — это жизненно необходимо.

SharePoint предлагает много возможностей индивидуальной настройки, в числе которых веб-части, пользовательские приемники и действия и другие. Есть также разные модели выполнения, позволяющие получить больше контроля над производительностью, безопасностью и высокой доступностью. «Песочница» — одна из моделей выполнения.

Получить профиль производительности блоков кода, создаваемого для выполнения в песочнице, можно средствами Visual Studio 2010 Profiler. Другой фактор, влияющий на производительность и масштабируемость решений для песочниц, — способ упаковки и развертывания пользовательских блоков кода, таких как веб-части. Эти компоненты можно упаковать так, чтобы они использовали службы песочницы, работающие на многих серверах, особенно на корпоративных серверных фермах.

В SharePoint 2010 есть много инструментов, которые позволяют выявлять возможные узкие места в пользовательком коде путем оценки времени выполнения кода, вызовов внешних ресурсов, таких как веб-службы, базы данных, запросы баз данных и числа инициируемых запросов и т. п. Можно использовать панель разработчика для оценки времени выполнения различных блоков кода. Время выполнения можно также анализировать с применением журналов ULS (Unified Logging Service).

Определенные ограничения

В случае решений для песочниц панель разработчика не позволяет получить полезную информацию. Также не будет никакой информации об исполнении решения-песочницы в журнале ULS. Компоненты песочницы не могут регистрировать информацию в журнале ULS. Так как SharePoint 2010 не позволяет понимать поведение блоков пользовательского кода в среде песочницы, нужно полагаться на возможности профилирования в Visual Studio Team System 2010.

Когда речь идет о профилировании кода, у вас есть две возможности: тестирование производительности шаблонов проектов в Visual Studio 2010 и использование автономного средства профилирования из Visual Studio Team System. При тестировании производительности шаблонов проектов в Visual Studio нужно настроить свой исходный код со всеми необходимыми зависимостями на той же машине, на которой установлен пакет Visual Studio Team System 2010 (VSTS) Ultimate Edition. Его возможно использовать только в среде разработки. Имейте в виду, что в этом варианте невозможно получить подробности выполнения кода в среде песочницы, а также невозможно работать с наборами сайтов заголовков узла.

При использовании автономного средства профилирования из Visual Studio Team System исходный код не нужен. В данном случае требуется компилированный результат. Это средство можно использовать в средах между средой разработки и производственной средой — таких как промежуточная среда, среда приемочного тестирования пользователями (UAT), пред-производственная среда и другие, — в которых невозможна установка средств разработки. Этот метод также дает дополнительную гибкость, так как выполнять профилирование любых процессов можно отдельно от W3WP.exe. Это позволяет извлекать подробную информацию об исполнении кода в среде песочницы, в том числе об использовании памяти и времени выполнения.

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

1. VSAspNetCmd.exe предназначен исключительно для профилирования W3WP.exe.
2. VSPerfCmd.Exe позволяет выполнять профилирование любого процесса.

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

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

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

Так как средство VSPerCMD.exe предназначено для профилирования любого нужного процесса, его можно использовать для профилирования процессов SPUCWorkerProcess.exe и SPUCWorkerProcessProxy.exe. При этом будет сгенерирована подробная информация, которая позволит больше узнать об исполнении кода в песочнице, в том числе об использовании памяти и времени выполнения.

Профилирование кода в песочнице

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

Далее приводится последовательность команд, необходимых для выполнения профиля. Во-первых, нужно задать нужные переменные среды.

VSPerfClrEnv /globalsampleon

Перезапустите машину и выполните следующую команду:

VSPerfClrEnv /globalinteractionon

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

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

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

Запустите соответствующее веб-приложение. Определите идентификатор процесса этого приложения — если на машине одновременно работают другие веб-приложения, выполните следующий код:

VSPerfCmd /Start:Sample /Output:<FILE_NAME>.vsp  /user:everyone  /CrossSession

Затем в зависимости от выбранной модели выполнения задайте SPUCWorkerProcess.exe или SPUCWorkerProcessProxy.exe и средство профилирования подключится к выбранному процессу:

VSPerfCmd /Attach:<PROCESS-ID>

Выполните пользовательские действия нужного веб-приложения:

VSPerfCmd /Detach:<PROCESS-ID>
VSPerfCmd /Shutdown

Если вы столкнулись с проблемами с символами, подключите эти символы к отчетам:

VSPerfReport.exe /summary:all /packsymbols  <ReportName.VSP>

Наконец сбросьте переменные среды:

vsperfclrenv /globaloff

Созданные этим средством профилирования отчеты можно открыть в Visual Studio 2010 Ultimate Edition, чтобы найти «узкие пути» и понять, как код ведет себя в среде песочницы. Это поможет внести нужные коррективы для оптимизации производительности.

Не забудьте убедиться, чо в среде Visual Studio есть нужные символы, чтобы открыть отчет без потери информации. На машинах, где автономные средства профилирования установлены вместе с любыми редакциями Visual Studio 2010 (за исключением Ultimate), могут возникать ошибки. Нужно устанавливать только автономные средства профилирования.

Упаковка решения

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

Число подключений на один процесс должно быть меньше или равно числу доменов приложений. Число подключений также должно быть меньше на уровне, в котором у свойства ResourceMaxValue значение больше.

В каждый момент времени в каждом домене приложения может выполняться только одно решение-песочница. Число доменов приложений представляет число решений-песочниц, которые можно вообще загрузить. Один WSP-файл представляет решение-песочницу. После выгрузки WSP-пакета его можно увидеть в ряду с другими решениями-песочницами в коллекции решений.

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

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

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

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

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

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