Лучшие способы улучшить производительность Sharepoint 2007? - PullRequest
4 голосов
/ 18 ноября 2008

Хорошо, мы находимся в конце нашей веревки, и я был бы очень признателен за отзывы сообщества SO.

Наша основная проблема - низкая производительность нашей интрасети на базе MOSS--

Некоторая информация об окружающей среде:

У нас есть стандартное издание MOSS для сайта для совместной работы.

  • Sitedb составляет 29 Гб
  • у нас есть два интерфейса на базе VMWare сервера. (2x 32-битных CPUS каждый)
  • менее 1000 пользователей распределены по всем * 1014 часовые пояса *
  • У нас есть один большой сайт коллекция с подсайтами.

Общие симптомы: Загрузка первой страницы и страниц, которые были «подогреты», довольно приличная, но страницы / сайты, не прошедшие проторенный путь, загружаются очень медленно.

Мы видим всплески, когда страница неожиданно загружается за 30 секунд, по сравнению с более обычным 2

Вот что мы уже сделали:

  • Уменьшенный путь при ползании
  • включенное кэширование объектов и блобов
  • оптимизированная настройка VMware
  • в соответствии с информационным документом Microsoft IT о передовой практике MOSS sharepoint (размер списка esp и т. Д.)

Я не знаю, что еще здесь делать - разделить на несколько семейств сайтов?

Переключиться на 64-битные внешние серверы?

Было бы здорово услышать от других людей, которые были в подобных ситуациях.

Ответы [ 9 ]

3 голосов
/ 18 ноября 2008

Вы не говорите, сколько памяти имеют ваши серверы переднего плана - учитывая, что они 32-битные, я предполагаю, что максимальный для каждого рабочего процесса примерно 2 ГБ + изменение.

Мой совет? Переключитесь на 64 бит, добавьте больше памяти и убедитесь, что вы не используете только один рабочий процесс w3wp для внешнего интерфейса. Изучите «веб-сады», то есть, где вы настраиваете несколько процессов w3wp для каждого интерфейса. Для начала начните с двух рабочих процессов для каждого интерфейса и посмотрите, как это работает. Также убедитесь, что они настроены на переработку, и что переработка каждой пары рабочих процессов НЕ пересекается - наличие двух + рабочих означает, что они могут по очереди перерабатывать, не ограничивая доступ.

только мои 0,02.

-Oisin

2 голосов
/ 20 ноября 2008

Да, кэширование - лучший способ снизить нагрузку на систему. Добавление оперативной памяти на сервер SQL также хорошо. (64-битная версия действительно необходима для вашего SQL-сервера, WFE не так важен).

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

Я упоминал о кешировании?

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

2 голосов
/ 18 ноября 2008

Спасибо за несколько полезных советов, одна вещь, которую я только что узнал, это то, что наше кеширование объектов практически ничего не делает! Это происходит потому, что кажется, что если у вас есть права на редактирование ЛЮБОГО ГОДА в семействе сайтов, по умолчанию отключается кэширование объектов на портале. Поскольку все пользователи имеют права хотя бы на что-то, это означает, что кэширование практически ничего не делает!

Мы обнаружили это, включив отладку кеша, которая помещает небольшой комментарий в html о том, какой кеш используется. После изменения параметра «Разрешить авторам просматривать кэшированное содержимое» в профиле аутентифицированного кэша,

Мы видим, что это делает для редакторов, но для обычных зрителей, неподтвержденным свидетельством является то, что это оказывает большое влияние!

2 голосов
/ 18 ноября 2008

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

  • Является ли сервер базы данных отдельным сервером или одним из ваших веб-серверов?

  • Видите ли вы узкое место CPU / Disk на внешнем сервере или серверах БД?

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

1 голос
/ 18 ноября 2008

Вы взглянули на План границ программного обеспечения (Office SharePoint Server) ?

На первый взгляд, ваш сервер соответствует рекомендуемым настройкам.

Для улучшения производительности вы должны взглянуть на:

  • 64-битные серверы
  • Ограничение количества элементов, отображаемых в ваших списках документов Limiting number of items displayed
    (источник: microsoft.com )
0 голосов
/ 09 марта 2011

Я запускаю очень похожую установку, однако у нас более 400 ГБ, распределенных по 3 семействам сайтов. Есть несколько других вещей, которые вы можете попробовать, прежде чем идти по 64-битному пути.

  • Убедитесь, что нет проблем с диском или пропускной способностью между сервером БД и веб-интерфейсом. Скорость сети на сервере базы данных имеет решающее значение.
  • Проверьте сам сервер базы данных, если диски находятся в сети SAN, могут возникнуть проблемы с производительностью, если существует конфликт из-за физического диска в san. ОЗУ также важно, чем больше она может кешировать в памяти, тем меньше времени ждет ответа дисков.
  • Запланировать выполнение заданий обхода в нерабочее время
  • Вы включили кэширование объектов, что может быть огромной помощью, убедитесь, что сжатие также включено! Для пользователей с низкой пропускной способностью sharepoint отправляет пользователям большое количество информации CSS, которая сжимается до 1/10 ее размера, если сжатие включено.
  • Вот еще один важный вопрос: убедитесь, что DNS вашей компании работает правильно в других местах, и посмотрите, не связана ли эта проблема с внешними источниками. То есть у нас есть межсетевой экран sonicwall, который жесток по времени отклика для офисов, подключающихся через него для чего угодно.
  • Micrsoft имеет технический документ по мониторингу производительности счетчика. Это очень тщательно и поможет вам сузить проблему между CPU / RAM / Network / HD IO.

Надеюсь, это поможет!

0 голосов
/ 30 июня 2009

у нас также есть проблемы с производительностью. Мы обновили 64-битную версию win 2008, но это не так сильно, как ожидалось.

Повышение скорости работы привело к переходу с азтентификации NTLM на Kerberos. Это было наше главное улучшение.

надеюсь, это кому-нибудь поможет

0 голосов
/ 20 января 2009

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

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

Microsoft публично заявила, что 2007 является последней версией SharePoint, которая будет работать на 32-разрядных серверах. Переход на 64 бит будет требованием - так как парень из масляного фильтра FRAM говорит - «плати мне сейчас или плати мне позже» ...

0 голосов
/ 20 ноября 2008

Обязательно проверьте использование диска. Если у вас две виртуальные машины, и они работают на одном диске / SAN, убедитесь, что они не слишком заняты. Перегруженные сети SAN снижают производительность

...