Оптимизация Office SharePoint Server для сред глобальной сети

В этой статье:

• Создание топологий глобальной сети

• Оптимизация процесса обхода контента

• Ускорители глобальной сети и другие средства

• Создание страниц быстрой загрузки

• Оптимизация кэширования сред глобальной сети

В этой статье обсуждаются отдельные способы оптимизации решения Microsoft Office SharePoint Server 2007 для лучшей производительности в широкомасштабных сетевых средах (глобальная сеть).

Создание топологий глобальной сети

Серверные роли в ферме Office SharePoint Server 2007 поддерживают гибкую настройку, которая позволяет оптимизировать производительность и доступность соответственно требованиям. В среде глобальной сети существует несколько технических характеристик ролей серверов, которые важно понимать. Дополнительно к требованиям к общей производительности и доступности, знание этих характеристик может помочь оптимизировать топологию фермы серверов и сред глобальной сети.

Оптимизация топологии для обхода контента

По умолчанию Office SharePoint Server 2007 использует все веб-серверы для обхода контента в ферме серверов. Если настройка фермы указывает использование всех веб-серверов для обхода, сервер индекса отправляет запросы на каждый веб-сервер в ферме.

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

В средах глобальной сети для обхода контента рекомендуется настраивать отдельный веб-сервер, особенно если сервер содержит больше 500 ГБ контента для обхода или обход контента выполняется по глобальной сети. Чтобы обход контента не влиял на запросы пользователей, удалите выделенный веб-сервер из ротации балансировки сетевой нагрузки. Это особенно важно в глобальных средах, в которых часы наименьшей нагрузки региональной фермы — как предполагается при планировании заданий обхода — совпадают с часами пиковой нагрузки центральной фермы.

Конфигурация выделенного веб-севера для обхода локального контента

Для лучшей производительности при обходе контента локальной фермы, настройте сервер индексирования как выделенный веб-сервер для обхода контента, если сервер индексирования имеет достаточно памяти для обеих ролей.

На следующем рисунке показана ферма, оптимизированная с помощью выделенного веб-сервера для индексации контента.

При использовании одного сервера как сервера индексирования и веб-сервера отпадает необходимость отправлять запросы с сервера индексирования на другой сервер при обходе контента. Следовательно, повышается производительность и снижается общий объем трафика в сети. Если такая конфигурация невозможна, можно использовать другой сервер в ферме.

Настроить индекс для использования выделенного веб-сервера можно с помощью одного из следующих подходов.

• Настроить службу поиска Office SharePoint Server в центре администрирования SharePoint.

• Внести изменения непосредственно в файл "Hosts".

Дополнительные сведения см. на следующих ресурсах:

• Настройка выделенного интерфейсного веб-сервера для обхода содержимого (Office SharePoint Server 2007)..

• Настройка выделенного интерфейсного веб-сервера для обхода содержимого при помощи пользовательского интерфейса (Office SharePoint Server 2007).

• Настройка отдельного интерфейсного веб-сервера для обхода посредством прямого изменения файла узлов (Office SharePoint Server 2007)

Конфигурация выделенного веб-сервера для обхода удаленных ферм

Для лучшей производительности региональных ферм при обходе их контента настройте сервер индексирования в центральной ферме для использования выделенного веб-сервера в региональной ферме.

На следующем рисунке показаны две региональные фермы, каждая из которых оптимизирована с помощью выделенного веб-сервера для индексации контента.

• В региональной ферме 1 один сервер выделен для роли веб-сервера. И центральная, и региональная ферма 1 используют этот выделенный веб-сервер для обхода контента.

• Подобным образом настроена региональная ферма 2, так как центральная ферма с ролью веб-сервера также развернута на сервер индекса.

Обратите внимание, что сервер индекса в центральной ферме не использует роль веб-сервера в центральной ферме для обхода контента в удаленной ферме. Сервер индекса напрямую контактирует с веб-серверами в удаленных фермах.

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

• Локальная производительность обхода в региональной ферме 1 улучшается, так как выделенный веб-сервер находится на отдельном сервере. Следовательно, центральная ферма не влияет на производительность сервера индекса.

• Улучшается время обхода по глобальной сети. Обход занимает меньше времени, так как выделенный веб-сервер в региональной ферме откликается быстрее, чем если бы он находился на одном сервере с сервером индекса.

• Процесс обхода центральной фермы улучшается, так как сервер индекса в центральной ферме соединен с выделенным веб-сервером.

При реализации конфигурации топологии, показанной с региональной фермой 2, можно оптимизировать производительность, назначив процессы обхода в двух фермах таким образом, чтобы они не перекрывались.

Чтобы использовать выделенный веб-сервер в удаленной ферме для обхода контента, необходимо внести изменения в файл "Hosts". Убедитесь, что изменения вносятся файле "Hosts", находящемся в ферме, которая обходит контент, а не в удаленной ферме.

В глобальном решении, в котором центральная ферма обходит контент в региональных фермах, Включите в файле "Hosts" запись для каждого веб-приложения в каждой региональной ферме обхода. Запись в файле "Hosts" содержит IP-адрес выделенного веб-сервера и имя веб-приложения. Пример:

• 10.10.10.4 TeamSites

• 10.10.10.4 MySites

• 10.10.10.4 Marketing

• 10.10.10.4 Sales

Дополнительные сведения см. в разделе Настройка отдельного интерфейсного веб-сервера для обхода посредством прямого изменения файла узлов (Office SharePoint Server 2007).

Оптимизация производительности запросов

Производительность запросов пользователей является основным вопросом при развертывании приложения Office SharePoint Server 2007 среде глобальной сети. Когда пользователь создает запрос, он пересылается на веб-сервер. Веб-сервер связывается с сервером запросов, чтобы создать список результатов, и затем связывается с компьютером, на котором выполняется Microsoft SQL Server, чтобы дополнить список результатов текстом сводки, URL-адресами и фильтрацией по ролям безопасности.

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

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

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

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

