Blog

SharePoint Workflow Performance (model 2010)

Proč dnes ještě psát o workflow modelu 2010? Dobrá otázka! Prostě proto, že se stále používá.

Nedávno jsem se znovu hlouběji ponořil do tohoto MSDN článku:

Kromě konceptu a obecných pravd o workflow rozebírá do detailu performance mechanismy, možnosti nastavení parametrů („throttle“, „batch size“, „timeout“, „workflow timer interval“), a popisuje výsledky specifických performance testů workflow. Dokument se sice vztahuje na WSS 3 / MOSS 2007, ale prakticky jde o identický model workflow engine, dnes nazývaný „SharePoint 2010 workflow model“, kdy jsou všechna workflow zpracovávána na SharePoint serverech.
Jak víme, SharePoint 2013 přinesl nový workflow engine „SharePoint 2013 workflow model“ založený na externalizovaném workflow manageru. Ten může běžet i mimo SharePoint (i v cloudu), může mít clusterový charakter, vlastní SQL infrastrukturu atd. Workflow jsou tedy zpracovávána ve vůči farmě externalizované službě workflow manager a s farmou si na pozadí povídají prostřednictvím webových služeb. O novém modelu toho bylo napsáno mnoho. Odhaduji však, a na projektech to jasně vidím, že většina workflow dnes stále ještě používá „starý dobrý“ model 2010. Důvody jsou zřejmé (beru v úvahu pouze instalace SharePointu 2013):
  • Nový model postrádá řadu očekávaných aktivit. I když tyto chybějící aktivity v zásadě nahrazuje možností oslovovat webové služby a využít tak širší základnu klientských SharePoint API, toto uchopení není tak příjemné, jako kdybychom měli očekávané možnosti k dispozici přímo jako aktivity.
  • Produkt Nintex Workflow 2013 nový model zatím přechází a pracuje nativně v modelu 2010 (mluvím o nasazení on premise). Dle mých informací Nintex vydá další verzi nebo revizi Nintex Workflow, která bude založena na novém modelu workflow 2013. Zatím to však nenastalo. A až to nastane, stejně nás to jako vývojáře / architekty / dodavatele nezbaví nutnosti dívat se na problematiku z širšího kontextu, o čemž chci psát dále.
V novém modelu workflow 2013, pominu-li jasný trend externalizace, který přesně odpovídá cloudovému modelu fungování, vidím (a slibuji si) vyšší stabilitu, performance i škálovatelnost s ohledem na enterprise projekty a enterprise delivery jako takové. Samotné zapouzdření a systémové oddělení běhu workflow do externalizované služby se mi zkrátka hodně líbí.
Zaměřme se však nyní na workflow model 2010. Cílem mého příspěvku není mimika původního MSDN článku (ten si určitě přečtěte), ale spíše souhrn nejdůležitějších fakt doplněný o další zkušenosti. V rámci realizace workflow musíme vidět více stran mince a skoro se mi chce napsat více než obě strany mince. Ostatně jako cokoliv v rámci SharePointu, i zde musíme uvažovat v širším kontextu. Pokud nám záleží na performance našich workflow řešení, mějme na paměti:

History listy nebyly navrženy pro účely auditování

Jsou určeny k „poznamenávání“ důležitých informací majících z pohledu toku procesu velký význam pro uživatele, nicméně jen po omezenou dobu. History záznamy zde nejsou udržovány věčně (nechme stranou ale …), nedá se na ně spoléhat, nejsou tedy použitelné pro účely auditování. Navíc zde nemáme příliš velkou security.
Dalším faktorem je performance. Není tajemstvím, že SharePoint listy a knihovny degradují na výkonu s přibývajícím počtem položek. History listy nejsou výjimkou. SharePoint 2013 je na tom mnohem lépe, ale i tak není dobré uvažovat ploše. Nemělo by se sem tedy „logovat“ cokoliv jen proto, že se to vývojáři líbí. Samozřejmě, během vývoje je zcela v pořádku, pokud sem logujeme potřebné „debugovací“ informace, ale v rámci produkčního provozu bychom se měli co nejvíce omezit.

Pro každou asociaci workflow je vhodné použít dedikovaný history list a task list

Vyplývá z předchozího. Čím méně položek, tím lépe. Někde se nevyhneme tomu mít v task listu mnoho úkolů atd., ale dílčí asociace workflow si přímo říkají o dedikované task a history listy.
I když můžeme mít „vyšší“ důvody pro použití jednoho společného listu, např. z důvodu následné jednoduchosti v rámci BI řešení (nemusíme řešit agregaci atd.), primárně bychom měli uvažovat způsobem co nejvíce tato data rozmělnit. Samozřejmě vždy záleží na očekávaných nárůstech, tzn. nemá smysl rozdělovat „slepě“ úplně vše. Musíme vidět i otázku následné správy takto rozděleného obsahu. Základní myšlenka je však zřejmá. Zaměřme se na workflow generující větší počty úkolů a history záznamů a snažme se tento obsah rozmělnit.

