Вот еще один кросс-пост из нашего блога JetBrains .NET . Он сфокусирован на dotTrace, но в нем также есть много полезных советов и рекомендаций по облачным службам Windows Azure, особенно в отношении работы с балансировщиком нагрузки. Приятного чтения!
С помощью dotTrace Performance мы можем профилировать приложения, работающие как на нашем локальном компьютере, так и на удаленных компьютерах . Последнее может быть очень полезно, когда некоторые проблемы с производительностью возникают только на промежуточном сервере (или даже хуже: только на производстве). А что если этот удаленный сервер является облачной службой Windows Azure?
Примечание: в этом посте мы рассмотрим, как настроить облачную службу Windows Azure для удаленного профилирования с помощью dotTrace, стороны платформы «как услуга» Windows Azure. Если вы работаете с обычными виртуальными машинами («инфраструктура как услуга»), единственное, что вам нужно сделать, это открыть любой порт в loadbalancer , перенаправить его на порт машины 9000 (по умолчанию dotTrace) и следовать обычный рабочий процесс удаленного профилирования .
Подготовка облачной службы Windows Azure к удаленному профилированию
Поскольку у нас нет системных администраторов под рукой при работе с облачными сервисами, мы должны выполнить часть их работы самостоятельно. Самая важная часть работы — убедиться, что балансировщик нагрузки в Windows Azure пропускает трафик dotTrace к экземпляру сервера, который мы хотим профилировать.
Мы можем сделать это, добавив тип конечной точки InstanceInput в конфигурацию веб- или рабочей роли:
По умолчанию балансировщик нагрузки Windows Azure использует циклический подход при маршрутизации трафика к экземплярам ролей. По сути, каждый запрос направляется на случайный экземпляр. При дальнейшем профилировании мы хотим ориентироваться на конкретную машину. И это то, что позволяет нам конечная точка InstanceInput : она открывает диапазон портов на балансировщике нагрузки и перенаправляет трафик на локальный порт. В приведенном выше примере мы открываем порты 9000-9019 в распределителе нагрузки и перенаправляем их на порт 9000 на сервере. Если мы хотим подключиться к конкретному экземпляру, мы можем использовать номер порта из этого диапазона. Порт 9000 будет подключаться к порту 9000 на экземпляре сервера 0. Порт 9001 будет подключаться к порту 9000 на экземпляре роли 1 и так далее.
При развертывании обязательно включите удаленный рабочий стол для этой роли. Это позволит нам подключиться к определенной машине и запустить там удаленный агент dotTrace.
Вот и все. Всякий раз, когда мы хотим запустить удаленное профилирование для конкретного экземпляра роли, теперь мы можем подключиться к машине напрямую.
Запуск сеанса удаленного профилирования с конкретным экземпляром
И вот этот момент наступил: нам нужно профилировать производство!
Прежде всего, мы хотим открыть подключение к удаленному рабочему столу для одного из наших экземпляров роли. На портале управления Windows Azure мы можем подключиться к конкретному экземпляру, выбрав его и нажав кнопку « Подключиться» . Сохраните файл, который загружается где-то в вашей системе: нам нужно изменить его перед подключением.
Причина сохранения и не немедленного открытия файла .rdp заключается в том, что нам необходимо скопировать удаленный агент dotTrace на компьютер. Для этого мы хотим разрешить доступ к нашим локальным дискам. Щелкните правой кнопкой мыши загруженный файл .rdp и выберите « Изменить» в контекстном меню. На вкладке « Локальные ресурсы » установите флажок « Диски», чтобы разрешить доступ к нашей локальной файловой системе.
Сохраните изменения и подключитесь к удаленному компьютеру. Теперь мы можем скопировать удаленный агент dotTrace в экземпляр роли, скопировав все файлы из нашей локальной установки dotTrace. Удаленный агент можно найти в C: \ Program Files (x86) \ JetBrains \ dotTrace \ v5.3 \ Bin \ Remote , но, поскольку машина в Windows Azure не имеет ни малейшего представления об этом пути, мы должны указать \\ tsclient \ C \ Program Files (x86) \ JetBrains \ dotTrace \ v5.3 \ Bin \ Remote вместо этого.
Из скопированной папки запустите RemoteAgent.exe . Появится окно консоли, подобное приведенному ниже:
Пока нет: мы открыли балансировщик нагрузки в Windows Azure, чтобы позволить трафику проходить к нашей машине, но собственный брандмауэр машины будет блокировать наше входящее соединение. Чтобы решить эту проблему, настройте брандмауэр Windows, чтобы разрешить доступ через порт 9000. Однострочник, который можно запустить в командной строке, будет выглядеть следующим образом:
netsh advfirewall firewall добавить правило name = «Profiler» dir = в действии = разрешить протокол = TCP localport = 9000
Поскольку мы открыли порты с 9000 по 9019 в балансировщике нагрузки Windows Azure и каждый экземпляр роли получает свой собственный номер порта из этого диапазона, теперь мы можем подключаться к машине с помощью dotTrace. Мы подключились к экземпляру 1, что означает, что мы должны подключиться к порту 9001 в окне присоединения к процессу dotTrace . URL удаленного агента будет выглядеть как http: // <yourservice > .cloudapp.net: PORT / RemoteAgent / AgentService.asmx .
Далее мы можем выбрать процесс, для которого мы хотим выполнить отслеживание производительности. Я развернул веб-приложение, поэтому буду подключаться к файлу IIS w3wp.exe .
Теперь мы можем использовать наше приложение и попытаться воспроизвести проблемы с производительностью. Как только мы почувствуем, что у нас достаточно данных, кнопка « Получить снимок» загрузит все необходимые данные с сервера для локальной проверки.
Теперь мы можем выполнять задачи анализа производительности и искать проблемы с производительностью. Мы можем анализировать данные снимка так же, как если бы мы записали снимок локально. После определения основной причины и развертывания исправления мы можем повторить процесс, чтобы собрать еще один снимок и убедиться, что вы решили проблему с производительностью. Обратите внимание, что все шаги в этом посте должны быть выполнены снова в следующем сеансе профилирования: компьютеры облачной службы Windows Azure не имеют состояния и, вероятно, откажутся от всего, что мы с ними сделали до сих пор.
Бонусный совет: получите профилируемый экземпляр из балансировщика нагрузки
Поскольку мы профилируем производственное приложение, мы можем мешать нашим пользователям собирать данные профилирования. Еще одна проблема, с которой мы столкнулись, заключается в том, что наши собственные тестовые данные и данные нашего реального пользователя будут отображаться в снимке производительности. И если мы запускаем много экземпляров, не каждое действие, которое мы делаем в приложении, будет выполняться экземпляром роли, к которому мы подключены, из-за циклического распределения нагрузки в Windows Azure.
В идеале мы хотим временно удалить экземпляр роли, который мы профилируем, из балансировщика нагрузки, чтобы преодолеть эти проблемы. Хорошая новость: мы можем это сделать! Единственное, что нам нужно сделать, это добавить небольшой фрагмент кода в наш класс WebRole.cs или WorkerRole.cs .
public class WebRole : RoleEntryPoint
{
public override bool OnStart()
{
// For information on handling configuration changes
// see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.
RoleEnvironment.StatusCheck += (sender, args) =>
{
if (File.Exists("C:\\Config\\profiling.txt"))
{
args.SetBusy();
}
};
return base.OnStart();
}
}
По сути, то, что мы здесь делаем, это захват зондов балансировщика нагрузки, чтобы увидеть, исправен ли наш узел. Мы можем решить ответить на балансировщик нагрузки, что наш текущий экземпляр занят и не должен получать никаких новых запросов. В приведенном выше примере кода мы проверяем, существует ли файл C: \ Config \ profiling.txt . Если это так, мы отвечаем балансировщику нагрузки с занятым статусом.
Когда мы начинаем профилирование, мы можем теперь создать файл C: \ Config \ profiling.txt, чтобы взять экземпляр, который мы профилируем, из пула серверов. Примерно через минуту портал управления сообщит, что экземпляр занят.
Лучше всего то, что мы все еще можем присоединиться к конечной точке конкретного экземпляра и прикрепить dotTrace к этому экземпляру. Просто имейте в виду, что использование приложения теперь должно происходить в сеансе удаленного рабочего стола, который мы открыли ранее, поскольку у нас больше нет текущей машины, доступной из Интернета.
Закончив, мы можем просто удалить файл C: \ Config \ profiling.txt, и Windows Azure добавит компьютер обратно в пул серверов. Не забывайте об этом, иначе вы будете платить за машину, не имея возможности обслуживать приложение с нее. Повторная загрузка машины также добавит ее в пул снова.