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...