Действительно ли шаблоны сайтов SharePoint менее эффективны, чем определения сайтов?
Таким образом, в блогосфере SharePoint кажется, что все просто копируют и вставляют одни и те же маркеры из других блогов. Одно замечание, которое я видел, заключается в том, что шаблоны сайтов SharePoint менее эффективны, чем определения сайтов, поскольку определения сайтов хранятся в файловой системе. Это правда?
Кажется странным, что шаблоны сайта были бы менее эффективными. Насколько я понимаю, все содержимое сайта хранится в базе данных, используете ли вы шаблон сайта или определение сайта. Шаблон сайта применяется один раз к базе данных, и с тех пор на сайте не должно волновать, был ли контент создан с использованием шаблона сайта или нет.
Итак, какова архитектурная причина, почему шаблон сайта будет менее эффективным, чем определение сайта?
Изменить: Ссылки на блоги, которые говорят, что есть разница в производительности:
- Из MSDN: поскольку хранить и извлекать шаблоны из базы данных очень медленно, шаблоны сайтов могут снизить производительность.
- Из DevX: Тем не менее, пользовательские шаблоны в SharePoint могут привести к проблемам с производительностью и могут быть не лучшим подходом, если вы пытаетесь создать набор повторно используемых шаблонов для всей организации.
- Из области ИТ. Из-за медленного хранения и извлечения шаблонов из базы данных шаблоны сайтов могут привести к снижению производительности. Шаблоны в базе данных компилируются и выполняются каждый раз при визуализации страницы.
- От брендинга SharePoint: пользовательские определения сайтов обладают следующими преимуществами по сравнению с пользовательскими шаблонами:
- Данные хранятся непосредственно на веб-серверах, поэтому производительность обычно выше.
Как минимум, я думаю, что вышеупомянутые статьи являются неполными, и я думаю, что некоторые вводят в заблуждение, основываясь на том, что я знаю об архитектуре SharePoint.
Я прочитал еще одно сообщение в блоге, в котором выступал против различий в производительности, но я не могу найти ссылку.
4 ответа
Влияние на производительность использования шаблонов сайтов по сравнению с определениями сайтов, как правило, завышено.
Зачем?
Хорошо, давайте возьмем этот пример:
- Вы берете определение сайта Team Team.
- Вы сохраняете его как новый шаблон сайта
- Затем вы создаете новую суб-сеть на основе этого нового шаблона сайта.
Что у тебя? Ну, важно помнить, что "Ghosting" происходит на уровне страницы, а не на уровне сайта. Поскольку вы не настраивали ЛЮБЫЕ страницы, то все страницы, к которым вы обращаетесь, все еще поступают непосредственно из определения сайта, непосредственно из файловой системы.
Хочу доказать это, вот два теста:
Первый тест
- Попробуйте изменить страницу default.aspx в исходном определении сайта.
- Проверьте шаблон вашего сайта, обратите внимание, что вы видите модификацию.
- Это все еще "Ghosted" для файловой системы
Второй тест
- Создайте новое определение сайта.
- Создайте новый сайт на основе этого нового определения сайта.
- Создать новый шаблон сайта
- Отправьте шаблон сайта товарищу с SharePoint и попросите его создать новый веб-сайт на его основе.
Это не удастся. Зачем? Потому что определение сайта не существует на их машине.
Итак, вернемся к вашему вопросу: "Действительно ли шаблоны сайтов SharePoint менее производительны, чем определения сайтов?" мой ответ будет таким: "Вопросы производительности не должны играть роли в вашем решении использовать определение сайта или шаблон сайта, а ваша функциональная цель должна быть такой". Сейчас это становится спорным, но для меня очень мало причин выбирать определение сайта, а не создавать компоненты.
Насколько "Ghosting" идет. Да, когда настроенная ваша страница будет храниться в базе данных, и да, вам придется сделать обход базы данных, чтобы получить его. Но, SharePoint, умный, что это, конечно, кеширует это. Так что, теоретически, да, это медленнее, на практике никто не замечает.
Ghosting присутствует в продукте с 2003 года (вероятно, в STS до этого, не помню), и я никогда не видел официального руководства о влиянии на производительность, которое он оказывает, и никто не спекулировал, кроме комментариев "это медленнее".
Это заставляет меня верить, что это действительно не беспокоит. Больше проблем со страницами "Ghosted" вызывает сложность их обслуживания, но с 2007 и Masterpages это гораздо меньшая проблема.
Проблема с unghosting - это не столько проблема производительности, сколько проблема с обновлением.
У SPS2003 unghosting был недостаток производительности. Большая часть этих проблем была решена в SharePoint 2007. Во-первых, неявные страницы запускаются как страницы без компиляции с помощью SPVirtualPathProvider - это на самом деле дает более быстрый рендеринг, по крайней мере, для первой страницы.
Настоящий убийца с un-ghosting (или настройкой - кто когда-либо думал, что будет хорошей идеей как переименовать термин, так и переключить "un"?;-), это когда вы хотите обновить, и ваши страницы, макеты страниц, главные страницы, типы контента и т. д. настроены. Если вы когда-либо пытались сделать косметическое обновление сайта MOSS с обширной настройкой, вы также знаете, как больно получить все, чтобы показать новый дизайн, не теряя макет или функциональность, содержащуюся в настроенных страницах.
Андерс Раск
Определения сайтов более производительны, поскольку они кэшируются в файловой системе, независимо от того, хранятся ли шаблоны в базе данных и должны ли они компилироваться и выполняться при каждом отображении страницы. Кроме того, пользовательские определения сайтов не зависят от обновления, в отличие от шаблонов, которые основаны на существующем шаблоне сайта.
В этом посте и в этом обновленном сообщается о других различиях.
Проблема здесь называется 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