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

Question

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

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

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

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

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

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

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

Рекомендации:

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

Answer 1

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

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

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

Комплименты Шивпрасад Коирала

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

Нет компиляции страниц:

No Compile Pages позволяет улучшить масштабирование для больших сайтов с тысячами страниц, так как Windows имеет ограничение на количество DLL-файлов, загружаемых в приложение, и производительность ухудшается при достижении этого предела. Установите директиву <% @ Page CompilationMode = "Auto"%> для условной компиляции, чтобы получить преимущества масштабирования без ограничений по коду. Вы также можете установить CompilationMode на "Never", чтобы предотвратить когда-либо компиляцию страницы. Вы можете установить это свойство в разделе в Web.config, чтобы применить его ко всем страницам приложения. Страница без компиляции выдаст ошибку, если она содержит код пользователя.

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

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

Answer 2

Нашел хорошее объяснение этому 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/