Шаблоны сайта SharePoint действительно менее эффективны, чем определения сайта?
Вы можете использовать TrailRenderer в единстве. TrailRenderer - это встроенный компонент Unity. Используя это, вы можете настроить ширину линии и высоту этого рендерера.
4 ответа
Влияние производительности использования Шаблонов Сайта по сравнению с Определениями Сайта обычно завышено.
Почему?
Ну, позволяет, берут этот пример:
- Вы берете определение сайта Сайта Команды.
- Вы сохраняете его как новый Шаблон Сайта
- Вы затем создаете новое sub веб-на этом новом шаблоне сайта.
Что Вы получили? Ну, важная вещь помнить состоит в том, что "Двоение" происходит на уровне СТРАНИЦЫ, НЕ на уровне САЙТА. Так как Вы не настроили страниц, затем любые страницы, к которым Вы получаете доступ, все еще прибывают непосредственно из Определения Сайта, непосредственно из файловой системы.
Хочу доказать его, вот два теста:
Первый тест
- Попытайтесь изменить default.aspx страницу в исходном Определении Сайта.
- Проверьте свой шаблон сайта, заметьте наблюдение модификации.
- Его все еще "Повторенный" к файловой системе
Второй тест
- Создайте новое определение сайта.
- Создайте новый сайт на основе этого нового Определения Сайта.
- Создайте новый Шаблон Сайта
- Отправьте шаблон сайта помощнику с SharePoint и попросите, чтобы они создали новое подвеб-на нем.
Это перестанет работать. Почему? Поскольку Определение Сайта не существует на их машине.
Так, для возвращения к вопросу "Шаблоны сайта SharePoint действительно менее производительны, чем определения сайта?" мой ответ был бы: "Соображения производительности не должны играть роль в Вашем решении использовать Определение Сайта или Шаблон Сайта, функциональная задача, которую Вы имеете, должна быть". Теперь это становится спорным, но для меня, существует очень очень немного причин выбрать Определение Сайта по созданию Функций.
Насколько "Двоение" идет. Да, при настройке страница будет сохранена в Базе данных, и да, необходимо будет сделать распространение в прямом и обратном направлениях базы данных для получения ее. Но, SharePoint, умный, который это, будет, конечно, кэшировать это. Так, в теории, да медленнее, на практике, никто действительно не замечает.
Двоение было в продукте с 2003 (вероятно, в STS перед этим, не помните), и я никогда не видел официального руководства на влиянии производительности, которое это оказывает, ни любой размышляющий вне, "это - более медленные" комментарии.
Это приводит меня полагать, что это просто действительно не вызывает беспокойство о. Большее беспокойство со страницами "Ghosted" является трудностью, которая идет с поддержанием их, но затем, с 2007 и Masterpages это - намного меньшая проблема.
Проблемой с недвоением не является так же проблема производительности как проблема обновления.
В SPS2003 недвоение имело недостаток производительности. Большая часть этих проблем была решена в SharePoint 2007. С одной стороны, неповторенные страницы работают как страницы без компиляций SPVirtualPathProvider - это на самом деле дает более быстрый рендеринг, по крайней мере, для первой страницы.
Реальный уничтожитель с недвоением (или настройка - кто когда-нибудь думал это хорошая идея и переименовать термин и также переключить "ООН"? ;-), когда Вы хотите обновить, и Ваши страницы, макеты страницы, основные страницы, типы контента и т.д. настраиваются. Если Вы когда-нибудь пытались делать косметическое обновление сайта MOSS с расширенной настройкой, Вы также знаете то, что боль это должно заставить все показывать новому дизайну, не освобождая расположение, или функциональность содержала на специализированных страницах.
hth Anders Rask
Определения сайта более производительны, потому что они кэшируются в файловой системе, хранятся ли шаблоны в базе данных и должны быть скомпилированы и выполнились каждый раз, когда страница представляется. Кроме того, пользовательскими определениями сайта является независимое обновление, в отличие от шаблонов, которые основаны на существующем шаблоне сайта.
Существуют другие различия, приятно обрисованные в общих чертах в этом сообщении в блоге и этом обновленном.
Проблему здесь называют, Двоясь. Из сайта поля SharePoint хранит много файлов (включая masterpages и pagelayouts) в 12 ульях веб-сайта SharePoint. Когда запрос выполнен для этих файлов, SharePoint достаточно умен, чтобы сделать операцию чтения с диска.
Возможно "Не повторить" эти страницы. По существу, createing модификация к странице, которая хранится в SharePoint conent база данных вместо файловой системы. Запрос на страницу Un-Ghosted приведет к распространению в прямом и обратном направлениях базы данных (выбирающий из базы данных, возвращая байты файла и т.д.). Это обязательно приводит к нетривиальному объему дополнительной работы. Когда Вы говорите о 100's или 1000-е пользователей, поражающих сайт, это распространение в прямом и обратном направлениях базы данных становится проблемой производительности.
Так SharePoint пользовательское определение сайта для в большой степени используемого веб-сайта захочет хранить как можно больше файлов в файловой системе веб-сервера (и кэшироваться.... из всего остального). Определение сайта не обязательно хранится в файловой системе, но процесс (кроме того, чтобы быть более сложным путем) дает намного больше контроля места хранения любых специализированных объектов.
Пример двух блогов, говорящих о проблеме. http://itfootprint.wordpress.com/2007/04/18/sharepoint-site-template-vs-site-definition/ http://my.advisor.com/doc/17614