Планирование архитектуры поиска в корпоративной среде в SharePoint Server 2016

 

**Применимо к:**SharePoint Server 2016

**Последнее изменение раздела:**2017-09-08

Сводка. Узнайте, как спланировать архитектуру поиска в корпоративной среде.

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

Знаете ли вы о компонентах системы поиска в SharePoint Server и их взаимодействии? Чтобы больше узнать об архитектуре, компонентах, базах данных и топологии поиска, ознакомьтесь со статьей Обзор архитектуры поиска в SharePoint Server и плакатом Архитектуры для поиска для SharePoint Server 2016 (или плакатом Архитектуры поиска для SharePoint Server 2013). Вот что следует учитывать при планировании архитектуры поиска:

1. Действие 1. Определение объема имеющегося контента.

2. Действие 2. Определение размера архитектуры поиска на основании объема имеющегося контента.

3. Действие 3. Требования к оборудованию, которые необходимо учитывать.

   • Выбор между физическими и виртуальными серверами

   • Выбор аппаратных ресурсов для серверов узлов

   • Планирование производительности хранилища

   • Выбор способа поддержки высокой доступности архитектурой поиска

4. Действие 4. Проверка качества работы архитектуры поиска.

   • Тестирование подсистемы ввода-вывода для хранилища

   • Тестирование производительности поиска

Действие 1. Определение объема имеющегося контента.

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

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

Например, если изначально у вас имеется 12 000 проиндексированных элементов и ожидается, что за год объем этого контента увеличится в три раза, то следует запланировать 36 000 элементов, поддерживающих поиск.

Действие 2. Определение размера архитектуры поиска на основании объема имеющегося контента.

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

Объем контента (SharePoint 2016)	Пример архитектуры поиска	Объем контента (SharePoint 2013)
0–20 млн элементов	Малая ферма поиска	0–10 млн элементов
0–80 млн элементов	Средняя ферма поиска	0–40 млн элементов
0–200 млн элементов	Большая ферма поиска	0–100 млн элементов
0–500 млн элементов	Очень большая ферма поиска	Не поддерживается

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

Малая ферма поиска

Мы определили, что эта архитектура поиска позволяет выполнять обход контента со скоростью 50 документов в секунду и обрабатывать порядка 10 запросов в секунду. Если у вас до 20 млн элементов в ферме SharePoint Server 2016, вероятно, наиболее подходящий вариант для вас — малая ферма поиска. При скорости 50 документов в секунду первый полный обход 20 миллионов элементов занимает 110 часов.

Средняя ферма поиска

Мы определили, что эта архитектура поиска позволяет выполнять обход контента со скоростью 100 документов в секунду и обрабатывать порядка 10 запросов в секунду. Если у вас от 20 до 80 млн элементов в ферме SharePoint Server 2016, вероятно, наиболее подходящий вариант для вас — средняя ферма поиска. При скорости 200 документов в секунду первый полный обход 80 миллионов элементов занимает 280 часов.

Большая ферма поиска

Мы определили, что эта архитектура поиска позволяет выполнять обход контента со скоростью 200 документов в секунду и обрабатывать порядка 10 запросов в секунду. Если у вас от 80 до 200 млн элементов в ферме SharePoint Server 2016, вероятно, наиболее подходящий вариант для вас — большая ферма поиска. При скорости 200 документов в секунду первый полный обход 200 миллионов элементов занимает 280 часов.

Очень большая ферма поиска

Корпорация Майкрософт протестировала эту архитектуру поиска и определила, что она позволяет выполнять обход контента со скоростью 300–500 документов в секунду и обрабатывать порядка 10 запросов в секунду. Архитектуру фермы поиска такого размера поддерживает только SharePoint Server 2016. Если у вас до 500 миллионов элементов, советуем взять за основу очень большую ферму поиска. При скорости 500 документов в секунду первый полный обход 500 миллионов элементов занимает примерно 300 часов.

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

Действие 3. Требования к оборудованию, которые необходимо учитывать.

Теперь, когда вы определили объем контента и выбрали пример архитектуры поиска, необходимо спланировать необходимое оборудование, как описано в этом разделе.

• Выбор между физическими и виртуальными серверами

• Выбор аппаратных ресурсов для серверов узлов

  • Планирование общего хранилища для серверов узлов

  • Минимальные аппаратные ресурсы, необходимые для малой фермы поиска

  • Минимальные аппаратные ресурсы, необходимые для средней фермы поиска

  • Минимальные аппаратные ресурсы, необходимые для большой фермы поиска

  • Минимальные аппаратные ресурсы для очень большой фермы поиска

