Slow estate?
Most OpenText estates don’t slow down because of the hardware.
Fourteen years of production casework say the same thing: it is configuration, chattiness and ownership. The slow save, the clean database report, the search that degrades month by month. Each has a measurable cause, and it is almost never the one that gets bought first.
Where the time actually goes
Share of performance-related support traffic across the estates we have worked on, 2012–2026. Approximate and anonymised.
Not on this chart: slow SQL plans, undersized CPU, insufficient memory. In fourteen years of casework these are almost never the cause. They are almost always the first thing bought.
The three failure modes
Three patterns, one method. Each one measured, root-caused and fixed at the cheapest layer.
Every number below is from our own production casework. Client identities are never published.
Failure mode one
Fast disks, slow saves
3–4×slower saves in production than in test, with the archive tier idle
Symptom. One attachment: 270 ms in test, 810–840 ms in production. A mail with nine attachments takes eight seconds to file.
What we found. The engine was fast: 18 ms open, 78 ms save. The storage path was not: 64 KB mount sizes where 1 MB belonged, sixteen round trips to write a megabyte, access-time updates on every read. A “helpful” buffer volume made it 16% worse.
The fix. Mount configuration and a restart. Not a project. The lowest-risk change on the board.
Failure mode two
Fast queries, slow application
49 sfor one routine save, on a database with a clean report
Symptom. No bad plans, no waits, queries fast. Routine operations still take tens of seconds.
What we found. One save issued ~15,000 statements at ~2.5 round trips each. On the application’s actual path, 1.3 ms instead of 0.49, that is forty-nine seconds of pure network wait. No index, CPU or memory changes that number.
The fix. Commit per business operation. Shorten the wire, and measure it with a probe. Where a code path is that chatty, work it with the vendor and fix it at source.
Failure mode three
“The system feels slow”
Month by month
Symptom. Search degrades too slowly for a ticket. Containers hold thousands of workspaces and browse crawls. Every facet count is a query per click. The first users after a restart pay the cache warm-up.
What we found. Object counts past the year-one design assumptions. Index maintenance assumed, not scheduled, and nobody owns it. “Perceived speed” falls between the application team and the infrastructure team.
The fix. Scheduled index maintenance sized to the change rate, capped container growth, trimmed query cost, scripted warm-up in every restart runbook.
Send us a day of logs
Upload one day of logs and a system report. We run the analysis and tell you which of the three you have.
Three files decide most “mystery” slowness before anyone opens a ticket with anyone: the timings and thread logs, the connect logs for the same day, and a system report. You already have all three. Nothing is installed, nothing on the estate changes, and you get a one-page verdict you can put in front of any team.
Encrypted upload. Logs are read only for this analysis and deleted within 30 days of the verdict. Strip user names first if your policy requires it; the timings work without them.
Timings and thread logs, one working day
The timing pairs tell us engine time against storage time for every open and save, and which operations issue the most statements. This is what separates failure mode one from failure mode two.
Connect logs for the same day
Connection and pool behaviour, statements and round trips per business operation. Multiplied by the round-trip time on the application’s actual path, this predicts the wall-clock time exactly.
System report
Mounts and storage options, JVM and memory, database and version currency, index and container statistics. This is where the configuration cause usually sits, and where the cheap fix is.
Sample verdict
timings (1 day) open 18 ms save 78 ms storage 610 ms ← mode ONE connect logs 14,920 statements per save, commit per statement app→db rtt 1.31 ms on the actual path (0.49 ms available) predicted wait ≈ 49 s per save observed 51 s ← mode TWO system report NFS rsize/wsize 64 KB, relatime on; index defrag: none scheduled verdict configuration, not capacity: three cheap fixes first
You get the verdict and the three cheapest fixes, in writing. No obligation. If the logs show nothing worth paying for, we say so.
The method, every time
Measure before touching. Prove the cause. Fix at root. Retest with the same numbers.
Measure
Timing pairs in service logs beat every opinion in the room.
Prove
Do the arithmetic. RTT × round trips predicts most “mystery” slowness exactly.
Root cause
The problem usually lives in the seam between platform, database and infrastructure, where each team correctly says “not ours”.
Fix
Cheap configuration wins first: mounts, commits, maintenance. Architecture second.
Retest
The same numbers that proved the problem prove the fix. Before a migration, replay a production hour against the target.
When you want it done for you
The Estate Continuity Review
The live production estate, reviewed with the method above: platform, the database underneath, ownership, patching and version currency, single-person dependency. Two weeks elapsed, five senior days, a fixed price agreed before we start, and the fee credited in full against the first remediation or the first quarter of a managed service. Review only: nothing on production changes.
You get
Written findings report
You get
Ranked remediation plan
You get
Walkthrough with the estate owner
Start with 45 minutes, free.
A continuity check call: you describe the estate and what worries you; we tell you whether a review would find anything worth paying for. If it wouldn’t, we say so.
Senior-led. Named engineer, not a ticket queue.
On-premise and private cloud. Content Server, Extended ECM, OTDS, Archive, Records Management, Oracle and SQL Server.
14+ years
on Content Server, Archive Center and Extended ECM, across the application, the database and the infrastructure.
Not allowed to fail
Central banking, defence, pharmaceuticals and insurance. Estates that hold the records the business has to produce on demand.
Munich, 2026
This method was presented at the AnswerModules User Group, September 2026: “Recurring performance failure modes.”
One team, one SLA
Platform, business administration and database run as one service, alongside your specialists, never replacing them.