UCM 11g, 2. část: škálování a výkon

Minulý článek jsme zakončili tvrzením, že jedním z největším přínosů verze 11g je velký posun ve výkonu a možnostech škálování celého řešení.

Co se tím přesně míní? Pro výkon ECM řešení jsou důležité především 2 operace:

• vkládání nového obsahu
• schopnost zobrazit požadovaný obsah

Při vkládání je výzvou zejména jednorázové vkládání mnoha, relativně krátkých položek, které je třeba stejně rychle dát k dispozici uživatelům (opačný extrém, tj. vkládání velkých položek se moc optimalizovat nedá, protože závisí primárně na průtoku sítě). Typickým případem ze skutečného života může být zpracování emailů či např. vydaných faktur (na toto téma např. tento článek).
Pro poskytování obsahu je náročné zvládnout zejména scénář obsluhy dynamických webových stránek pro velkou komunitu uživatelů (public web).

Detailní výsledky je možné najít v tomto dokumentu a jsou skutečně impozantní. Např. na poměrně běžném hardware (2 CPU 2.33 GHz Xenon, 16 GB RAM) dosahuje UCM 11g pro soubory o velikostech 4-200 kB rychlosti vkládání 270, resp. 128 souborů za sekundu, to je 11-23 miliónů dokumentů denně na jednom uzlu UCM 11g!

Čím jsou takové rychlosti dosahovány? Hlavními přispěvovateli jsou databáze Oracle 11g (zejména technologie Oracle SecureFiles) a pak Fast Checkin mechanismus UCM, který umožňuje některé generické funkce (konverze, zahájení workflow, indexace na fulltextové vyhledávání) vypínat pro ty dokumenty, pro které to nemá smysl - např. TIFF vytvořený skenovací linkou nemá smysl ani konvertovat, ani indexovat.

A pokud by Vám dosahované hodnoty stále nestačily, je možné nasadit Sun Oracle Database Machine (Exadatu), na které je možné se dobrat až takových hodnot jako 1060 dok./sec (91 mil. denně) na 1/4 Exadaty, resp. 2070 dok./sec (179 mil. denně) na 1/2 Exadaty - testy byly prováděny se 100kB soubory.

Při poskytování webového obsahu se plně využívá Weblogic Server. Technologie "Open WCM" využívá tzv. smart caching - tj. webový objekt je z UCM přenesen přímo na Weblogic Server, kde setrvává, dokud jej UCM neprohlásí za neplatný. V jiném modelu je možné proaktivně vyspecifikovat, které objekty se takto mají cachovat přímo v rámci implementace site.
Tyto mechanismy lze ještě doplnit o cachování na proxy, kde se ukládají celé stránky.
V testech se kombinací dosahovalo výsledků až 124 stránek za sekundu (na komoditním hardware).

Při škálování, čímž se zde míní provozování na více uzlech clusteru, je pak žádoucí, aby režie clusteru byla co nejnižší, tj. aby byla investice do dalšího hardware co nejvíce využita. V tomto ohledu dokument příliš specifický není - jen zmiňuje, že UCM 11g dosahuje průměrného poměru kolem 95% (tj. 5% výkonu je spotřebováno režií clusteru). Zde záleží především na výběru operačního systému - pro Windows je režie větší, např. pro 128 uzlů Solaris byla režie jen kolem 2%.

(pokračování někdy příště)

Sizing Oracle UCM

Tato otázka se objevuje neustále. Vlastně je až skoro zarážející, že jsem tento článek nenapsal mezi prvními: jak správně určit počet CPU produktu Oracle UCM, tj. "nasizovat" řešení za určitých podmínek (nejčastěji se objevují počty uživatelů, dokumentů atd.)?

Předně budiž řešeno evidentní:
1) Oracle UCM se prodává ve dvou licenčních modelech:

• per NUP (Named Users Plus), tj na počet uživatelů užívajících produkt (i kdyby to mělo být jen jednou za čas!!!); u tohoto způsobu je irelevantní, na jaké "železo" se produkt nainstaluje, protože však jedna CPU licence cenově odpovídá 50 NUP, dá se předpokládat, že NUP model bude spíše jen pro opravdu malé projekty či prostředí specificky zaměřené (vývojové, testovací apod.)
• per CPU