• Планирование производительности хранилища

  • Выбор хранилища

    • Требования к количеству операций ввода-вывода в секунду для компонента поиска

    • Требования к количеству операций ввода-вывода в секунду для базы данных поиска

• Выбор способа поддержки высокой доступности архитектурой поиска

Выбор между физическими и виртуальными серверами

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

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

Выбор аппаратных ресурсов для серверов узлов

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

Например, при размещении виртуальных машин в Windows Server 2008 R2 с пакетом обновления 1 (SP1) можно использовать больше четырех ядер ЦП на каждую виртуальную машину. При использовании Windows Server 2012 и более новых версий, на виртуальную машину можно применять восемь и более ядер ЦП. Затем можно реализовать горизонтальное масштабирование, добавив число ядер для каждой виртуальной машины, вместо вертикального масштабирования (увеличения числа виртуальных машин). Настраивайте серверы или виртуальные машины, на которых размещаются одинаковые компоненты поиска, с одинаковыми аппаратными ресурсами. Используем в качестве примера компонент индекса. Если разделы индекса размещаются на виртуальных машинах, производительностью всей архитектуры поиска определяется производительностью самой медленной виртуальной машины.

Общее хранилище

Убедитесь, что в каждом сервере узла имеется достаточный объем дискового пространства для базовой установки операционной системы Windows Server и для программных файлов SharePoint Server. Серверу узла также требуется свободное дисковое пространство для диагностических целей, например для ведения журнала, отладки и создания дампов памяти по выполняемым ежедневно операциям, а также для файла подкачки. Обычно для операционной системы Windows Server и программных файлов SharePoint Server достаточно 80 ГБ дискового пространства.

Увеличьте пространство для хранения журналов SQL для каждого сервера базы данных. Если не настроить частое резервное копирование баз данных, журналы SQL будут занимать много места. Дополнительные сведения о планировании баз данных SQL см. в статье Настройка и планирование загрузки SQL Server и хранилища (SharePoint Server).

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

Минимальные аппаратные ресурсы, необходимые для малой фермы поиска

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

Сервер	На узле	Хранилище	ОЗУ	Processor1	Пропускная способность сети
Сервер приложений с компонентами обработки запросов и индексирования.	A, B	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений с компонентами обхода контента, администрирования поиска, аналитики и обработки контента.	A, B	200 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Сервер баз данных со всеми базами данных поиска.	C, D	100 ГБ	16 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с

1Здесь указано количество ядер, а не количество потоков ЦП.

2 С SharePoint Server 2013 минимальный объем ресурсов — 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора.

3 С SharePoint Server 2016 можно также использовать 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора, но в этом случае любой индексированный компонент сможет вместить не более 10 миллионов элементов, а в ферме поиска будет поддерживаться такой же объем контента, как в ферме поиска SharePoint Server 2013.

Минимальные аппаратные ресурсы, необходимые для средней фермы поиска

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

Сервер	На узле	Хранилище	ОЗУ	Processor1	Пропускная способность сети
Сервер приложений с компонентами обработки запросов и индексирования.	A, B, C, D	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений, содержащий компонент индекса.	A, B, C, D	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений с компонентами аналитики и обработки контента.	E, F	300 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Сервер приложений с компонентами обхода контента, администрирования поиска и обработки контента.	E, F	100 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Сервер баз данных со всеми базами данных поиска.	G, H	400 ГБ	16 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с

1Здесь указано количество ядер, а не количество потоков ЦП.

2 С SharePoint Server 2013 минимальный объем ресурсов — 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора.

3 С SharePoint Server 2016 можно также использовать 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора, но в этом случае любой индексированный компонент сможет вместить не более 10 миллионов элементов, а в ферме поиска будет поддерживаться такой же объем контента, как в ферме поиска SharePoint Server 2013.

Минимальные аппаратные ресурсы, необходимые для большой фермы поиска

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

Сервер	На узле	Хранилище	ОЗУ	Processor1	Пропускная способность сети
Сервер приложений с компонентами обработки запросов и индексирования.	A, B, C, D, E, G, H	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений, содержащий компонент индекса.	A, B, C, D, E, F, G, H, I, J	500 ГБ2, 3	32 ГБ2, 3	1,8 ГГц, 8 ядер2, 3	1 Гбит/с
Сервер приложений с компонентами аналитики и обработки контента.	K, L, M, N	300 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Серверы приложений с компонентами обхода контента и администрирования поиска	K, L	100 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Серверы баз данных с базами данных поиска.	O, P, Q, R	500 ГБ	16 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с

1Здесь указано количество ядер, а не количество потоков ЦП.

2 С SharePoint Server 2013 минимальный объем ресурсов — 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора.