Není pravda, že retenční job workflow (podle AutoCleanupDays) odstraňuje z history listů záznamy

Pouze history list po určité době deasociuje s danou instancí workflow, takže záznamy se dále na stránce přehledu historie workflow nezobrazí. Osobně si celou situaci dovedu představit mnohem lépe řešenou, ale stav je prostě takový, jaký je. Fyzické záznamy jako takové ale v history listu zůstávají. Máme tedy možnost vytvořit si vlastní řešení, která nám pomohou s historizací workflow, pokud jí nutně potřebujeme i za delší čas. Rozhodně tím ale neříkám, abychom staré záznamy v history listech ponechávali.
Jedny ze základních otázek, které bychom si měli klást, jsou ohledně reálných potřeb pro sledování historie workflow. Jak dlouho a zejména jakou historii vlastně potřebujeme? A pro jaké účely?

Kam tedy logovat pro účely auditování?

MS nám v tomto ohledu pouze říká, že history listy nemáme používat pro auditování. Nic jiného hotového a nativně použitelného s rozumnou ergonomií nám ale nedává, ani v SharePointu 2013.
Abych byl přesnější, MS doporučuje použít pro účely auditování workflow standardní mechanismus auditování SharePointu. Nicméně abychom tento mechanismus mohli použít, museli bychom si napsat vlastní provider. Následnou ergonomii při práci s reporty již jsem ochoten akceptovat (přeci jen jedná se o auditování). Hotový provider ale bohužel standardně k dispozici není.
Další možností je použít kompletně vlastní řešení. A zde si dovedu představit v zásadě dva druhy uchopení:
  • Místo logování do history listu prostě logovat někam jinam. Nejlépe pak do vlastní SQL databáze. Toto lze zapouzdřit do vlastní custom aktivity či jinou vhodnou formou.
  • Použít standardní history list, ale na událost dokončení workflow reagovat vlastním mechanismem, který data z history listu zkopíruje na jiné místo určené pro auditování. A opět se mi jako nejlepší jeví vlastní SQL databáze.
V obou případech lze dát oprávněným uživatelům k dispozici custom akci pro zobrazení auditních záznamů. A vlastně si dovedu představit kompletní vlastní řešení pro podporu auditování workflow, přeci jen jsem ale od MS očekával trochu více. Nintex Workflow tuto skutečnost sice částečně řeší (důležité informace o úkolech a jejich výsledcích udržuje ve vlastní SQL databázi a poskytuje vlastní řízení, tzv. „purging“), ale ani to není černobílé.

Archivovat a uvažovat tak, že „produkce“ je pouze dočasným oknem pro sledované informace

Po ukončení workflow je přirozené, že dané položky a informace o workflow jsou dále dostupné po nějakou (omezenou) dobu. Tato doba je závislá na konkrétních potřebách. Může se jednat o dny, týdny, ale i roky. Záleží na situaci. Přirozeně je však nutné uvažovat tak, že staré informace a data musíme buď archivovat, nebo smazat.
V rámci archivace nemusíme nutně uvažovat pouze v intencích přemísťování dat do archívu 1:1 tak, jak fyzicky existují. Můžeme klidně i změnit jejich podstatu a formu, tzn. u záznamů např. vygenerovat nějaký chronologicky orientovaný dump (nejlépe v XML – to pak můžeme pomocí XSLT dobře transformovat na požadovaný výstup), ten uložit do archívu a zdrojové záznamy smazat.
Smyslem tohoto článku není rozebírat vhodné struktury archívů, ale poukázat na nutnost tyto otázky reálně řešit a nesoustředit se jen na workflow jako takové. Není dobré uvažovat čistě aditivním způsobem. Musíme mít přehled, co se vlastně v rámci daného procesu děje, s čím vším daný proces souvisí, jaké jsou požadavky na performance a na časové odezvy (časová odezva nemusí vždy nutně vypovídat o komplexní performance aplikace) atd.
Odpadkové koše také vynášíme, resp. odpadky přemísťujeme do popelnic (a mnohdy měníme jejich formu), tak proč se tváříme, že v produkčním systému toto řešit nemusíme?

Snažit se věci maximálně zjednodušovat