Дополнительно к оптимизации производительности запросов в одной ферме существуют варианты оптимизации для сценариев с несколькими фермами.

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

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

  • Разверните роль веб-сервера на сервер индекса во всех фермах. Удалите этот сервер из ротации сетевой балансировки нагрузки и настройте процесс обхода родительской фермы таким образом, чтобы для обхода контента использовался этот выделенный веб-сервер.

  • Разверните сервер запросов на все веб-серверы с балансировкой нагрузки в каждой ферме.

Разделение серверов фермы по географическому принципу

Чтобы обеспечить нужный уровень обслуживания запросов пользователей и избежать "узких мест" производительности, для связи между серверами фермы требуются надежные подключения. Стандартное требование к сети — все серверы в ферме находятся в одном центре данных в одной локальной сети. Разделение серверов фермы по каналам глобальной сети не поддерживается.

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

Этот сценарий развертывания отвечает предварительно поддерживаемым требованиям при следующих условиях.

• Сетевые каналы между веб-сервером и сервером базы данных имеют задержку меньше 1 миллисекунды (мс). Чтобы получить такую задержку, в идеале веб-серверы должны располагаться на расстоянии 16 или меньше километров от сервера базы данных. В большинстве оптимальных сетевых конфигураций задержку менее 1 мс можно достичь на расстоянии до 160 километров, хотя это бывает редко. Если расстояние составляет от 16 до 160 километров, проконсультируйтесь с поставщиками сети и оборудования, чтобы определить, могут ли они обеспечить уровень обслуживания с задержкой менее 1 мс. Разделение серверов фермы на расстояние больше 160 километров не поддерживается. При измерении задержки между двумя центрами обработки данных, в которых находятся серверы одной и той же фермы, используйте инструмент Ping, измеряя при этом задержку сигнала от веб-сервера в удаленном центре обработки данных до сервера базы данных в основном центре обработки данных. Результат приемо-передачи следует поделить на два.

• Канал поддерживает достаточную доступную полосу пропускания для обработки трафика между веб-сервером и другими серверами в ферме.

• Все роли серверов, участвующие в общих службах, расположены в одном центре данных, например, на сервере базы данных. Сюда входят роли индекса, запросов и служб Excel.

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

• Если тип нагрузки, обслуживаемой веб-сервером, является некоторым поднабором запросов браузера пользователя, ожидается, что Office SharePoint Server 2007 допускает некоторую задержку между веб-сервером и сервером базы данных, однако для страниц с несколькими или настраиваемыми веб-частями, команд Stsadm и обходов поиска это, вероятно, относится в меньшей степени.

• Серверы фермы находятся в одном часовом поясе. Все компьютеры в ферме серверов должны быть синхронизированы для одного часового пояса.

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

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

• Распределение обхода источников контента.

• Настройка частоты обхода и распределение полного и добавочного обхода.

• Настройка параметров обхода.

Распределение обхода источников контента

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

Добавьте источник контента поиска при следующих условиях.

• Требуется обход разных типов репозиториев.

• График обхода некоторых репозиториев отличается от других.

• Требуется ограничить или увеличить объем контента обхода.

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

Дополнительно, создайте разные источники контента для отдельной региональной фермы на основе следующих критериев.

• Создайте отдельные источники контента, обход которого будет выполняться чаще (например, контент совместной работы) или реже (например, опубликованный контент).

• Создайте отельный источник контента, публикуемого через определенные промежутки времени. Например, если известно, что контент отдельного набора сайтов обновляется только по пятницам, можно создать отдельный источник контента для синхронизации графиков обхода с обновлениями контента.

• Создайте отдельные источники контента на основе его объема, который пользователи могут обходить по каналам глобальной сети во время спада активности в региональной ферме. Например, если обход большого репозитория выполняется один раз в неделю, его можно разделить на 5-7 фрагментов контента, которое можно успешно обходить в ночное время, и затем разнесите задания обхода по направлению каждой недели.