3 С SharePoint Server 2016 можно также использовать 500 ГБ места для хранения, 16 ГБ оперативной памяти и четыре ядра процессора, но в этом случае любой индексированный компонент сможет вместить не более 10 миллионов элементов, а в ферме поиска будет поддерживаться такой же объем контента, как в ферме поиска SharePoint Server 2013.

Минимальные аппаратные ресурсы для очень большой фермы поиска

В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или базы данных. Этот пример фермы можно создать только при использовании SharePoint Server 2016.

Сервер	На узле	Хранилище	ОЗУ	Processor1	Пропускная способность сети
Сервер приложений с компонентами индексирования.	A-X	500 ГБ	32 ГБ	1,8 ГГц, 8 ядер	1 Гбит/с
Сервер приложений с компонентами обработки запросов и индексирования.	Y, Z	500 ГБ	32 ГБ	1,8 ГГц, 8 ядер	1 Гбит/с
Серверы приложений с компонентами обхода контента, администрирования поиска или обработки контента	AA-AF	100 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Серверы приложений с компонентами обработки аналитики	AG, AH	800 ГБ	8 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с
Серверы баз данных с базами данных поиска	AI-AL	500 ГБ	16 ГБ	1,8 ГГц, 4 ядра ЦП	1 Гбит/с

1Здесь указано количество ядер, а не количество потоков ЦП.

Планирование производительности хранилища

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

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

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

• Храните данные компонентов поиска в отдельном томе или разделе хранилища, обладающем высокой производительностью.

  Примечание

  Вы можете выбрать настраиваемое расположение для данных компонента поиска при установке SharePoint Server на узле. Любой компонент поиска на узле, которому требуется хранить данные, будет хранить их в указанном расположении. Чтобы изменить его, необходимо переустановить SharePoint Server на этом узле.

Выбор хранилища

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

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

Требования к количеству операций ввода-вывода в секунду для компонента поиска

Имя компонента	Сведения о компоненте	Требуемое количество операций ввода-вывода в секунду	Использование отдельного тома или раздела хранилища
Компонент индекса	Использует хранилище при объединении индекса и при обработке запросов и ответах на них.	300 операций ввода-вывода в секунду для чтения блоков размером 64 КБ в случайном порядке. 100 операций ввода-вывода в секунду для записи блоков размером 256 КБ в случайном порядке. 200 МБ/с для последовательного чтения. 200 МБ/с последовательной записи.	Да
Компонент аналитики	Выполняет локальный анализ данных путем массовой обработки.	Нет	Да
Компонент обхода	Выполняет локальное хранение загруженного контента перед отправкой его на компонент обработки контента. Хранилище ограничено пропускной способностью сети.	Нет	Да

Требования к количеству операций ввода-вывода в секунду для базы данных поиска

Имя базы данных	Требуемое количество операций ввода-вывода в секунду	Типичная нагрузка на подсистему ввода-вывода.
База данных обхода	Количество операций ввода-вывода в секунду варьируется от среднего до большого	Скорость обхода контента составляет 10 операций ввода-вывода на 1 документ в секунду.
База данных ссылок	Среднее количество операций ввода-вывода в секунду	10 операций ввода-вывода в секунду на 1 млн элементов в индексе поиска.
База данных администрирования поиска	Малое количество операций ввода-вывода в секунду	Неприменимо.
База данных отчетов аналитики	Среднее количество операций ввода-вывода в секунду	Неприменимо.

Выбор способа поддержки высокой доступности архитектурой поиска

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

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

1. Избыточные сетевые ресурсы

2. Избыточные источники питания с независимой разводкой или источники бесперебойного питания.

Действие 4. Проверка качества работы архитектуры поиска.

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

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

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

3. Протестируйте производительность поиска в пилотной среде. См. статью Тестирование производительности поиска

Общий обзор тестирования в SharePoint см. в статье Тестирование производительности для SharePoint Server 2013.

Тестирование подсистемы ввода-вывода для хранилища

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

Настройка тестовой среды

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

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

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

1. Установить восемь виртуальных машин в узлах A, B, C и D и настроить источники несвязанных рабочих нагрузок.

2. Убедитесь, что несвязанная рабочая нагрузка применяется к общему хранилищу в то же время, когда вы запускаете одновременные тесты дисковых операций на всех виртуальных машинах в узлах A, B, C и D.

Создание тестового файла

1. С помощью команды sqlio.exe -t32 -s1 -b256 1g создайте тестовый файл размером 1 ГБ. В результате выполнения этой команды будет создан файл с именем 1g.

2. Сохраните тестовый файл на запоминающем устройстве, которое необходимо протестировать, например на жестком диске узла A в средней ферме.

