SharePoint 2010: Оптимизация хранения рабочих областей SharePoint

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

Термином «рабочая область SharePoint» именуют место хранилища, применяемое для хранения данных рабочей области. Клиентское программное обеспечение также именуют рабочей областью SharePoint (SharePoint Workspace), потому мы будем именовать последнюю SPW 2010. С таковой терминологией рабочую область SharePoint можно считать похожей на рабочую область Microsoft Groove.

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

Для чего нужна оптимизация

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

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

Если вы увеличите число документов до 1800 либо больше, SPW 2010 откажется их все синхронизировать и загрузит в рабочую область SharePoint только метаданные документов. При открытии 1-го из документов он будет синхронизироваться «на лету».

Так, если в SPW 2010 загружать метаданные документов намного эффективнее, чем пробовать синхронизировать документы полностью, почему же тогда SPW 2010 не делает так всегда? Так ведь сам смысл существования SPW 2010 в том, чтоб предоставлять возможность работать с данными SharePoint даже в автономном режиме. Очень тяжело работать с документами, имея только их метаданные.

Оптимизация хранилища рабочей области

В текущее время существует только два метода обойти упомянутые ограничения. 1-ый — создавать рабочие области Groove заместо рабочих областей SharePoint. В согласовании с официальной информацией Microsoft, эти ограничения на синхронизацию относятся только к кешу документов в Office, но не к рабочим областям Groove (которые можно сделать и к которым можно обращаться средствами SPW 2010).

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

Во-1-х, можно избавиться от всех неиспользуемых рабочих областей. Производительность процесса синхронизации определяется общим числом документов во всех рабочих областях. Если у вас 10 рабочих областей с соткой документов в каждой, SPW 2010 придется синхронизировать 1000 документов, невзирая на то, что в каждой рабочей области число документов существенно ниже порога в 500 документов.

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

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

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

Допустим, что на сервере есть библиотека «Общие документы», содержащая папки «Финансовый отдел», «Маркетинг» и «Управление персоналом». Сотрудникам денежного отдела нет смысла синхронизировать всю библиотеку, так как все папки не считая «Финансовый отдел» им не необходимы. В реальной компании у их даже не будет доступа к другим папкам.

Чтоб сделать рабочую область, связанную с библиотекой документов, используйте последующий URL-адрес: http://SharePoint/Общие%20Документы/Денежный%20отдел. Так вы создадите рабочую область, содержащую только папку «Финансовый отдел» и все ее подпапки, исключив все другие папки (другими словами «Маркетинг» и «Управление персоналом»), также содержимое папки «Общие документы».

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

Мониторинг SQL Server

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

Перечисленные ниже характеристики относятся к SQL Server 2008 либо SQL Server 2008 R2, работающим в связке с SharePoint 2010, и они не непременно применимы к другим типам баз данных SQL Server.

Microsoft советует смотреть за счетчиком General Statistics\User Connections, показывающим общее число пользовательских подключений к SQL Server. Задачи с производительностью вероятны, если показания счетчика превосходят в 5 раз базисное значение.

Очередной счетчик — Databases\Transactions/Sec. Microsoft не предоставляет никаких определенных советов относительно показаний этого счетчика, но рекомендует записывать его показания при работе сервера в обычном «здоровом» состоянии. Таким макаром, при появлении заморочек с производительностью, вы можете сопоставить текущее число транзакций с базисными показателями.

Мониторинг блокировок сервера — один методов высококачественной оценки производительности SQL Server. Есть много относящихся к блокировкам счетчиков, но более нужный из их — Locks\Lock Waits/Sec.Он указывает, сколько запросов на блокировку за секунду не удается немедля обслужить серверу SQL Server.

Если запросы на блокировку не удовлетворяются немедля, необходимо проследить за счетчиком Locks\Average Wait Time (ms), который информирует о среднем времени ожидания блокировки. Если это значение стабильно вырастает, у сервера SQL суровые препядствия с производительностью.

Найти, как отлично работает база данных SQL, позволяет не только лишь мониторинг обыденных блокировок, да и наблюдение за короткосрочными блокировками. Для этого служат счетчики Latches\Latch Waits/Sec и Latches\Average Latch Wait Time. Признак заморочек — рост числа ожиданий за секунду.

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

В конце концов, нужно смотреть за скоростью обработки сервером SQL Server пользовательских запросов. Наблюдайте за числом операций компиляции и перекомпиляции за секунду при помощи счетчиков Statistics\Compilations/Sec и SQL Statistics\Re-Compilations/Sec.

Показания последних 2-ух счетчиков глупы, если не найти базисные характеристики во время обычной работы сервера. Сделав это, можно держать под контролем число компилируемых и перекомпилируемых запросов. Уменьшение этого числа, не сопровождаемое понижением пользовательской нагрузки, значит, что у сервера SQL Server трудности с обработкой пользовательских запросов.

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

Материалы по теме:

SharePoint 2010: Improve SharePoint 2010 Performance with RBS
Storage and SQL Server Capacity Planning and Configuration
Inside SharePoint: Securing External SharePoint Communications

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.