2) metriky zaměřené na obsah (počty dokumentů, jejich celková velikost apod.) rovněž nemají vliv na počet CPU Oracle UCM - mohou (a nejspíš budou) však mít vliv na počet CPU podpůrné databáze (o roli databáze v ECM řešení viz tento článek), velikost úložného prostoru apod.

K této oblasti přeci pár poznámek:

• při počítání nutného prostoru pro úložiště nesmíme zapomínat na verzování; pokud se tedy nejedná o řešení převážně pro dále neměnné dokumenty (skeny, datové zprávy apod.), musíme velikost vynásobit ještě koeficientem počtu verzí ke každému dokumentu. Pokud nebudete mít lepší odhad, užijte konstantu 2,5.
• při konfiguraci databáze (zejména v modelu, kdy db neslouží k ukládání obsahu) bychom neměli zapomenout na přidělení prostoru (tablespace). Pro objekty v db (kterými může být cokoli - od definice metadat či struktury folia, přes uživatele, po specifikaci konfigurace přenášené komponentou CMU) pak užijte pravidlo, že na každých 50.000 objektů by databáze měla mít přiděleno 100 MB tablespace

Jak to je tedy s těmi CPU?
UCM má v podstatě roli aplikačního serveru. Jeho výkon se tedy určuje dle počtu transakcí, které musí zvládnout za nějaký časový údaj (zpravidla za sekundu). Už v této větě se skrývá určité riziko, protože některé z transakcí jsou "dražší" (mezi "drahé" transakce patří např. vyvolání konverzí, zejména pokud běží online, jak to dovoluje např. komponenta Dynamic Converter; ještě dražší transakcí je pak např. spuštění Batch Loaderu pro hromadné nahrávání většího množství položek obsahu najednou).
Nicméně, pokud opět nemáte lepší odhad, počítejte, že jeden CPU zvládne 5-25 transakcí za sekundu za GHz výkonu.

Př. organizace vlastní quadcore o 3GHz - celkem tedy má výpočetní kapacitu 12 GHz, což nám dává až optimistických 300 transakcí za sekundu (pokud je primárním vyhledávání či přímý přístup na dokumenty v úložišti)

Co s tím dál? Počet transakcí za sekundu nám asi nikdo do požadavků nedá - pokud se nedá zjistit z nějakého existujícího řešení - nejbližší použitelnou metrikou je počet současně pracujících aktivních uživatelů, což už je zpravidla dohledatelný údaj. Za aktivního uživatele se považuje ten, kdo dokáže udělat zhruba 5 transakcí (kliknutí) za minutu.

Př. výše uvedená organizace odhaduje, že systém bude užívat max. 200 současně pracujících aktivních uživatelů (celkové číslo NUP může být klidně až o řád větší!) - tito uživatelé tedy vygenerují odhadem 200 už. x 5 trans/min / 60 sec = 17 transakcí/sec, jinými slovy, tuto zátěž zvládne 1 CPU UCM (pokud by se ovšem nejednalo o UCM SE, počítal by se licenční počet CPU dle jader, což by u většině typů fakticky znamenalo 2 "licenční" CPU) na výše uvedeném serveru s prstem v nose (s rezervou na 4-18x větší zátěž).

Tyto úvahy také odpovídají na otázku co dělat, když potřebujeme zvýšit výkon. Metoda první volby je samozřejmě (surprise, surprise) - posílit hardware...

V českých podmínkách bude primární motivací pro nákup většího počtu CPU spíše požadavek na dostupnost.

Poznámka k active-active clusteringu
Při sběru materiálů na dnešní článek jsem narazil ještě na jednu docela zajímavou poznámku týkající se active-active clusteringu. Jedná se o čistě empirický poznatek, že u operačního systému Windows bere na clusteru se 2 nody režie clusteringu zhruba 5% výkonu a na clusteru se 4 nody dokonce celých 20%. Naopak při realizaci clusteru na Solarisu byl pokles výkonu řešení až se 128 nody někde na hranici 2%.

Jinak, rovněž jsem našel informaci, že s verzí 11g přijde i metodický dokument, který bude problematiku sizingu popisovat s mnohem větší mírou detailu. Tak se budeme těšit...