SharePoint 2010: Оптимизация хранения рабочих областей SharePoint
С SharePoint можно работать, даже находясь в автономном режиме. В этой статье рассказывается, как для этого надо оптимизировать архитектуру хранения рабочих областей 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 только метаданные документов. При открытии одного из документов он будет синхронизироваться «на лету».
Так, если в SPW 2010 загружать метаданные документов намного эффективнее, чем пытаться синхронизировать документы целиком, почему же тогда SPW 2010 не делает так все время? Так ведь сам смысл существования SPW 2010 в том, чтобы предоставлять возможность работать с данными SharePoint даже в автономном режиме. Очень трудно работать с документами, имея только их метаданные.
Оптимизация хранилища рабочей области
В настоящее время существует только два способа обойти упомянутые ограничения. Первый — создавать рабочие области Groove вместо рабочих областей SharePoint. В соответствии с официальной информацией Microsoft, эти ограничения на синхронизацию относятся только к кешу документов в Office, но не к рабочим областям Groove (которые можно создать и к которым можно обращаться средствами SPW 2010).
Другой вариант — сократить число синхронизируемых документов. Здесь возможны разные сценарии.
Во-первых, можно избавиться от всех неиспользуемых рабочих областей. Производительность процесса синхронизации определяется общим числом документов во всех рабочих областях. Если у вас десять рабочих областей с сотней документов в каждой, SPW 2010 придется синхронизировать 1000 документов, несмотря на то, что в каждой рабочей области число документов значительно ниже порога в 500 документов.
SPW 2010 создает новую рабочую область для каждого подключения к библиотеке или папке в ней. Со временем оказывается, что вы накопили массу рабочих областей, которые больше не используются. Избавление от этих рабочих областей — отличный способ сократить число документов, которые надо синхронизировать средствами SPW 2010.
Кроме того, можно также подумать, нужно ли вообще кешировать все документы. Большинству ваших мобильных пользователей скорее всего очень понравиться возможность иметь автономный доступ к данным SharePoint, когда они путешествуют. Вместе с тем, набор документов, которые им действительно нужны, невелик. Неплохо иметь автономный доступ к другим документам, но это не является необходимым. Уменьшение числа кешируемых документов позволит избавиться от проблем с производительностью.
Вы сильно облегчите себе и своим пользователям работу, если покажете им, как синхронизировать отдельные папки вместо целых библиотек документов SharePoint. Когда вы создаете рабочую область SharePoint, SPW 2010 запрашивает URL-адрес библиотеки документов, которую надо синхронизировать. В сущности, можно добавить в URL путь к файлу.
Допустим, что на сервере есть библиотека «Общие документы», содержащая папки «Финансовый отдел», «Маркетинг» и «Управление персоналом». Сотрудникам финансового отдела нет смысла синхронизировать всю библиотеку, потому что все папки кроме «Финансовый отдел» им не нужны. В реальной компании у них даже не будет доступа к другим папкам.
Чтобы создать рабочую область, связанную с библиотекой документов, используйте следующий URL-адрес: https://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.
Показания последних двух счетчиков бессмысленны, если не определить базовые показатели во время нормальной работы сервера. Сделав это, можно контролировать число компилируемых и перекомпилируемых запросов. Уменьшение этого числа, не сопровождаемое снижением пользовательской нагрузки, означает, что у сервера SQL Server сложности с обработкой пользовательских запросов.
Мониторы производительности предоставляют счетчики SQL Server, которые позволяют оценивать общую производительность этого сервера. При обнаружении проблем с производительностью для более глубокой диагностики неполадок можно также использовать счетчики аппаратных средств.
.jpg)
Брайен Поузи (Brien Posey) носит звание MVP и является независимым автором, из-под пера которого вышли тысячи статей и десятки книг. Связаться с Брайеном можно через его веб-сайт brienposey.com.