• Создайте отдельный внешний по отношению к сайтам Office SharePoint Server 2007 источник контента. В приложении Office SharePoint Server 2007 и Windows SharePoint Services 3.0 журнал изменений регистрирует измененные объекты, включая обновления в списках контроля доступа (ACL). Журнал изменений предоставляет возможность добавочного обходить только измененный контент, значительно сокращая время, требуемое для повторного обхода источника. Добавочный обход контента, сохраненного во внешних источниках, не поддерживается. Поэтому процесс обхода этих источников контента следует выполнять отдельно. Дополнительные сведения см. в статье Журнал изменений (https://go.microsoft.com/fwlink/?linkid=106007&clcid=0x419).

Дополнительные сведения о планировании обхода и источников контента см. в разделе Планирование обхода содержимого (Office SharePoint Server).

Настройка частоты обхода и распределение полного и добавочного обхода

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

• Время запланированного простоя и периоды высокой активности в региональной ферме.

• Частота изменения и обновления контента.

• Доступная полоса пропускания и задержка в канале глобальной сети. Обязательно примите во внимание другие процессы, использующие канал глобальной сети.

Для каждого источника контента в приложениях Office SharePoint Server 2007 и Windows SharePoint Services 3.0 можно указать время для полного обхода и отдельное время для добавочных обходов. Обратите внимание, что перед запуском добавочного обхода необходимо выполнить полный обход отдельного источника контента. Если выбран добавочный обход контента, обход которого еще не выполнен, система выполнит полный обход.

При планировании графиков обхода глобальной сети учтите следующие рекомендации.

• Разнесите графики обхода таким образом, чтобы использование каналов глобальной сети было распределено по времени и они не переполнялись.

• Планируйте график полных обходов только при необходимости. Рекомендуется выполнять полные обходы реже, чем добавочные.

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

• Для некоторых административных изменений в приложениях Office SharePoint Server 2007 и Windows SharePoint Services 3.0, таких как применение пакета обновления или восстановление базы данных, необходимо выполнить полный обход. Планируйте административные изменения, требующие полного обхода, непосредственно перед плановыми полными обходами. Например, попробуйте внести в график создание правила обхода перед следующим запланированным полным обходом, чтобы дополнительный полный обход не требовался. Дополнительные сведения об административных изменениях, требующих полного обхода, см. в разделе Планирование обхода содержимого (Office SharePoint Server)

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

Дополнительные сведения о планировании обхода и источников контента см. в разделе Планирование обхода содержимого (Office SharePoint Server).

Настройка параметров обхода

Можно оптимизировать несколько отдельных параметров обхода для среды глобальной сети, чтобы повысить надежность заданий обхода. Доступны следующие параметры:

• Параметры таймаута поиска

• Правила воздействия программы-обходчика

Параметры таймаута поиска

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

Чтобы указать параметры таймаута для службы поиска Office SharePoint Server, используйте следующую процедуру.

Определение параметров таймаута

1. В центре администрирования на вкладке Управление приложениями в разделе Поиск выберите Управление службой поиска.

2. На странице "Управление службой поиска" в разделе Параметры поиска на уровне фермы выберите Параметры поиска на уровне фермы.

3. На странице "Управление параметрами поиска на уровне фермы" в разделе Параметры таймаута выполните следующие действия.

   • В поле Время подключения (в секундах) введите количество секунд, в течение которых сервер будет ожидать подключения к другим службам.

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

4. Нажмите кнопку ОК.

Правила воздействия программы-обходчика

Правила воздействия программы-обходчика предоставляют способ управления числом документов, для которых одновременно выполняется запрос и обход. Правила воздействия программы-обходчика позволяют администраторам управлять влиянием заданий обхода в каналах глобальной сети.

Для каждого правила воздействия обходчика можно указать один URL-адрес или использовать подстановочные знаки в URL-адресе, чтобы включить блок URL-адресов, к которым применяется правило. Затем можно указать, сколько будет выполняться одновременных запросов страниц определенного URL-адреса, или определить одновременный запрос только одного документа и выбрать время ожидания в секундах между запросами.

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

Чтобы добавить правило воздействия программы-обходчика, выполните следующую процедуру.

Добавление правила воздействия программы-обходчика

1. В центре администрирования на вкладке Управление приложениями в разделе Поиск выберите Управление службой поиска.

2. На странице "Управление службой поиска" в разделе Управление параметрами поиска на уровне фермы выберите Правила воздействия программы-обходчика.

3. На странице "Правила воздействия программы-обходчика" выберите Добавить правило.

4. На странице "Добавление правила воздействия программы-обходчика" в разделе Сайт в поле Сайт ведите имя сайта, который будет связан с этим правилом воздействия программы-обходчика.

   Примечание

   При вводе URL-адреса необходимо исключить протокол. Например, не следует включать "http://" или "file://".

5. В разделе Частота запросов выберите один из следующих параметров.

   • Запрашивать одновременно не более указанного числа документов без ожидания между запросами. Если выбран этот параметр, используйте список Одновременные запросы, чтобы указать количество документов для одновременного запроса программой-обходчиком при обходе этого URL-адреса. Можно указать максимальное число запросов, которое может отправить служба поиска Office SharePoint Services одновременно при обходе этого URL-адреса.

   • Запрашивать по одному документу и ожидать заданное время между запросами. Можно назначить перерыв (в секундах) между запросами для обхода этого URL-адреса. Если выбран этот параметр, служба поиска Office SharePoint Server выполняет одновременно один запрос на сайт, после чего ожидает указанное время перед отправкой следующего запроса. В поле Время ожидания (в секундах) введите время ожидания в секундах между запросами. Минимальное время ожидания между запросами — одна секунда, максимальное — 1 000 секунд.

6. Нажмите кнопку ОК.

Дополнительные сведения о правилах воздействия программы-обходчика см. в следующих статьях:

• Управление воздействием программы-обходчика (Office SharePoint Server 2007).

• "Правила воздействия программы-обходчика" в разделе Расчет требований к производительности и ресурсам для сред поиска.

Ускорители глобальной сети и другие средства

В этом разделе описываются параметры оптимизации сред глобальной сети с решениями сторонних производителей в следующих категориях:

• Ускорители глобальной сети

• Устройства кэширования и разгрузки

• Клиентские решения

• Репликация данных, синхронизация с несколькими хозяевами и управление конфигурацией

• Отчеты и управляемость нескольких ферм

• Репликация аппаратная или на уровне байтов

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

Существует множество партнера, предлагающих пути расширения и оптимизации решений Office SharePoint Server 2007. Обновляемые списки партнеров см. в каталоге Каталог решений системы Microsoft Office (на английском языке) (https://go.microsoft.com/fwlink/?linkid=108591&clcid=0x419) (на английском языке).

Ускорители глобальной сети

Решения по ускорению глобальной сети разрабатываются уже долгое время. Алгоритмы самых коротких путей и средства сжатия пакетов предлагаются в течение нескольких десятилетий. Самые крупные инновационные разработки по оптимизации в последние годы касаются стека TCP/IP и блока сообщений сервера (SMB).

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

Решение по выбору ускорителя сети включает следующие два важных критерия.

• Требования безопасности организации. На выбор влияют такие требования, как протоколы IPsec или HTTPS.

• Приложения, используемые в организации. Если будет использоваться устройство, которое также обеспечивает оптимизацию Microsoft Exchange Server и трафика общих ресурсов, это также повлияет на выбор.

Примеры включают следующие решения: Cisco, Citrix, Packeteer, Riverbed и F5.

Устройства кэширования и разгрузки

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

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

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

Также как и Microsoft ISA, некоторые решения обеспечивают разгруженную или делегированную проверку подлинности в качестве шлюза доступа к данным. Эти решения добавляют дополнительный уровень безопасности. Если нужно соответствие нескольким требованиям, ищите продукты или решения, предоставляющие брандмауэр, балансировку нагрузки и некоторые операции разгрузки и кэширования. В дальнейшем можно ожидать объединение этих типов компонентов.

Примеры включают следующие решения: Cisco, F5, Inktomi, Microsoft ISA Server и Microsoft Internet Application Gateway.

Клиентские решения

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

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

Некоторые клиенты обрабатывают эти операции лучше, чем другие. Некоторые — обеспечивают только поддержку файлов. Другие клиенты поддерживают и списки, и файлы. Вероятно, в автономном режиме не удастся найти вики-сайты, но можно найти программы чтения RSS-каналов для доступа к большинству списков локально или автономно. Office Outlook 2007 представляет пример клиента, который позволяет получать блоги или списки SharePoint в автономном режиме с помощью программы чтения RSS-каналов, а также синхронизировать библиотеки. Office Groove 2007 также предоставляет хорошие возможности автономного режима, в том числе — возможность совместной работы в одноранговых сетях и сжатия файлов в глобальной сети. Дополнительные сведения о клиентских решениях Майкрософт см. в разделе Расширение глобальных решений Office SharePoint Server с использованием программного обеспечения Office Outlook 2007 и Office Groove.

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

Партнеры: Colligo. Майкрософт: Microsoft Office Outlook 2007, Office Groove 2007

Репликация данных, синхронизация с несколькими хозяевами и управление конфигурацией

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

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

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

Имеются следующие решения партнеров: Syntergy, WinApp Technologies, Casahl и Infonic.

Отчеты и управляемость нескольких ферм

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

Некоторые партнеры фокусируют внимание на том, чтобы помочь пользователям в настройке параметров ферм и нескольких сред. В статье Межсайтовой конфигуратор SharePoint (на английском языке) (https://go.microsoft.com/fwlink/?linkid=108592&clcid=0x419) (на английском языке) обсуждается пример средства, созданного корпорацией Майкрософт для настройки аудита, срока действия, главных страниц и типов контента для согласованности веб-приложений.

Имеются следующие решения партнеров: Quest Software, echoTechnologies, IDevFactory, AvePoint, CorasWorks, Barracuda Tools, CommVault и Symantec.

Репликация аппаратная или на уровне байтов

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

Если нужно устранить потенциальные сбои оборудования, попробуйте применить службы кластеров Microsoft (MSCS). Службы MSCS обеспечивают аппаратную отказоустойчивость. Программные решения отказоустойчивости, такие как доставка журналов SQL и зеркальное отображение SQL, обеспечивают аппаратную отказоустойчивость, однако эта возможность не работает в автоматическом режиме при использовании с продуктами и технологиями SharePoint.

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

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

Имеются следующие решения партнеров: Neverfail и Double-take.

Имеются следующие встроенные в аппаратные средства решения, такие как репликация на базе SAN: HP, EMC Centera и Hitachi Data Systems.

Создание страниц быстрой загрузки

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

Элементы страниц

Страница сайта SharePoint состоит из нескольких уникальных элементов, как показано на следующем рисунке.

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

URL-адрес	Размер (байт)
http://myServer/_layouts/images/topnavhover.gif	96
http://myServer/Pages/Default.aspx	1656
http://myServer/Pages/Default.aspx	1539
http://myServer/Pages/Default.aspx	66084
http://myServer/_layouts/1033/styles/controls.css?rev=EhwiQKSLiI%2F4dGDs6DyUdQ%3D%3D	1448
http://myServer/_layouts/1033/styles/HtmlEditorCustomStyles.css?rev=8SKxtNx33FmoDhbbfB27UA%3D%3D	642
http://myServer/_layouts/1033/styles/HtmlEditorTableFormats.css?rev=guYGdUBUxQit03E2jhSdvA%3D%3D	1317
http://myServer/_layouts/1033/styles/core.css?rev=5msmprmeONfN6lJ3wtbAlA%3D%3D	13596
http://myServer/_layouts/1033/init.js?rev=VhAxGc3rkK79RM90tibDzw%3D%3D	15732
http://myServer/_layouts/1033/core.js?rev=F8pbQQxa4zefcW%2BW9E5g8w%3D%3D	54367
http://myServer/_layouts/portal.js?rev=INhSs9mWTnUTqdwwIXYMaQ%3D%3D	954
http://myServer/_layouts/1033/ie55up.js?rev=Ni7%2Fj2ZV%2FzCvd09XYSSWvA%3D%3D	20508
http://myServer/_layouts/1033/search.js?rev=yqBjpvg%2Foi3KG5XVf%2FStmA%3D%3D	5092
http://myServer/_layouts/1033/EditingMenu.js?rev=eh0f0CwzvHQ7Ii0JvdsIjQ%3D%3D	2735
http://myServer/WebResource.axd?d=__WrA1TRLicJgwGEmYKqSA2&t=633214754549731034	5383
http://myServer/WebResource.axd?d=h_u9v0Coj_eDqsvEkDrdtw2&t=633214754549731034	8258
http://myServer/_layouts/images/blank.gif	43
http://myServer/_layouts/images/helpicon.gif	1025
http://myServer/_layouts/images/Menu1.gif	68
http://myServer/_layouts/images/titlegraphic.gif	1299
http://myServer/_layouts/images/gosearch.gif	19933
http://myServer/WebResource.axd?d=puevA5kEAx44yxozBd-hspPZ9eA51Rh9u95VwVGLFCc1&t=633214754549731034	224
http://myServer/WebResource.axd?d=wyTuS1folQ6wX2Tc_7NOOaeElHHqL6rtdeAeRRUR36s1&t=633214754549731034	218
http://myServer/_layouts/images/whitearrow.gif	68
http://myServer/_layouts/images/recycbin.gif	1004
http://myServer/PublishingImages/newsarticleimage.jpg	10710
http://myServer/_layouts/images/icongo01.gif	1171
http://myServer/_layouts/images/menudark.gif	68
http://myServer/_layouts/images/topnavhover.gif	96

Обратите внимание на следующее.

• Для загрузки страницы всего было обработано 29 запросов.

• Общий размер страницы составил 235 КБ.

• Эти характеристики представляют первую загрузку страницы; почти все элементы в запросе содержат кэшированную директиву, указывающую браузеру не загружать их снова в течение года. Загрузка второй и последующей страницы создает только три запроса. Из них два являются частью согласования NTLM, поэтому фактически загружен только один элемент — HTML-код для страницы.

• По умолчанию используется наименьшее возможное сжатие IIS уровня 0. Дополнительное сжатие приведет к еще меньшему размеру загрузки.

• Загружены следующие типы файлов:

  • 4 запроса ресурсов AXD

  • 4 запроса ресурсов CSS

  • 12 запросов ресурсов изображений

  • 6 запросов ресурсов JS (некоторые из которых были копиями)

  • 3 запроса ресурсов страниц для файла default.aspx (два из которых являются частью согласования NTLM)

Большинство этих типов файлов очевидны, за исключением, возможно, типа ресурса AXD. Ресурс AXD является частью новой возможности в компоненте ASP.NET версии 2.0. Разработчик может добавить ресурс, такой как файл сценария или таблицу стилей, к элементу управления. В элементе управления разработчик использует класс ClientScript, чтобы включить метод, называемый GetWebResourceUrl. Когда элемент управления представлен в среде выполнения, он динамически генерирует URL-адрес для этого ресурса. Ресурс самостоятельно компилируется в сборку элемента управления, поэтому этот метод представляет способ направить ресурс из сборки в клиент так, как если бы на веб-сервере размещался отдельный файл.

Знание запросов ресурсов, используемых страницей, помогает понять, где и как применить оптимизации. Такого рода информацию можно получить с помощью различных средств и технологий. В этой статье использовалась бесплатная программа, называемая Fiddler (на английском языке). Fiddler можно запустить в клиентской рабочей станции и отслеживать все HTTP-запросы, созданные для страницы. Результаты отображаются в таблице, как показано на следующем рисунке.

Если выбран сайт для оптимизации, протестируйте его с помощью программы Fiddler. Чтобы лучше понять, какие элементы запрашиваются, какие кэшируются и какого размера, выполните следующие действия.

1. Удалите все временные файлы браузера.

2. Запустите Fiddler.

3. Запросите страницу.

   Примечание

   Обязательно запросите страницу, щелкнув ссылку. Если только нажать кнопку "Обновить", система автоматически повторно запрашивает элементы и не отражает в точности выполненные изменения оптимизации.

Оптимизация загрузок страниц

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

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

Кэш BLOB

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

Сжатие IIS

Сжатие IIS также обсуждается более подробно в разделе этого документа Оптимизация кэширования сред глобальной сети. Однако как было замечено ранее, настройки по умолчанию используют сжатие уровня 0. Следует попробовать настройки разных уровней сжатия, чтобы найти такой уровень, который оптимизирует сжатие одновременно с минимальным влиянием на ЦП веб-серверов. Практически во всех случаях можно использовать сжатие с уровнем выше 0. Однако важно помнить, что уровень сжатия применяется только к динамическим файлам, таким как AXD и ASPX.

64-разрядное оборудование

На задержку запросов влияет также выбор оборудования в ферме. 32-разрядные системы имеют ограничение оперативной памяти до 2 ГБ на одно приложение. Хотя можно расширить оперативную память приложений до 3 ГБ, продукты и технологии SharePoint не поддерживают использование параметра /3GB. Небольшой объем памяти может отрицательно влиять на задержку запросов в следующих ситуациях.

• Ограничение памяти может вызвать повторный запуск пула приложений SharePoint. Это повлечет также повторный запуск домена приложений ASP.NET, в результате чего возникнет большая задержка отклика на запросы пользователей.

• Ошибки нехватки памяти могут вызвать остановку обслуживания контента кэшем BLOB.

Применение 64-разрядного оборудования гарантирует размещение и использование достаточного количества оперативной памяти, чтобы предупредить эти ошибки.

Параметры веб-сада

Параметры веб-сада также могут непреднамеренно вызвать неустойчивую работу кэша BLOB. Так как только один процесс может получить блокировку, необходимую для управления кэшем, успешное использование кэша зависит от того, какой поток обслуживает запрос. Если запрос обслуживается веб-садом, не имеющим блокировки кэша BLOB, контент, отправляемый в ответ, не имеет связанных с ним директив кэширования. В результате, увеличивается число запросов и объем данных, передаваемых по сети. Поэтому если планируется применить кэш BLOB, не следует использовать веб-сады.

Снижение числа защищенных элементов на странице

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

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

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

Снижение числа и размера изображений

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

На следующем рисунке показано последовательное изменение этого изображения для отображения как отдельного изображения в таблице.

Работа с изображениями была выполнена во всех классах таблицы стилей. В элементах div и img в каждой ячейке таблицы использованы следующие два основных класса:

.cluster {

   height:50px;

   position:relative;

   width:50px;

}

.cluster img {

   position:absolute;

}

Каждое изображение имеет класс, связанный с ним с помощью идентификатора изображения. Этот стиль создает клип изображения и определяет смещение от исходного изображения в кластере. Представлены следующие классы:

#person {

   border:none;

   clip:rect(0, 49, 49, 0);

}

#keys {

   clip:rect(0, 99, 49, 50);

   left:-50px;

}

#people {

   clip: rect(0, 149, 49, 100);

   left:-100px;

}

