Siebel CRM Credit Approval System: 2.5× Faster, Scaled to 10,000 Users

Sona Hakobyan

Author

Sona Hakobyan

Sona Hakobyan is a Senior Copywriter at PFLB. She writes and edits content for websites, blogs, and internal platforms. Sona participates in cross-functional content planning and production. Her experience includes work on international content teams and B2B communications.

Senior Copywriter

Reviewed by Boris Seleznev

Reviewed by

Boris Seleznev

Boris Seleznev is a seasoned performance engineer with over 10 years of experience in the field. Throughout his career, he has successfully delivered more than 200 load testing projects, both as an engineer and in managerial roles. Currently, Boris serves as the Professional Services Director at PFLB, where he leads a team of 150 skilled performance engineers.

Why Siebel is expensive to load test

Siebel punishes the standard approach in a specific way: its traffic is extremely sensitive to interface changes. A live system receives improvements, blocking-bug fixes, layout changes, patches and hotfixes continuously - and each one can invalidate load scripts that were correct yesterday.

Two properties make this worse:

• Opening a single arbitrary page generates more than 90 requests.
• Neither JMeter nor LoadRunner can work out which parameters need to be passed between those requests, so correlation has to be done by hand.

The result is scripts that are laborious to write and go stale almost immediately. That is the cost driver, not the testing itself.

What we built

FiddlerToJMeter - a plugin that automates the routine part of the work. The tester specifies which values to parameterise; in one click the plugin produces a ready-to-run JMeter script from recorded traffic. Script creation time dropped sharply, and with it the cost of every subsequent test round, without giving up script quality.

Siebel traffic: over 90 requests for a single page.

The JMeter plugin built to record and parameterise that traffic.

Traffic parameterisation, automated.

The results pack from the Siebel CRM runs.

The plugin outlived the project: it is now part of PFLB's load testing tooling.

An emulator for the external system. The original plan was to reuse the functional testing environment where the external system was already deployed. After a series of tests that bench proved too weak to load Siebel at all - it became the bottleneck instead of the system under test. So the team built an emulator that answers requests with the delays characteristic of production, which removed the false ceiling.

How the load model was built

Real user scenarios in a credit system run through many stages, so the team built status transition diagrams for requests and used statistics to determine what percentage of requests took each transition. User behaviour was analysed from production statistics, and separate load profiles were built for different times of day and for peak periods. All of it was documented as a load testing methodology rather than left in scripts.

Results

• 25+ load testing iterations completed.
• 5 performance-affecting issues found.
• Database analysis and optimisation delivered a 2.5× performance improvement.
• Performance indicators were established that let the business plan for scaling to 10,000 simultaneous users - the question the transformation actually needed answered.

Questions this engagement answers

Why is Siebel harder to load test than a typical web application?

Because a single page opening generates 90+ requests, standard tools cannot infer the parameters to correlate between them, and the traffic breaks whenever the interface changes - so scripts need constant rework unless the recording and parameterisation are automated.

What do you do when the test environment is weaker than production?

Stop testing the environment. Here the shared functional bench could not generate enough load, so an emulator replicating production response delays replaced it.

How do you plan for a demand increase you have not seen yet?

Establish performance indicators against a defined target - in this case, evidence that the system supports 10,000 simultaneous users before the transformation drove the traffic there.

Is a 2.5× improvement typical?

It came from database analysis and optimisation, not from adding hardware. Whether the same margin exists elsewhere is exactly what a first round of testing tells you.