Stsadm vs Sharepoint Powershell cmdlet

Как известно, Microsoft активно продвигает Powershell, и старается использовать его в каждом своем продукте. Не исключением стала и очередная версия Sharepoint 2010. В данной статье я хотел бы поделиться своими соображениями на счет того, почему Powershell это наше всё, и почему следует активно отказывать от stsadm при работе с Sharepoint 2010.

С каждой последующей версией любой серьезный программный продукт обрастает функциональностью, и, как следствие, требует всё больше и больше системных ресурсов. В Sharepoint количество таких изменений и нововведений просто огромно. Поэтому требования к аппаратному обеспечению (особенно к памяти) выросли. Но этот вопрос должен больше волновать администраторов. Что же до разработчиков, то для них это вылилось в заметное удлинение процесса деплоя и отладки. stsadm – это .NET приложение, и ему свойственны все “болячки” таких приложений, связанные с производительностью. Только усугубляет ситуацию “модульность” stsadm.

Перейдем сразу к примеру. Думаю многим разработчикам, да и администраторам, знакома вот такая последовательность:

spsadm -o deactivatefeature -id 3bd1ede7-cfa3-45a7-b19e-70ae69a50db6 -url %TargetWebUrl% –force 
spsadm -o uninstallfeature -id 3bd1ede7-cfa3-45a7-b19e-70ae69a50db6 -force
echo Deactivating feature ...
spsadm -o deactivatefeature -id e240c347-7fd4-4ef8-9f57-424664e53e01 -url %TargetWebUrl% -force
echo Uninstalling feature ...
spsadm -o uninstallfeature -id e240c347-7fd4-4ef8-9f57-424664e53e01 -force
echo Retracting solution %PackageName% ...
spsadm -o retractsolution -name "%PackageName%" -local -url %TargetWebUrl%
echo Deleting solution %PackageName% from SharePoint ...
spsadm -o deletesolution -name "%PackageName%"

echo Adding solution %PackageName% to SharePoint ...
spsadm -o addsolution -filename "%PackageFile%"
echo Deploying solution %PackageName% ...
spsadm -o deploysolution -name "%PackageName%" -local -allowGacDeployment -url %TargetWebUrl%
echo Activating feature ...
spsadm -o activatefeature -id 3bd1ede7-cfa3-45a7-b19e-70ae69a50db6 -url %TargetWebUrl%
echo Activating feature ...
spsadm -o activatefeature -id e240c347-7fd4-4ef8-9f57-424664e53e01 -url %TargetWebUrl%

Стандартный скрипт для установки решения в Sharepoint, часто применяется для установки решений в продуктовой среде. Когда я запустил подобный скрипт для установки решения из нескольких рабочих процессов и пары-тройки фич на сервере под управлением Sharepoint 2010, то выполнение этого скрипта заняло у меня… 15 минут. Скрипт и сервер были те же самые, которые использовались для Sharepoint 2007, и на нем выполнение занимало 6-7 минут. Даже после добавления памяти на сервер время удалось уменьшить всего на 2-3 минуты.
 
Ждать столько времени желания не было никакого, особенно если учесть, что из Visual Studio такой же деплой идет за минуту-две. И тогда появилась идея попробовать переписать эту же последовательность на Powershell с применением командлет от Sharepoint 2010. Когда работа была закончена, результат превзошел все ожидания – вместо 12-15 минут те же самые действия в Powershell выполнялись за пару минут!!!! Кроме этого, благодаря Powershell, в скрипт были добавлены действия по открытию сайта (т.к. первое открытие занимает довольно ощутимое время), а также включение рабочих процессов в списках.
 
Для примера привожу тот же самый кусок скрипта, что и выше, но уже на Powershell:
Disable-SPFeature -Identity "3bd1ede7-cfa3-45a7-b19e-70ae69a50db6" -url $TargetWebUrl -Confirm:$false 
Uninstall-SPFeature -Identity "3bd1ede7-cfa3-45a7-b19e-70ae69a50db6" -Confirm:$false
write-host Deactivating feature ...
Disable-SPFeature -Identity "e240c347-7fd4-4ef8-9f57-424664e53e01" -url $TargetWebUrl -Confirm:$false 
write-host Uninstalling feature ...
Uninstall-SPFeature -Identity "e240c347-7fd4-4ef8-9f57-424664e53e01" -Confirm:$false 
write-host Retracting solution $PackageName ...
Uninstall-SPSolution -Identity $PackageName -local -Confirm:$false 
write-host Deleting solution $PackageName from SharePoint ...
Remove-SPSolution -Identity $PackageName  -Confirm:$false
 
write-host Adding solution $PackageName to SharePoint ...
Add-SPSolution -LiteralPath $PackageFile -Confirm:$false
write-host Deploying solution $PackageName ...
Install-SPSolution -Identity $PackageName  -local -GACDeployment -Confirm:$false
write-host Activating feature ...
Enable-SPFeature -Identity "3bd1ede7-cfa3-45a7-b19e-70ae69a50db6" -url $TargetWebUrl -Confirm:$false
write-host Activating feature ...
Enable-SPFeature -Identity "e240c347-7fd4-4ef8-9f57-424664e53e01" -url $TargetWebUrl -Confirm:$false
 
Надеюсь эта информация поможет вам принять решения, и начать использовать Powershell в своей повседневной работе.
 
PS Это мой последний про Sharepoint. В связи со сменой работы, у меня несколько сместился акцент деятельность. Теперь я буду плотно заниматься продуктами из линейки System Center, в частности Operations Manager, Configurations Manager и Service Manager.

Реклама

2 Responses to Stsadm vs Sharepoint Powershell cmdlet

  1. Vasily says:

    Я правильно понимаю что такая разница в производительности вызвана именно _модульностью_ stsadm? Ведь PowerShell вообще целиком на .NET и работает с .NET объектами/классами. Единственное преимущество которое я вижу — то что командлеты SharePoint подгружаются непосредственно в PowerShell, и в результате всё является фактически одним модулем.

  2. Anton says:

    Да, дело в модульности. Каждая команда в stsadm заново инициирцет подключение к Sharepoint и потом торжественного его закрывает. Производительность соответствующая.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: