Sizing an Oracle WebCenter Content deployment

Who this is for

The infrastructure or middleware lead who has been asked how many CPUs and how much disk a WebCenter Content deployment needs — for a new build, a 12c to 14c upgrade, or a move to OCI — and wants a number that will still be right in year three.

Why the spreadsheet is harder than it looks

Sizing WebCenter Content is one of those exercises that looks trivial until you try to fill the cells in. The number depends on questions nobody asked at kickoff: how many environments you really run, which components sit on which node, what the storage grows into over five years, and where the content actually sits — filesystem, database, or a mount shared with a component two tiers away.

We have sized WebCenter Content for organisations up to a federal legislative body, and the pattern that produces a defensible figure is always the same. You do not size a server. You size a topology: a set of node roles, replicated across a set of environments, each with a storage growth curve, and you are honest about the two or three line items you cannot pin down until you have the content profile.

Start from node roles, not machines

A production-grade WebCenter Content deployment is a small constellation of cooperating roles, and each has its own resource shape.

• Oracle HTTP Server (OHS). The web tier in front of the cluster. Light on everything. Two instances at roughly 4 vCPU and 4 GB each, with a small fixed disk footprint — tens of gigabytes for the web server and its logs, not content.
• WebCenter Content managed servers. The core: Content Server, the Content UI and Inbound Refinery. These are the heavy nodes. 4 vCPU and 16 GB is the working baseline, rising to 8 vCPU for the higher-throughput environments. Run at least two in production if availability matters; that is not negotiable.
• WebCenter Enterprise Capture. The ingestion tier for scanned and imported documents. Lighter on memory than the content nodes — 4 vCPU and 8 GB is a sensible node — but run as a pair, because capture throughput and resilience matter when documents arrive continuously.
• WebCenter Forms Recognition (WFR). Different in kind. It runs on Windows Server with the .NET runtime, not on the Linux the rest of the stack uses, and it wants memory — 16 GB — because recognition workloads are RAM-hungry. Budget it as its own machine with its own operating-system licensing line.

Size by role because roles scale independently. Content nodes may need to double for a heavy-write environment while OHS stays flat. Collapse everything into "a WebCenter server" and you cannot reason about that; you either over-provision the web tier or starve the content tier.

The environment multiplier everyone under-budgets

The single biggest miss in WebCenter Content sizing: people size Production and forget that Production is one of four environments they are about to pay for.

1. Development — where configuration, components and customisations are built.
2. Test — where they are validated, on a topology close enough to Production to mean something.
3. Training — routinely overlooked and routinely not small. Training a large user population drives real load through it during sessions.
4. Production — the one everyone remembers.

In the federal-scale exercise we ran, all four environments carried the same node topology: the same OHS pair, the same two content nodes, the same Capture pair, the same WFR machine. What differed was CPU on the content nodes. Development and Test ran them at 4 vCPU; Training and Production ran them at 8 vCPU. That is the calibration that matters. Training got production-grade CPU because it had to survive a room of simultaneous users, not because the estimate was padded.

Multiply the per-node sizing by the real environment count before a total goes to finance. One content node at 8 vCPU and 16 GB looks inexpensive. Sixteen of them across four environments, plus eight OHS instances, plus eight Capture nodes, plus four WFR Windows machines, is a different conversation, and it is the true one.

Storage: size in tiers, not in one guess

Nobody knows their five-year storage number on day one, and pretending otherwise produces a figure that is wrong in one direction or the other. Size storage in low, medium and high tiers and let the organisation choose a growth assumption it can defend.

For the compute nodes this is straightforward. The OS-plus-application footprint per Content or Capture node lands around 30, 60 or 100 GB for low, medium or high: boot volume, middleware, logs and headroom. WFR is similar. OHS is smaller and roughly flat across tiers because it does not grow with content.

But compute-node disk is not where the content lives, and this is what trips people. The documents, renditions and metadata sit in three other places, each its own capacity line.

• The cluster's shared file system. A shared volume the content nodes mount in common so a clustered Content Server has one view of its configuration and shared files. A small allocation, distinct from per-node disk.
• The Vault and Weblayout. The stored documents (Vault) and their web-viewable renditions (Weblayout). Depending on configuration these live on a filesystem or, with database storage enabled, inside the database via JDBC. This is the line that grows without bound.
• The NFS mount between Capture and Forms Recognition. The handoff volume where scanned batches wait for processing. Small relative to the Vault, but real, and easy to forget because it spans two tiers.

The two lines that stay open, and why that is correct

In the sizing document behind this guide, three storage lines were deliberately left as question marks: database JDBC storage for Vault and Weblayout, the Capture-to-WFR NFS mount in some environments, and the precise shared cluster allocation. That is not sloppiness. It is honesty about what cannot be known without a content profile. To size the Vault and Weblayout you need three numbers only the business can give you:

1. Average document size. A page of scanned TIFF is a different world from a native PDF or an Office document, and the mix drives everything.
2. Ingestion rate. Documents per day or month — including any historical backfile migration, which is often an order of magnitude larger than the ongoing rate.
3. Retention. How long content lives before disposition. For a public-sector or records-managed environment that can be decades, which for planning purposes means "forever."

With those three, the Vault line stops being a question mark. Without them, a responsible sizing document flags the unknown rather than inventing a number, because a fabricated storage figure is the one that breaks the budget in year three when the backfile lands.

A worked baseline to start from

The per-environment topology we would put on the table for a mid-to-large WebCenter Content deployment. Raise content-node CPU for the high-load environments and multiply across the environment count.

Run that across Development, Test, Training and Production, hold the content nodes at 4 vCPU for the two lower environments and 8 vCPU for the two higher-load ones, and you have a defensible compute number. Then size the content-bearing storage separately, from the document profile, once you have it.

Size for the 14c target, not a standstill

If you are sizing WebCenter Content in 2026, you are doing it against the Fusion Middleware 12c support timeline: Premier Support for 12.2.1.4 ends December 2026 and Extended Support December 2027. WebCenter Content has a 14c release (14.1.2), and the sensible move is to size the infrastructure toward that target rather than for the release you are on today.

The topology above carries directly to a 14c deployment. The node roles are the same and the roles-times-environments-times-storage-tiers logic is release-independent. What changes is that you right-size on current operating-system, database and WebLogic baselines instead of inheriting whatever the original 12c build assumed. A sizing exercise is the ideal moment to bake the 14c target in, because the infrastructure question is already open. Doing it once, with the runway in view, beats sizing for standstill and re-sizing in eighteen months. The out-of-place 12c to 14c upgrade needs the new topology stood up beside the old one, so the sizing feeds directly into that plan — and if the target is OCI, the repository-to-OCI guide covers the shape and storage service choices.

How ECMWorks does this

We run the sizing as a short, structured exercise: confirm the node roles and environment count against how the estate is actually used, set the per-role compute from the baseline above and adjust for throughput evidence from the current system, size compute disk in tiers, and produce the content-profile questionnaire that turns the open storage lines into numbers. The output is a topology and capacity document that infrastructure can procure from and that feeds directly into the 14c upgrade or OCI migration plan. Where a current estate exists, we read its actual Vault growth, Inbound Refinery load and Capture throughput rather than estimating them.