Vyplývá z výše popsaných bodů. Opravdu, v jednoduchosti je síla. Mnohdy skutečně bývá jedním z hlavních a klíčových pilířů úspěchu celého projektu schopnost (a možnost) se se zákazníkem dohodnout na určitých kompromisech a zjednodušeních. A mnohdy opravdu nejde o to, že bychom něco neuměli v SharePoint workflow zrealizovat, ale prostě o to, že to není efektivní a v konečném důsledku bude daná „třešnička na dortu“ zákazníka vlastně jen omezovat.
SharePoint, byť je velmi schopný, není ERP systémem a nemá význam snažit se z něj udělat ERP systém. Nabízí nám toho opravdu hodně, ale je nutné umět správně „uchopit“ podstatu problému a vidět pilíře požadovaného řešení. A to není vůbec jednoduché. Chci říci zbytečně si tu realizaci nekomplikujme, nikoliv však z vlastní pohodlnosti.

Před plochým čistě aditivním uvažováním, tzn. nezájmem vidět a řešit komplexní rovinu problému, se nedá schovávat

Sebelepší produkt nevyřeší problém nekvalitní práce vývojáře nebo analytika. Jakmile jde v nějakém projektu o workflow, musíme vidět nejenom workflow jako takové, ale i další související aspekty, o kterých jsem se zmínil výše. Daný problém musíme prostě odbavit jako celek a musíme to tak sami chtít. Vlastní workflow je pouze jedna část celku. Potom jsme skutečně schopní zajistit určitou deklarovanou performance i z dlouhodobějšího pohledu.

Dostat workflow do dehydrovaného stavu co nejdříve po zahájení

Tedy např. jej uspat na krátký interval. Tím odpadne zátěž tohoto workflow v procesu w3wp, a tedy se na něj dále nevztahuje „throttle“ limit pro konkurenční běh/start workflow (blíže viz. odkazovaný MSDN článek). Naopak workflow se dále vykonává v rámci fronty workflow timer service, kde hraje roli pouze velikost dávky („batch size“) na jeden cyklus timeru a frekvence spouštění odpovědného jobu. Tento způsob umožní rychlejší konkurenční starty workflow za krátkou dobu a spravedlivější rozdělení prostředků serveru.
O cílovém workflow musíme znát nejen vlastní tok aktivit, ale i jeho bližší technické okolnosti. Umožní nám to optimalizovat dané workflow pro jeho konkrétní situaci.
Opět to však není úplně černobílé. Workflow, která ihned na začátku mají přímo dehydrující aktivitu (jako např. úkol), jsou z tohoto pohledu zcela v pořádku a není tedy vhodné je dehydrovat uměle. Navíc čím více aktivit se podaří „odbavit“ ještě před dehydrací, tím méně jich zbývá do následné fronty a to má kladný dopad na performance workflow, jejichž aktivity čekají na zpracování ve frontě. Tzn. zde to chce zdravě vyvážit, jsme-li v situaci, kdy to opravdu musíme řešit. Správně však není ani jeden extrém a záleží samozřejmě také na tom, co si můžeme s danou farmou dovolit.
U workflow nelze čekat (a není to jejich koncept), pracovat s přesností na sekundy (ani minuty). Jde primárně o procesy pracující delší dobu, kde nám v celkovém toku tolik nezáleží na několika minutách rozdílu oproti očekávání. Mimochodem článek MSDN dobře vysvětluje i rozdíly mezi workflow a event receivery a kdy by se měly používat z pohledu koncepcí, pro které byly navrženy.

Je nutné mít přehled, v jakém stavu a formě se farma nachází

Musíme se o to zajímat a mít o tom přehled. Existují-li nějaké nároky na performance, musíme vědět, jak jsou nastaveny parametry pro běh workflow ve farmě, zda byly měněny, kolik workflow se startuje a ukončuje za relevantní jednotky času, na kolika a na jakých serverech je spuštěna „workflow timer service“, jaká je průměrná zátěž farmy, jak daná zátěž vypadá ve špičkách (jsou-li tyto informace k dispozici) atd.
Většinou se nic nezkazí zkrácením výchozího 5-ti minutového intervalu „workflow“ timer jobu na kratší čas (minimálně 1 minuta), přičemž se ponechá standardní „batch size“ o 100 položkách. Ale opět to není černobílé. „Pomalou“ farmu nemá cenu trápit, protože by to ve výsledku vedlo k timeoutům, což by pro stabilitu workflow nemělo kladný přínos.

Nezapomínat na recyklaci poolů a tedy na to, že po recyklaci se deklarativní workflow musí znovu zkompilovat