#lock {

   clip:rect(0, 199, 49, 150);

   left:-150px;

}

#phone {

   clip:rect(0,249, 49, 200);

   left:-200px;

}

#question {

   clip:rect(0, 299, 49, 250);

   left:-250px;

}

HTML-код таблицы включает теги div и img со следующими соответствующими значениями идентификаторов и именами классов:

<table border="1">

   <tr>

      <td><div class="cluster"><img id="person" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="keys" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="people" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

   <tr>

      <td><div class="cluster"><img id="lock" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="phone" src="Icons50x50.gif" width="300" height="50"/></div></td>

      <td><div class="cluster"><img id="question" src="Icons50x50.gif" width="300" height="50"/></div></td>

   </tr>

</table>

Эта технология сейчас используется в нескольких веб-свойствах и продуктах корпорации Майкрософт, включая Microsoft Passport Network и Microsoft Office Outlook Web Access (OWA). Группа MSN провела несколько тестов, чтобы проанализировать влияние этих изменений, и определила, что время загрузки первой страницы улучшилось на 50-75%.

При создании страниц в приложении Microsoft Office SharePoint Designer 2007 важно учитывать один момент. Когда в Office SharePoint Designer 2007 создается новая страница, к ней добавляется следующая разметка схемы XHTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

It then adds this namespace to the HTML element:

