When Open UI performance goes wrong

Open UI performance problems rarely arrive as “Siebel is slow.” They arrive as one applet, one view, or one button that used to return before the user looked away. The useful response is a short isolation. A new server is a later conversation, and usually the wrong one.

This order assumes a view someone can reproduce. If you cannot reproduce it, you do not have a performance project yet. You have a complaint.

Separate the wait

Watch one person do the slow thing once. Record three times from that same action:

• Time until the view shell appears.
• Time until the applet has rows.
• Time until a specific action returns: a button, a drilldown, or a save.

Those are different code paths. A slow shell is often manifests, controls, and files the browser must fetch. A slow applet is often the query behind the list or the form. A slow button is often the method the presentation model invoked, and the business service or workflow under it.

Write down the view name, the applet name, and how many rows the user expected to see. Those three names are the ticket.

Look at the browser before the database

Open the network panel on a cold load and again on a second load of the same view.

• Count the files the manifest pulls for this view. A presentation-model or physical-renderer override that imports a large library on every applet will show up here, including on applets that never use it.
• See whether the same files are requested again with cache-busting query strings on every navigation.
• See whether a third-party control initializes on a view that never displays it.
• Find the one request that dominates. Note its URL, the Siebel method, and the size of the response. A list applet that returns far more columns, or more child data, than the UI shows is a common shape.

Then read the console. A renderer that throws and retries, or that rebinds events on every refresh, looks like a slow server and will not appear in a SQL trace. Fixing the server while the browser is looping is how a week disappears.

Then the query

When one request dominates, trace that request before anyone resizes a connection pool.

• The business component, and the search spec the applet sent, including one that differs from last year’s repository screenshot.
• The sort spec, and whether the user is sorting a column that is not selective.
• Joins and multi-value groups the list does not display and still evaluates.
• A picklist or association applet that queries on every keystroke.

Capture a short trace against the click you reproduced. Turn it off. Leaving every Siebel performance log on in production for a week produces a file nobody will read and a system that is slower than the one you were asked to fix.

EIM and workflow slowness are a different afternoon. Do not mix them into an Open UI ticket because both “feel like Siebel.” If the slow part never paints a screen, start from the workflow step or the EIM process instead of from this list.

The method the click actually calls

From IP2014 onward, a button the user trusts may not be the method the repository still lists. An override in the presentation model can replace it, wrap it, or swallow it. When a click is slow, or a click does nothing:

• Confirm which method the click invokes in the running model, not only in Tools.
• See whether the override calls the base method once, or calls it and then refreshes the whole view.
• See whether the override waits on a second service call the old high-interactivity applet never made.

A missing button and a slow button are neighboring problems. Both live in the manifest and the model. Restarting a web server does not answer either one. The same is true of a physical renderer that re-queries on every field change because that was the fastest way to make a demo work.

What not to do first

• Do not add hardware because a single view is slow for one team.
• Do not drop the user’s row count to ten if the business process is a queue. Change the query or the columns.
• Do not treat a script timeout as proof the database is fine. It is proof something in that click did not return.
• Do not start a repository cleanup in parallel. You will not know which change helped.

A stopping point

Isolation is finished when you can say one of these with a name attached:

• This file, on this view, on every load.
• This business component search spec, for this applet.
• This presentation-model method, which calls this business service.

That sentence is the scope. Siebel CRM work here starts from it. A program to “tune Open UI” with no view attached spends a month without a result you can show a user.

Write-ups of specific IP2014 breakages — buttons that moved, methods the presentation model no longer called — are on Bloomspire and linked from Resources as external reading. This page does not republish them.