SharePoint, VirtualPathProviders и перезапуск приложений

Учитывая, что единственный способ выгрузить динамически скомпилированные сборки (для освобождения памяти) — выгрузить домен приложения, как SharePoint использует VirtualPathProviders, в частности, для главных страниц и макетов страниц, не натыкаясь на это ограничение?

Перезапуск можно отложить с помощью различных настроек, но нельзя полностью избежать, если мастер-страницы и макеты страниц часто обновляются и публикуются, верно?

(Связано ли отсутствие информации об этом с тем, что это более теоретическое ограничение, которое не распространено в шаблонах публикации? Вы лично замечали, что частота изменений главных страниц или макетов вызывает нестабильность приложения? Должен ли SharePoint выдавать предупреждение?)

Любая возможность в стиле CMS, использующая динамические веб-формы (включая, по умолчанию, представления MVC), подвержена нестабильности скорости изменения, верно?

Обновление на страницах без компиляции:

Страницы без компиляции В ASP.NET 2.0 модель компиляции была значительно переработана и расширена. Прекомпиляция сайта, пожалуй, самая популярная и востребованная из новых функций. Еще одна довольно интересная функция — страницы без компиляции. Это специальные страницы, которые просто никогда не компилируются. Итак, какова конечная цель некомпилируемых страниц и в чем разница между ними и статическими HTML-страницами? Для начала вы создаете страницу без компиляции, устанавливая для атрибута CompilationMode в директиве @Page значение Never. Когда запрашивается страница без компиляции, сборка страницы не создается и не сохраняется на диске. Вместо этого экземпляр компонента компоновщика страниц кэшируется в памяти и используется для создания вывода страницы для каждого запроса. Компоновщик страниц — это специальный компонент, который поддерживает анализатор страниц при построении дерева управления страницей. Когда компиляция включена, дерево управления используется для получения класса для компиляции. Когда компиляция выключена, для получения разметки используется управляющее дерево. Излишне говорить, что классы необходимы, если вы хотите дать программистам возможность прикреплять свой собственный код к странице. Страницы без компиляции состоят из серверных элементов управления и литералов, но вообще не содержат кода.

Страницы без компиляции подходят не для каждого приложения. Они предназначены исключительно для улучшения масштабируемости на очень больших веб-сайтах с тысячами страниц. Страницы без компиляции не могут быть привязаны к файлу кода и не могут содержать блок на стороне сервера. Единственная исполняемая часть кода, разрешенная на странице без компиляции, — это $-выражения. У некомпилируемых страниц есть два основных преимущества. В безопасной среде, такой как SharePoint, страницы без компиляции не позволяют разработчикам писать потенциально ошибочный код, который может вызвать проблемы в среде размещения и даже вывести ее из строя. На большом контентном веб-сайте страницы без компиляции позволяют избежать компиляции тысяч страниц.

Использованная литература:

1 – http://haacked.com/archive/2009/04/22/scripted-db-views.aspx


asp.net asp.net-mvc sharepoint restart virtualpathprovider
person Nariman    schedule 16.10.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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



Вот визуальное представление процесса, когда делается запрос на персонализированную страницу:

alt text
Поздравления Шивпрасад Коирала



Вот также хорошее описание режима без компиляции ASP.net

Без компилируемых страниц

Без компилируемых страниц обеспечивает улучшенное масштабирование для больших сайтов с тысячами страниц, поскольку Windows имеет ограничение на количество библиотек DLL, загружаемых в приложение, и производительность ухудшается по мере того, как вы дойти до этого предела. Установите директиву ‹%@ Page CompilationMode="Auto" %› для условной компиляции, чтобы получить преимущества масштабирования без ограничений кода. Вы также можете установить для CompilationMode значение «Никогда», чтобы предотвратить компиляцию страницы. Вы можете установить это свойство в разделе ‹pages/› в Web.config, чтобы оно применялось ко всем страницам в приложении. Страница без компиляции выдаст ошибку, если она содержит пользовательский код.


Таким образом, это в основном решает проблему, которую вы упомянули в отношении чрезмерного сброса приложений при выгрузке/загрузке домена приложения из-за многочисленных настроек, происходящих в режиме реального времени (проблема, которую должна решить любая CMS, созданная на среде выполнения ASP.net). ).

Вдобавок к этому; вы получаете многопользовательские возможности и масштабируемость SQL Server «бесплатно» при хранении настраиваемого контента таким образом; в отличие от подхода файловой системы, который потребовал бы дополнительных усилий для управления блокировкой.

person gn22    schedule 16.10.2009
comment
Спасибо за этот ответ. Конечно, это снижает производительность за счет масштабируемости; иначе по умолчанию было бы просто Авто для всех приложений? Но в отличие от сборок, кешированные компоновщики страниц можно восстанавливать по мере необходимости. Некоторые ссылки: weblogs.asp.net/jgaylord/archive/2005 /04/20/403580.aspx msdn.microsoft.com/en-us/library/ msdn.microsoft.com/en-us/library/ - person Nariman; 17.10.2009

arrow_upward
0
arrow_downward

Нашел хорошее объяснение этого 1:

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

Страницы без компиляции могут быть загружены в память, а затем выгружены способом, который невозможен для скомпилированных страниц, поскольку .NET Framework на самом деле не поддерживает концепцию выгрузки сборки DLL из памяти. Ближайшим эквивалентом будет повторное использование текущего процесса Windows или текущего домена приложений .NET. Однако этот тип повторного использования включает в себя выгрузку из памяти всех библиотек DLL сборки, а не только тех библиотек DLL сборки, которые в последнее время не использовались. Кроме того, .NET Framework накладывает верхний предел на количество сборочных библиотек DLL, которые можно загрузить в .NET AppDomain.

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

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

1 – http://chiragrdarji.wordpress.com/2007/10/12/page-ghosting-unghosting-and-effect-of-pageghosting-on-performance-in-sharepoint-2007/

person Nariman    schedule 17.10.2009