Любой метод в Umbraco, чтобы определить, какой XSLT вялый при трансформации? - PullRequest
Новая
       17

Любой метод в Umbraco, чтобы определить, какой XSLT вялый при трансформации?

1 голос
/ 29 декабря 2011

Я получаю очень низкую производительность с сайта Umbraco, размещенного в моей учетной записи Azure.Учетная запись запускает два сайта, каждый из которых имеет размер extrasmall и работает с двумя экземплярами для восстановления после отказа.

Отредактировано для ясности -

Доступно два сайтав каждом случае.Из этих двух сайтов один работает нормально, другой - очень медленно (несмотря на то, что обслуживается из одного и того же экземпляра, того же IIS и т. Д.).

-

Я начал с проверки экземпляров Azure, они выглядят нормально и особенно не борются (обычные инструменты: диспетчер задач, монитор ресурсов, perfmon и т. Д.).Оба сайта запускаются из SQL Azure, и, похоже, что там практически нет лагов.

Затем я запустил свой вялый сайт с помощью строки запроса ?umbdebugshowtrace=true, и большая часть задержек происходит в этот момент жизненного цикла страницы.: 

Category Message FromFirst(ms) FromLast(ms)

umbracoMacro Before performing transformation 0.858817787142857 0.000024

Resolve Urls 0 11.9020404352381 11.043223

umbracoMacro After performing transformation 11.9022704233333 0.000230

Выполнение XSLT-преобразования занимает около 11 секунд.

Итак, я провел несколько хакерских расследований и в основном удалил каждый элемент управления XSLT на странице, по одному за раз,похоже, что ни один из них (по отдельности) не вызывает зависания.

У кого-нибудь есть какие-либо рекомендации о том, как я могу углубиться в это и, возможно, получить немного больше информации о том, где именно задержка?1025 *

Здорово, что у меня достаточно данных, чтобы сузить их до проблемы преобразования XSLT, но больше информации было бы здорово:)

Заранее большое спасибо за любой совет!

Karl.

Ответы [ 3 ]

0 голосов
/ 29 декабря 2011

Я считаю, что отключение подмножества элементов управления (а не одного за другим) является практическим методом.

Фактически, это можно сделать аналогично процедуре двоичного поиска:

  1. База: Если у вас есть только один элемент управления, это неисправный элемент управления

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

  3. Продолжить рекурсивно, применяя 2. выше к набору элементов управлениякоторый содержит неисправный.

0 голосов
/ 29 декабря 2011

Тот факт, что преобразование заканчивается через 11 секунд после его запуска, не обязательно означает, что выполнение XSLT заняло 11 секунд. Возможно, он потратил большую часть этого времени в ожидании ресурсов, которые ему нужны, прежде чем он сможет начать. Например, частой причиной является то, что механизм преобразования вызывает синтаксический анализатор XML, а анализатор XML запрашивает DTD для выборки с удаленного веб-сайта.

0 голосов
/ 29 декабря 2011

Если это проблема в одном экземпляре, но не в другом, я думаю, что у вас может возникнуть одна из проблем с Azure: вы не единственный клиент на сервере.

Что-то вроде XSLT-преобразования действительно довольно ресурсоемко; в зависимости от преобразования для обработки может потребоваться значительное количество процессоров.

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

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

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

...