V produkčním systému je velmi vhodné mít připravené určité „fire-up“ mechanismy, které zajistí „čerstvost“ a připravenost potřebných prostředků, v tomto případě workflow. Určitě všichni vnímáme vhodnost řešit tuto problematiku u produkčních aplikací z pohledu jejich UI, resp. prezentační vrstvy. Ale co workflow?
Deklarativní workflow, která tedy z podstaty nejsou „předkompilovaná“ v DLL knihovně, se musí při prvním použití (a nemusí se přitom jednat o nové spuštění) zkompilovat z deklarativní formy (XOML) do binárního obrazu. A tento proces určitě není nejlepší „absolvovat“ v pracovní době během největší zátěže serverů, když navíc uživatel očekává rychlejší odezvu na svou akci. Pro opravdu malá workflow ano, proč ne, zde o nic nejde. Ale u workflow s větším počtem aktivit je situace jiná.
Můžeme jí řešit různě. Jedním ze způsobů je „fake“ položka / dokument, tedy „fake“ událost, která si vynutí „fake“ start workflow a tedy jeho fyzické zkompilování. Samozřejmě se bavíme o čase po provedení recyklace aplikačního poolu dané webové aplikace a na to dnes máme páky. Pokud se nám tento způsob zdá nešikovný s ohledem na business logiku daného workflow (např. se v rámci toku odesílají v tomto případě nežádoucí notifikace atd.), můžeme do iniciačních parametrů zavést proměnnou udávající „fake“ start a následně jej ošetřit v samotném toku daného workflow (poslat přímo na konec atd.).

Testovat a optimalizovat

Opravdu se nejedná o prázdná slova. V článku MSDN se dočteme o nutnosti testovat a optimalizovat a o důvodech, proč to dělat. Např. zvýšení parametrů ovlivňujících performance workflow nemusí mít nutně za následek reálné zrychlení, ale spíše naopak. Pokud opravdu realizujeme projekt, kde se počítá se stovkami až tisíci konkurenčními (nyní myšleno spuštěnými „In Progress“) instancemi workflow, měli bychom v rámci projektového plánu zcela automaticky počítat s pracností na performance testy a ladění.

Pro velké objemy workflow běžících ve farmě je dobré častěji recyklovat OWSTimer (SPTimerV4) service

Je prokázáno, že to zlepší performance. Tato služba se může po delším běhu „zpomalovat“. Zdaleka na ní nejsou závislá pouze workflow, ale prakticky vše v SharePoint farmě. Recyklovat i po několika hodinách není ostuda. O automatickou recyklaci se stará timer job nazvaný „Timer Service Recycle“.

Farmy s velkým počtem běžících workflow si zaslouží více hardwarových prostředků

Chceme-li za deklarovaný čas překonat určitou vzdálenost po určité silnici, přičemž vezeme určitý náklad (a chceme samozřejmě dodržovat dopravní předpisy), musíme jet minimálně takovým a takovým vozem.

Možná trochu nešikovně popsáno, ale hlavní myšlenka je zřejmá. Pokud někde budeme řešit performance problémy workflow, přičemž blíže nevidíme do vlastní logiky dané aplikace a nemáme na to ani čas, ani zdroje, podívejme se (kromě jiného) na to, co dělá procesor, paměť a další hardwarové zdroje. A to nejen na SharePoint serverech, ale i na SQL serverech. Možná nám pomůže „trochu jim přidat“. Není to však samoúčelné. Zajímejme se o danou farmu a aplikaci komplexně.

Administrátoři nás nesmí nechat na holičkách

Není tajemstvím, že pokud content databáze nemůže růst a z určitých důvodů narazí na strop, instance workflow mohou popadat. Takže administrátoři musí provádět proaktivní monitoring farmy, obzvlášť pokud provozujeme kritické aplikace. SharePoint je sice nástroj (velmi schopný), ale je to také organismus a tak je potřeba k němu přistupovat.

Závěr

Abych body výše nějak shrnul do úderného závěru, nenapadá mě nic lepšího, než zkrátka apelovat na všechny SharePoint analytiky, architekty a vývojáře, ale i na uživatele:
  • zajímejme se o širší kontext řešeného problému – má své důsledky,
  • zajímat se nestačí, buďme proaktivní a před možnými problémy se neschovávejme,
  • buďme ochotní ke změnám a kompromisům a snažme se vidět hlavní pilíře řešeného problému.
TAGS:
Share:
0 comments on SharePoint Workflow Performance (model 2010)

Post a comment

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Tato stránka používá Akismet k omezení spamu. Podívejte se, jak vaše data z komentářů zpracováváme..