Планирование архитектуры корпоративного поиска в SharePoint Server
ОБЛАСТЬ ПРИМЕНЕНИЯ:
2013 2016 2019 Subscription Edition 
SharePoint в Microsoft 365
Перед настройкой архитектуры поиска в корпоративной среде необходимо тщательно спланировать несколько вещей. Пошаговые инструкции помогут вам спланировать небольшую, среднюю, большую или очень крупную архитектуру корпоративного поиска.
Знакомы ли вы с компонентами системы поиска в SharePoint Server и как они взаимодействуют? Прочитав обзор архитектуры поиска в SharePoint Server и архитектуры поиска для SharePoint Server 2016 (или архитектуры поиска для SharePoint Server 2013), прежде чем начать работу, вы познакомитесь с архитектурой поиска, компонентами поиска, базами данных поиска и топологией поиска. При планировании архитектуры поиска следует учесть несколько предложений.
Шаг 2. Архитектура поиска какого размера для какого объема содержимого?
Действие 3. Требования к оборудованию, которые необходимо учитывать.
Действие 1. Определение объема имеющегося контента.
Объем контента, имеющегося в индексе поиска, влияет на то, какие ресурсы необходимо размещать в ферме. Вычислите приблизительное количество элементов, которые будут поддерживать поиск. Например, это могут быть следующие элементы: документы, веб-страницы, записи списков SharePoint или изображения. Помните, что каждая запись в списке SharePoint считается за один элемент.
Определив это количество, умножьте его на предполагаемый коэффициент роста контента за год.
Например, если вы начинаете с 12 000 индексированных элементов и ожидаете, что объем этого содержимого утроит в течение следующих 12 месяцев. Необходимо запланировать 36 000 элементов с возможностью поиска.
Шаг 2. Архитектура поиска какого размера для какого объема содержимого?
Не всегда легко оценить, насколько большой или малой должна быть архитектура. Размер архитектуры поиска зависит от объема контента, скорости обхода контента, пропускной способности запросов и требуемого уровня высокой доступности. Существуют примеры архитектуры поиска, которые мы рекомендуем использовать в качестве основы для планирования собственной фермы. Выбор примера архитектуры поиска зависит от того, какой объем контента должен поддерживать поиск.
| Объем содержимого (SharePoint 2016) | Пример архитектуры поиска | Объем содержимого (SharePoint 2013) |
|---|---|---|
| 0–20 млн элементов | Малая ферма поиска | 0–10 млн элементов |
| 0–80 млн элементов | Средняя ферма поиска | 0–40 млн элементов |
| 0–200 млн элементов | Большая ферма поиска | 0–100 млн элементов |
| 0–500 млн элементов | Очень большая ферма поиска | Не поддерживается |
Хотя в этих примерах архитектуры поиска используются виртуальные машины, можно использовать как физические серверы, так и виртуальные машины в соответствии со стратегией общего решения SharePoint Server вашей архитектуры поиска.
Малая ферма поиска
Мы определили, что эта архитектура поиска может выполнять обход контента со скоростью 10 документов в секунду и обрабатывать порядка 20 запросов в секунду. Если в ферме SharePoint Server 2016 имеется до 20 миллионов элементов, скорее всего, вам подойдет небольшая ферма поиска. При скорости 50 документов в секунду первый полный обход 20 миллионов элементов занимает 110 часов.
Средняя ферма поиска
Мы определили, что эта архитектура поиска может выполнять обход контента со скоростью 20 документов в секунду и обрабатывать порядка 80 запросов в секунду. Если у вас есть от 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. Серверу узла также требуется свободное дисковое пространство для диагностических целей, например для ведения журнала, отладки и создания дампов памяти по выполняемым ежедневно операциям, а также для файла подкачки. Как правило, 80 ГБ дискового пространства достаточно для операционной системы Windows Server и программных файлов SharePoint Server.
Увеличьте объем хранилища для пространства журналов SQL каждого сервера базы данных. Если не настроить сервер базы данных для частого резервного копирования баз данных, пространство журнала SQL использует много хранилища. Дополнительные сведения о планировании баз данных SQL см. в статье Планирование и настройка ресурсов хранилища и SQL Server (SharePoint Server).
Минимальный объем хранилища, необходимый для базы данных отчетов аналитики, может быть разным. Это связано с тем, что объем хранилища зависит от того, как пользователи взаимодействуют с SharePoint Server. Если взаимодействие происходит часто, обычно требуется хранить больше событий. Узнайте, какой объем хранилища текущая архитектура поиска использует для базы данных аналитики, и назначьте по крайней мере этот объем переработанной топологии.
Минимальные аппаратные ресурсы, необходимые для малой фермы поиска
В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных.
| Сервер | На узле | Хранилища | ОЗУ | Процессор1 | Пропускная способность сети |
|---|---|---|---|---|---|
| Сервер приложений с компонентами обработки запросов и индексирования. | 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 ГБ ОЗУ и четыре ядра ЦП.
3SharePoint Server 2016 также позволяет использовать хранилище размером 250 ГБ, 16 ГБ ОЗУ и четыре ядра ЦП, но каждый компонент индекса может содержать только 10 миллионов элементов, а ферма поиска поддерживает только тот же объем содержимого, что и ферма поиска SharePoint Server 2013.
Минимальные аппаратные ресурсы, необходимые для средней фермы поиска
В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных.
| Сервер | На узле | Хранилища | ОЗУ | Процессор1 | Пропускная способность сети |
|---|---|---|---|---|---|
| Сервер приложений с компонентами обработки запросов и индексирования. | 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 ГБ ОЗУ и четыре ядра ЦП.
3SharePoint Server 2016 также позволяет использовать хранилище размером 250 ГБ, 16 ГБ ОЗУ и четыре ядра ЦП, но каждый компонент индекса может содержать только 10 миллионов элементов, а ферма поиска поддерживает только тот же объем содержимого, что и ферма поиска SharePoint Server 2013.
Минимальные аппаратные ресурсы, необходимые для большой фермы поиска
В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных.
| Сервер | На узле | Хранилища | ОЗУ | Процессор1 | Пропускная способность сети |
|---|---|---|---|---|---|
| Сервер приложений с компонентами обработки запросов и индексирования. | 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 ГБ ОЗУ и четыре ядра ЦП.
3SharePoint Server 2016 также позволяет использовать хранилище размером 250 ГБ, 16 ГБ ОЗУ и четыре ядра ЦП, но каждый компонент индекса может содержать только 10 миллионов элементов, а ферма поиска поддерживает только тот же объем содержимого, что и ферма поиска SharePoint Server 2013.
Минимальные аппаратные ресурсы для очень большой фермы поиска
В этой таблице показан минимальный объем аппаратных ресурсов, необходимых каждому серверу приложений или баз данных. Этот пример фермы можно создать только с SharePoint Server 2016.
| Сервер | На узле | Хранилища | ОЗУ | Процессор1 | Пропускная способность сети |
|---|---|---|---|---|---|
| Сервер приложений с компонентами индексирования. | 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. Архитектура поиска будет поддерживать высокую доступность, если разместить избыточные компоненты и базы данных поиска на отдельных доменах сбоя. Во всех образцах архитектуры поиска избыточные компоненты поиска размещаются на независимых серверах.
Для каждого избыточного сервера узла в вашей архитектуре поиска необходимо запланировать установку следующих ресурсов.
Избыточные сетевые ресурсы
Избыточные источники питания с независимой разводкой или источники бесперебойного питания.
Действие 4. Проверка качества работы архитектуры поиска.
Перед развертыванием архитектуры поиска в рабочей среде необходимо проверить ее работоспособность. Ниже приведен контрольный список необходимых действий.
Убедитесь, что компоненты индекса используют подсистему ввода-вывода хранилища с достаточным количеством операций ввода-вывода в секунду. См . раздел Тестирование подсистемы ввода-вывода хранилища.
Выполните развертывание архитектуры поиска в пилотной среде. Убедитесь, что пилотная среда имеет те же параметры, что и рабочая среда.
Протестируйте производительность поиска в пилотной среде. См . раздел Проверка производительности поиска.
Общие сведения о тестировании в SharePoint см. в статье Тестирование производительности для SharePoint Server 2013.
Тестирование подсистемы ввода-вывода для хранилища
Чтобы протестировать подсистему ввода-вывода хранилища, выполните наиболее важные операции с диском и измерьте количество операций ввода-вывода в секунду. Для выполнения этих тестов можно использовать средство DiskSpd. См . раздел DiskSpd: надежное средство повышения производительности хранилища.
Настройка тестовой среды
Вам не нужно настраивать всю архитектуру поиска или устанавливать SharePoint Server. Достаточно настроить тестовую среду, которая будет создавать реалистичную рабочую нагрузку для подсистемы ввода-вывода хранилища.
Рассмотрим случай локального хранилища. Например, если в узле A в средней ферме поиска используется локальный диск, необходимо установить две виртуальные машины и запустить тесты дисковых операций одновременно на обеих виртуальных машинах.
Для общего хранилища необходима другая конфигурация. Например, если для рабочей нагрузки всех компонентов индекса в средней ферме поиска и других не связанных с ней рабочих нагрузок используется одно и то же хранилище, необходимо сделать следующее.
Установить восемь виртуальных машин в узлах A, B, C и D и настроить источники несвязанных рабочих нагрузок.
Убедитесь, что несвязанная рабочая нагрузка применяется к общему хранилищу в то же время, когда вы запускаете одновременные тесты дисковых операций на всех виртуальных машинах в узлах A, B, C и D.
Создание тестового файла
Создайте тестовый файл размером 256 Гибайт с помощью команды
diskspd -c256G testfile. Эта команда создает файл размером 256 Гибайт с именем testfile. Вы также можете создать файл другого размера, следуя синтаксису:diskspd -c<size>[K|M|G|b] <filename>Сохраните тестовый файл на запоминающее устройство, которое требуется протестировать. Например: на жестком диске узла A в средней ферме.
Перезапустите сервер. Это гарантирует, что кэширование не повлияет на результаты теста.
Запустите тесты
Теперь можно измерить следующие показатели.
Производительность случайного доступа к блокам среднего размера (см. тесты 1 и 2 ниже).
Пропускная способность чтения и записи при перемещении больших объемов данных (см. тесты 3 и 4 ниже).
В таблице ниже приведены команды DiskSpd, которые следует использовать для выполнения каждого теста. При использовании всех команд подразумевается, что в текущем каталоге имеется тестовый файл. Каждый тест работает в течение 300 с.
| Номер теста | Scope | Command |
|---|---|---|
| 1 | Чтение блоков размером 64 КБ [количество операций ввода-вывода в секунду] | diskspd -t4 -b64K -o25 -r -d300 testfile |
| 2 | Запись блоков размером 256 КБ [количество операций ввода-вывода в секунду] | diskspd -t4 -b256K -o25 -r -w100 -d300 testfile |
| 3 | Чтение файла размером 100 МБ [МБ/с] | diskspd -t1 -o1 -b100M -r -d300 testfile |
| 4 | Запись файла размером 100 МБ [МБ/с] | diskspd -t1 -o1 -b100M -r -w100 -d300 testfile |
Пример результатов для локального дискового хранилища
Примеры результатов в таблице ниже приведены для развертывания, в котором перед добавлением тестового файла использовалось по меньшей мере 50 % емкости дисковой подсистемы.
Параметры контроллера и шпинделей диска оказывают сильное влияние на эти результаты.
Если вы выполняете тестирование на пустых дисках, вы получите завышенные результаты, поскольку тестовый файл будет находиться на самых оптимальных дорожках на всех шпинделях (с коротким рабочим ходом). В этом случае производительность может повыситься в два или три раза. Если вы будете тестировать жесткий диск, оптимизирующий удаленный доступ на неинициализированном дисковом пространстве или в хранилище, содержащем только нули, например в динамических файлах VHD/VHDX, то вы получите нереалистично высокие результаты. В этом случае используйте очень большой файл теста, содержащий реальные данные, а не создавайте искусственный тестовый файл с помощью команд DiskSpd.
| Разметка диска | Тест 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 |
Тестирование производительности поиска
Ниже приведен контрольный список действий, необходимых для тестирования архитектуры поиска.
Выбор контента, для которого будет выполняться тестирование
Выберите контент, который максимально приближен к рабочему контенту. Если вы используете контент, предназначенный только для тестирования, убедитесь, что у вас имеются элементы различных типов, а не один многократно дублированный элемент. Это необходимо, поскольку обработчик запросов будет терять время на обнаружение дублирующих элементов, что повлияет на производительность поиска и ваши результаты не будут репрезентативными для рабочей среды.
Настройте один или несколько источников контента для выполнения обхода контента. Убедитесь, что у вас имеется необходимая учетная запись пользователя и доступ к сети.
Выбор терминов и фраз для тестирования производительности запросов
Количество результатов, получаемых в ответ на запрос, называется отзывом.
Для тестирования производительности обработки запросов прежде всего необходимо создать набор терминов и фраз, которые будут использоваться в качестве запросов. Кроме того, можно собирать запросы из существующей установки. Убедитесь, что этот набор содержит термины и фразы с низким и высоким отзывом что они релевантны среде.
Примеры
Если вы ищете номер продукта в каталоге продуктов, то скорее всего каждый продукт будет иметь только один номер. Поэтому результаты поиска будут получены быстро. Это малый отзыв.
Если вы ищете общий термин, например "презентация", в интрасети компании, то вероятнее всего вы получите много результатов, для чего потребуется больше времени. Это большой отзыв.
Если, например, ваш контент связан с человеческими ресурсами, используйте условия поиска, связанные с этой областью.
Измерение производительности поиска
SharePoint Server собирает показатели производительности поиска в отчетах о работоспособности обхода контента и отчетах о работоспособности запросов. Эти отчеты находятся в Центр администрирования в разделе администрирования поиска.
Для получения хорошего результата можно сначала измерить производительность поиска с помощью синтетической нагрузки, а затем с помощью небольшого набора реальных пользователей и реального контента. При использовании реальных пользователей и реального контента можно наблюдать, как работает архитектура поиска. Если объем контента увеличивается быстрее, чем предполагалось, возможно, стоит рассмотреть использование архитектуры поиска большего размера. Или, если ваши пользователи более активны, чем ожидалось, мы рекомендуем увеличить объем хранилища базы данных аналитики.