<html xmlns="http://www.w3.org/1999/xhtml">

Если используется эта схема, изображения будут выравниваться неправильно. Чтобы изображения отображались, как запланировано, необходимо удалить атрибут xmlns из тега HTML.

Задержка загрузки файла core.js

Основной файл сценария клиента, включенный в приложение Office SharePoint Server 2007, называется core.js. Это самый большой файл с размером около 257 КБ в несжатом виде и около 54 КБ — в сжатом. В некоторых ситуациях можно отложить загрузку файла core.js. В этом случае страница отображается быстрее, так как файл core.js начнет загружаться только после того, как страница откроется в браузере. Это позволяет быстрее просмотреть страницу и начать чтение контента. Такая технология наиболее полезна в Интернет-сценариях с анонимными пользователями. И наоборот, пользователям, прошедшим проверку подлинности, во время загрузки страницы требуется файл core.js для поддержки таких функциональных возможностей, как элементы интерфейса пользователя или меню Действия сайта.

Для реализации этой технологии можно использовать следующие шаги.

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

   Примечание

   По умолчанию указан тип контента начальной страницы сайта портала совместной работы.

2. Добавьте к странице следующий тег: <SharePointWebControls:ScriptLink runat="server"/>. Он указывает системе не использовать файл core.js, пока на него не будет дана ссылка.

