Действительно ли шаблоны сайтов SharePoint менее эффективны, чем определения сайтов?

Question

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

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

Итак, какова архитектурная причина, по которой шаблон сайта будет менее эффективным, чем определение сайта?

---

Редактировать: ссылки на блоги, которые говорят, что разница в производительности:

• С MSDN : поскольку хранить шаблоны и извлекать их из базы данных очень медленно, это может привести к снижению производительности.
• От DevX : Однако пользовательские шаблоны в SharePoint могут привести к проблемам с производительностью и могут оказаться не лучшим подходом, если вы пытаетесь создать набор повторно используемых шаблонов для всей организации.
• С IT Footprint : поскольку хранить и извлекать шаблоны из базы данных очень медленно, шаблоны сайтов могут привести к снижению производительности. Шаблоны в базе данных компилируются и выполняются каждый раз при визуализации страницы.
• С Брендинг SharePoint : пользовательские определения сайтов обладают следующими преимуществами по сравнению с пользовательскими шаблонами:
  • Данные хранятся непосредственно на веб-серверах, поэтому производительность обычно выше.

Как минимум, я думаю, что вышеупомянутые статьи являются неполными, и я думаю, что некоторые вводят в заблуждение, основываясь на том, что я знаю об архитектуре SharePoint.

Я прочитал еще одно сообщение в блоге, в котором выступал против различий в производительности, но не могу найти ссылку.

Answer 1

Влияние на производительность использования шаблонов сайтов по сравнению с определениями сайтов обычно завышено.

Почему?

Хорошо, давайте возьмем этот пример:

1. Вы принимаете определение сайта Team Team.
2. Вы сохраняете его как новый шаблон сайта
3. Затем вы создаете новую суб-сеть на основе этого нового шаблона сайта.

Что у тебя есть? Ну, важно помнить, что «Ghosting» происходит на уровне страницы, а не на уровне сайта. Поскольку вы не настраивали ЛЮБЫЕ страницы, то все страницы, к которым вы обращаетесь, все еще поступают непосредственно из определения сайта, непосредственно из файловой системы.

Хотите доказать это, вот два теста:

Первый тест

1. Попробуйте изменить страницу default.aspx в исходном определении сайта.
2. Проверьте шаблон сайта, обратите внимание, что вы видите модификацию.
3. Это все еще "Ghosted" для файловой системы

Второй тест

1. Создание нового определения сайта.
2. Создайте новый сайт на основе этого нового определения сайта.
3. Создать новый шаблон сайта
4. Отправьте шаблон сайта помощнику с SharePoint и попросите его создать на его основе новый веб-сайт.

Это не удастся. Зачем? Потому что определение сайта не существует на их машине.

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

Что касается "Призрака". Да, когда настроенная ваша страница будет храниться в базе данных, и да, вам придется сделать обход базы данных, чтобы получить его. Но SharePoint, умный, что это, конечно, кеширует это. Так что, теоретически, да, это медленнее, на практике никто не замечает.

Ghosting присутствует в продукте с 2003 года (вероятно, в STS до этого, не помню), и я никогда не видел ни официального руководства по влиянию на производительность, ни кого-либо, кто спекулировал бы за «медленными» комментариями.

Это заставляет меня верить, что это действительно не беспокоит. Больше проблем с «призрачными» страницами вызывает сложность их обслуживания, но с 2007 и Masterpages это гораздо меньшая проблема.

Answer 2

Проблема с unghosting - не столько проблема производительности, сколько проблема с обновлением.

В SPS2003 unghosting имел недостаток производительности. Многие из этих проблем были решены в SharePoint 2007. Во-первых, неявные страницы запускаются как страницы без компиляции с помощью SPVirtualPathProvider - это на самом деле ускоряет рендеринг по крайней мере для первой страницы.

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

НТН Андерс Раск

Answer 3

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

Существуют и другие отличия, хорошо описанные в этом блоге и в этом обновленном .

Answer 4

Проблема здесь называется Ghosting. Готовый сайт SharePoint хранит много файлов (включая мастер-страницы и разметки страниц) в 12 кустах сайта SharePoint. Когда делается запрос на эти файлы, SharePoint достаточно умен, чтобы выполнить операцию чтения с диска.

Возможно "Un-Ghost" на этих страницах. По сути, создание модификации страницы, которая хранится в базе данных контента SharePoint вместо файловой системы. Запрос на страницу без Ghosted приведет к обращению в базу данных (выбор из базы данных, возврат байтов файла и т. Д.). Это обязательно приводит к нетривиальному количеству дополнительной работы. Когда вы говорите о сотнях или тысячах пользователей, заходящих на сайт, этот круговой обход базы данных становится проблемой производительности.

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

Пример двух блогов, говорящих о проблеме. http://itfootprint.wordpress.com/2007/04/18/sharepoint-site-template-vs-site-definition/ http://my.advisor.com/doc/17614