3. Сцепите этот файл с тестовым файлом достаточно большого размера, например 256 ГБ, с помощью команды copy 1g+1g+1g+...+1g testfile.

4. Перезапустите сервер. Это гарантирует, что кэширование не повлияет на результаты теста.

Запустите тесты

Теперь можно измерить следующие показатели.

• Производительность случайного доступа к блокам среднего размера (см. тесты 1 и 2 ниже).

• Пропускная способность чтения и записи при перемещении больших объемов данных (см. тесты 3 и 4 ниже).

В таблице ниже перечислены команды SQLIO, необходимые для запуска каждой проверки. Предполагается, что в текущем каталоге имеется файл testfile. Каждая проверка длится 300 с.

Номер теста	Область	Команда
1	Чтение блоков размером 64 КБ [количество операций ввода-вывода в секунду]	sqlio.exe -kR -t4 -o25 -b64 -frandom -s300 testfile
2	Запись блоков размером 256 КБ [количество операций ввода-вывода в секунду]	sqlio.exe -kW -t4 -o25 -b256 -frandom -s300 testfile
3	Чтение файла размером 100 МБ [МБ/с]	sqlio.exe -kR -t1 -o1 -b100000 -frandom -s300 testfile
4	Запись файла размером 100 МБ [МБ/с]	sqlio.exe -kW -t1 -o1 -b100000 -frandom -s300 testfile

Пример результатов для локального дискового хранилища

Примеры результатов в таблице ниже приведены для развертывания, в котором перед добавлением тестового файла использовалось по меньшей мере 50 % емкости дисковой подсистемы.

Параметры контроллера и шпинделей диска оказывают сильное влияние на эти результаты.

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

Разметка диска	Тест 1	Тест 2	Тест 3	Тест 4
Минимальное рекомендуемое количество операций ввода-вывода в секунду во время обычных операций	300	100	200	200
Четыре диска NLSAS (1 ТБ, 7200 об/мин) в массиве RAID5 на контроллере RAID Dell H710 (с полосой, равной 64 КБ, и размером блока, равным 64 КБ)	1181	206	284	296
Восемь дисков NLSAS (1 ТБ, 7200 об/мин) в массиве RAID5 на контроллере RAID Dell H710 (с полосой, равной 64 КБ, и размером блока, равным 64 КБ)	2082	337	610	645
Шестнадцать дисков NLSAS (1 ТБ, 7200 об/мин) в массиве RAID5 на контроллере RAID Dell H710 (с полосой, равной 64 КБ, и размером блока, равным 64 КБ)	3763	595	1173	1181
Шестнадцать дисков NLSAS (1 ТБ, 7200 об/мин) в массиве RAID50 (2 x 8) на контроллере RAID Dell H710 (с полосой, равной 64 КБ, и размером блока, равным 64 КБ)	3613	545	1139	1164
Шестнадцать дисков NLSAS (1 ТБ, 7200 об/мин) в массиве RAID10 на контроллере RAID Dell H710 (с полосой, равной 256 КБ, и размером блока, равным 64 КБ)	4030	1146	970	775
Четыре SSD SmartStorage Optimus (800 ГБ) в массиве RAID5 на контроллере RAID Dell H710 (с полосой, равной 64 КБ, и размером блока, равным 64 КБ)	32385	3781	1714	1319
Четыре SSD SmartStorage Optimus (800 ГБ) в массиве RAID0 на контроллере RAID Dell H710 (с полосой, равной 256 КБ, и размером блока, равным 64 КБ)	31747	7149	1643	1798

Тестирование производительности поиска

Ниже приведен контрольный список действий, необходимых для тестирования архитектуры поиска.

1. Выбор контента, для которого будет выполняться тестирование

2. Выбор терминов и фраз для тестирования производительности запросов

3. Измерение производительности поиска

Выбор контента, для которого будет выполняться тестирование

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

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

Выбор терминов и фраз для тестирования производительности запросов

Количество результатов, получаемых в ответ на запрос, называется отзывом.

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

Примеры

• Если вы ищете номер продукта в каталоге продуктов, то скорее всего каждый продукт будет иметь только один номер. Поэтому результаты поиска будут получены быстро. Это — малый отзыв.

• Если вы ищете общий термин, например "презентация", в интрасети компании, то вероятнее всего вы получите много результатов, для чего потребуется больше времени. Это — большой отзыв.

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

Измерение производительности поиска

SharePoint Server собирает результаты измерений производительности поиска в отчеты о работоспособности обхода и работоспособности запросов. Эти отчеты находятся в Центр администрирования в разделе администрирования поиска.

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