3. Создайте настраиваемый элемент управления для установления пользователей, прошедших проверку подлинности. Элемент управления должен быть простым и, главным образом, содержать следующий код (показан в коде C#):

   if (HttpContext.Current.Request.IsAuthenticated)   
       Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(this.Page, true);
   

4. На всех веб-серверах поместите элемент управления в глобальный кэш сборок (GAC) и затем добавьте для него запись SafeControl в файле Web.config веб-приложения, в котором он будет использоваться.

5. Добавьте настраиваемый элемент управления к настраиваемой странице макета, созданной на шаге 1.

6. Добавьте элемент IFRAME к странице макета. Он должен ссылаться на страницу со следующим контентом:

   <body>
   <SharePoint:ScriptLink name="core.js" runat="server" />
   <script language="javascript">
    DisableRefreshOnFocus();
   </script>
   </body>
   

7. Проверьте настраиваемую страницу макета и опубликуйте ее.

8. Разместите домашнюю страницу сайта на новой странице макета.

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

Дополнительно, перед развертыванием этой технологии, рассмотрите следующие вопросы.

• Главная страница сайта и главная системная страница должны отличаться; иначе все страницы in _layouts не будут работать.

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

• Убедитесь, что главная страница не содержит элементов управления ScriptLink, которые загружают файл core.js или ссылаются на него.

Дополнительные подробности и примеры кодов см. в статье Блог группы Microsoft Enterprise Content Management (ECM) (на английском языке) (https://go.microsoft.com/fwlink/?linkid=106008&clcid=0x419).

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

Группа служб Майкрософт провела работу по количественной оценке и улучшению времени отображения страниц представления списков. Страница представления списка — это страница AllItems.aspx, которая используется каждым списком и библиотекой, чтобы разрешить переход к контенту. Время отображения этой страницы может значительно отличаться, в зависимости от числа отображаемых в представлении столбцов и их формата. Например, отображение вариантов и включение значков присутствия может значительно повлиять на время отображения. Свернутые группы отображаются значительно дольше, чем развернутые, и те и другие отображаются медленнее, чем отображение вовсе без группирования.

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

• Отображение меньшего числа столбцов.

• Исключение столбцов, отображающих сведения о присутствии.

• Использование ссылки (но без меню правки) для просмотра сведений для элемента.

В следующей таблице описываются настройки, которые сокращают время, необходимое для отображения представления.

Элемент	Описание
Тип представления	Создайте представление как таблицу вместо стандартного представления.
Представление: "Максимальное число элементов"	Значение больше 1 000, скорей всего, приведет к более медленному отображению. Для медленных соединений важно опытным путем найти правильный баланс между количеством одновременно отображаемых данных и числом циклов, необходимый для отображения всех данных. Больше одновременно отображаемых строк, меньше циклов, но страницы большего масштаба.
Представление: "Фильтр"	Используйте фильтры [Today] и [Me], чтобы отфильтровать элементы по обновлению или назначению. Используйте поля "Состояние", чтобы отобразить только активные элементы в представлениях по умолчанию.
Представление: "Столбцы"	Используйте необходимое число столбцов. Создайте представление по умолчанию с небольшим числом столбцов, позволяющим высокоуровневый просмотр, после которого пользователи могут просматривать детали.

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

Элемент	Описание
Группировать по	Группирование добавляет код HTML и сценарий JScript, замедляя отображение больших списков. Свернутые группы по умолчанию, в действительности, затем увеличивают время отображения из-за дополнительных операций в объектной модели браузера.
Столбец — "заголовок, связанный с элементом меню правки"	Параметр "связанный с пунктом меню правки" более длинен; такой же параметр "связанный с элементом" не увеличивает заметно время отображения.
Столбец — "Поиск пользователя с присутствием"	При добавлении поля поиска пользователя с присутствием добавляется HTML-код для каждой ссылки для открытия меню присутствия. Кроме того, также используется полоса пропускания для определения доступности присутствия.

В следующей таблице описываются настройки, которые имеют относительно небольшие влияние на время, требуемое для отображения представления.

Элемент	Описание
Сортировка, итоги	Применение нескольких сортировок и приведение итогов заметно увеличивает время отображения, но первое занимает меньше времени, чем второе, для списков из 1 000 элементов.

Оптимизация кэширования для сред глобальной сети

В приложении Office SharePoint Server 2007 поддерживаются несколько параметров кэширования. Часть из них предназначена для улучшения производительности в канале отображения — от начала запроса, полученного на сервере, до начала отклика, запускающего обратный поток на клиентский компьютер. Хотя это важный аспект производительности сайта в целом, в этом разделе внимание будет уделено кэшированию, связанному со следующими процессами.

• Роль конфигурации сервера в клиентском кэшировании.

• Управление размером элементов, передаваемых по сети с сервера в клиент.

Кэш BLOB

Кэш BLOB — это механизм, доступный только со средствами публикации Office SharePoint Server 2007. Это делает его идеальным кандидатом для корпоративных сайтов портала, основанных на шаблоне сайта портала совместной работы, и корпоративных веб-сайтов в Интернете, основанных на шаблоне сайта портала публикаций. Кэш BLOB позволяет настраивать директивы кэширования, связанные элементами, обслуживаемыми из списков сайтов публикаций, например, библиотеки страниц или изображений семейства сайтов. Когда браузер в клиентском компьютере встречает директиву кэширования, он обнаруживает, что полученный из кэша элемент может быть сохранен локально, и его больше не требуется запрашивать, пока не закончится срок действия директивы кэширования. В географически распределенной среде это очень важно, так как снижается число элементов, запрашиваемых и отправляемых по сети.

Когда в приложении Office SharePoint Server 2007 включен кэш BLOB, выполняются две разные операции. Во-первых, каждый раз при запросе кэшируемого элемента приложение Office SharePoint Server 2007 выполняет поиск жесткого диска веб-сервера, который получил запрос, чтобы определить, существует ли локальная копия. Если копия существует, файл направляется прямо с локального диска пользователю. Если файла еще нет на локальном диске, копия элемента создается из базы данных SQL, где он хранится, и затем элемент отправляется пользователю, сделавшему запрос. После этого все запросы данного элемента могут обслуживаться напрямую с веб-сервера, пока значение кэширования элемента не покажет, что время его действия закончилось. В результате, улучшается производительность в ферме серверов из-за сокращения состязаний на сервере базы данных.

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

При тестировании сайта, чтобы определить, какие элементы и каким образом будут кэшироваться, можно использовать статью Fiddler (на английском языке) (http://www.fiddler2.com/fiddler2/) . На следующем рисунке показан моментальный снимок приложения Fiddler в простом сайте SharePoint, который используется для публикации. Сайт был создан с помощью шаблона сайта портала совместной работы по умолчанию. На страницу было добавлено текстовое содержимое, и на главную страницу были добавлены несколько изображений.

Приложение Fiddler содержит несколько важных данных.

• Столбец "#" в левой части указывает, что для отображения страницы из браузера на сервер всего поступило 44 HTTP-запроса.

• Столбец "Result" указывает код результата HTTP, который был возвращен из запроса элемента; результат 200 означает, что элемент был успешно извлечен.

• Столбец "URL" указывает, какой отдельный элемент был запрошен.

• Столбец "Body" указывает размер каждого элемента.

• В столбце "Caching" отображена директива кэширования, которая была связана с каждым элементом. Данные в столбце "Caching" указывают, что несколько элементов имеют директиву кэширования, связанную с элементом; то есть они содержат атрибут максимального возраста больше 0. Директивы кэширования выражаются в секундах. Это означает, что для страницы, отображающей несколько элементов, задано кэширование в течение 365 дней (60 секунд в минуте, 60 минут в часе, 24 часа в сутках = 60x60x24 = 86 400x365 = 31 536 000).

Обратите внимание, что все элементы с этой директивой кэширования находятся в каталоге _layouts. Причина, по которой они имеют этот параметр кэша, заключается в том, что путь виртуального каталога _layouts/images был настроен в службе IIS. При создании нового веб-приложения Office SharePoint Server 2007 автоматически создает несколько виртуальных каталогов, сопоставленных с папками на физических дисках веб-сервера. Когда создается виртуальный каталог _layouts/images, добавляется директива кэширования, которая применяется ко всему каталогу. На следующем моментальном снимке показана конфигурация каталога в оснастке "Диспетчер IIS".

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

Как показывают данные в приложении Fiddler, число запрошенных элементов значительно снизилось — с 44 до 11. Важно отметить, что число запросов во многом может зависеть от способа запроса страницы. Если используется кнопка "Обновить" в браузере, скорей всего, все элементы будут запрошены снова, независимо от того, существует локальная кэшированная версия элемента или нет. И наоборот, если страница запрошена путем перехода к ней с помощью ссылки или ярлыка, запрашиваются только некэшированные элементы.

Также данные приложения Fiddler показывают, что браузер запрашивает с сервера другие изображения на главной странице, которые уже имеются в его локальном кэше; на это указывает код отклика 304. Это означает, что браузер выполняет условный запрос элемента. Отклик 304 указывает, что версия на сервере не была изменена соответственно версии в клиенте, поэтому элемент не требуется загружать повторно. Даже если файл не был загружен по сети, на сервер все равно генерируется обратный сигнал, чтобы определить, что локальная копия не устарела. В географически разнесенной среде обратный сигнал сервера удорожает связь, поэтому целью является сокращение циклического сигнала, насколько это возможно. Если к оставшимся элементам (отличным от страницы, которая всегда возвращается сервером) добавляется ненулевая директива кэширования, в этом случае, цель может быть достигнута. Кэш BLOB является тем средством, которое добавляет такую директиву кэширования.

Кэш BLOB настраивается с помощью файла Web.config веб-приложения, в котором будет использоваться кэш. Откройте файл Web.config в текстовом редакторе, например, Notepad, и найдите запись BlobCache. По умолчанию это следующая запись:

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>

Атрибуты, используемые в элементе BlobCache, имеют следующие значения.

• location **   **Ссылка на местоположение на жестком диске веб-сервера, в котором будут сохранены кэшированные элементы.

• path   Регулярное выражение типов файлов, которые следует кэшировать.

• maxSize    Размер в ГБ, который может использовать кэш.

• enabled **   **Установите значение true, чтобы разрешить кэш BLOB.

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

• max-age   Время в секундах, в течение которого элементы будут кэшированы в клиентском компьютере

Когда для атрибута максимального возраста установлено значение, отличное от нуля, кэшируемые элементы получают связанное с ними значение срока действия кэша, поэтому браузеру больше не требуется их загружать или даже проверять, что они соответствуют последней версии. Например, предположим, что нужно включить кэширование и выделить до 100 МБ места на веб-сервере для хранения элементов. Срок действия составит один день, и дополнительно к предопределенным типам кэшируемых файлов также требуется кэшировать файлы HTC. Для поддержки этих требований укажите следующие атрибутыBlobCache:

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>

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

Обратите внимание, что все элементы в библиотеке /SiteCollectionImages теперь имеют код состояния HTTP 200, указывающий, что они были успешно загружены. Кроме того, все элементы имеют связанную с ними директиву кэширования, которая указывает, что срок действия кэша составляет меньше одного дня (8 400 секунд). Если страница снова запрашивается, приложение Fiddler показывает, что ни одно изображение не будет запрошено повторно; общее число запросов для обслуживания этой страницы снизилось, таким образом, с 44 до трех, и два из них относятся лишь к согласованию проверки подлинности NTLM между веб-серверов и клиентским приложением. На следующем рисунке показаны данные приложения Fiddler при повторном запросе страницы.

Дополнительно, при работе с кэшем BLOB, примите во внимание следующие условия.

• При его настройке требуется выполнить дополнительные действия, так как файл Web.config необходимо обновить на каждом веб-сервере. Однако полученные преимущества стоят этих усилий.

• Просмотрите контент сайтов и определите, имеются ли другие типы файлов, которые также должны будут обслуживаться из кэша. Хорошим примером являются файлы HTC. Этот тип файлов необходимо добавить в список кэширования, так как они используются в большинстве сайтов публикации.

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

• Некоторые списки не работают по умолчанию для анонимных пользователей. Если к сайту обращаются анонимные пользователи, необходимо вручную настроить разрешения для следующих списков для кэширования внесенных в них элементов:

  • Коллекция главных страниц

  • Библиотека стилей

При работе с кэшем BLOB необходимо знать еще о двух параметрах настройки. Первый применяется для очистки кэша BLOB. Если из кэша нужно удалить отдельный сайт, перейдите к этому семейству сайтов и выберите меню "Действия сайта", "Параметры сайта", "Изменить параметры сайта". В списке задач "Администрирование семейства веб-сайтов" щелкните ссылку кэша объекта семейства сайтов. В разделе "Очистить кэш на диске" установите флажок "Очистить кэш на диске данного сервера" и затем нажмите кнопку ОК.

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

Сжатие IIS

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

Сжатие может дать значительную экономию полосы пропускания. Например, файл core.js включен в каждую страницу SharePoint. Его размер составляет 257 КБ, а после сжатия — только 54 КБ, без дополнительной настройки сжатия IIS. Файл core.js должен кэшироваться после первого обращения пользователя к сайту, но этот пример показывает, насколько значительно сжатие может помочь в сценариях с узкой полосой пропускания.

При установке продуктов и технологий SharePoint программа установки настраивает в службе IIS сжатие статических типов файлов HTM, HTML и TXT и сжатие динамических типов файлов ASP и EXE. После рассмотрения файлов, которые широко используются в существующей реализации, может потребоваться сжатие их дополнительных типов. Например, возможно, будет смысл также сжать статические типы файлов CSS и JS и динамические — AXD и ASPX.

Чтобы добавить статические или динамические типы файлов к списку сжатия, используйте файл adsutil.vbs, который находится в папке %SystemDrive%\Inetpub\AdminScripts по умолчанию на каждом веб-сервере. В следующем примере показан список сжатия статических типов файлов в приложении Microsoft Windows Server 2003, включающий файлы CSS и JS:

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcFileExtensions "htm" "html" "txt" "css" "js"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcFileExtensions "htm" "html" "txt" "css" "js"

В следующем примере показано включение файлов ASPX и AXD в список динамических типов файлов:

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "exe" "axd" "aspx"

При изменении типов файлов для сжатия убедитесь, что в список включаются хорошо сжимаемые файлы. Например, файлы JPG не слишком подходят для сжатия, так как они, по сути, уже сжаты. Также не стоит выбирать типы файлов системы Система Microsoft Office 2007, такие как DOCX, XLSX и PPTX, потому что они обслуживаются не напрямую с сервера, а маршрутизируются через различные фильтры ISAPI, используемые для обслуживания интегрированных конечных пользователей контента Microsoft Office. Кроме того, в системе Система Microsoft Office 2007 эти типы файлов уже сжаты.

Дополнительно к управлению типами сжимаемых файлов также имеется возможность управлять уровнем сжатия динамических типов файлов. Используемая величина сжатия основана на шкале от 0 до 10. Чем выше уровень сжатия, тем меньше будут файлы. Однако компромисс заключается в том, что более высокий уровень сжатия требует больше ресурсов ЦП, поэтому для создания небольших файлов используйте при сжатии ЦП с большей тактовой частотой. Если включено сжатие IIS, в настройке используется уровень сжатия 0. Опыт показывает, что идеальным для продуктов и технологий SharePoint является уровень сжатия 9. Чтобы изменить уровень сжатия, используйте файл сценария adsutil.vbs, описанный ранее в этой статье. В следующем примере показано изменение уровня сжатия до 9.

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel "9"

• CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel "9"

  Примечание

  Эта настройка не изменяет сжатие статических файлов.

Дополнительные сведения см. в статье Использование сжатия HTTP (IIS 6.0) (на английском языке) (https://go.microsoft.com/fwlink/?linkid=108705&clcid=0x419).

Сочетание кэша BLOB и сжатия IIS

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

Загрузка этой книги

Для упрощения чтения и печати эта тема включена в следующую загружаемую книгу:

• Планирование и архитектура для Office SharePoint Server 2007, Часть 2

См. полный список доступных книг на веб-сайте Загружаемые книги для Office SharePoint Server 2007.

См. также

Понятия

Оптимизация настраиваемых веб-частей для территориально-распределенной сети
Расширение глобальных решений Office SharePoint Server с использованием программного обеспечения Office Outlook 2007 и Office Groove
Поддерживаемые глобальные решения для Office SharePoint Server