Site Map

Wondering why your sever sizing estimates are invariably way off the mark? We help model your application workloads using quantitative models so that your server sizing has a scientific basis.

Predict Before You Deploy

Why is it that most performance tested apps fail soon after they are deployed? We use established yet simple models to extrapolate test results to the live environment, so there are no surprises after you deploy.

Define Before You Design

Are you merely recording user performance requirements? Or are you truly defining them? We bring statistical SLA-based techniques to performance requirements definition so you don't get burnt.

Diagnose Before You Tune

Are you burning up effort, money and time tuning your servers endlessly without tangible results? We help you determine what to tune before you tune, so that your next buck is spent where it yields the most bang.

Science. Not Serendipity

We use established and proven quantitative models and methods to analyze, diagnose, predict and baseline. We don't rely on cowboy techniques.

Experience. Not Evangelism

With 17+ years of field experience apiece, we know what works and what doesn't. We don't burden you with processes or frameworks to get it done.

Reuse. Not Reinvention

We don't invent our own techniques, and neither do we reinvent the wheel. You get "unfashionable" approaches that have been proven to work in the field.

Are you connected with IT decision-makers who could use our expertise? Make a referral and get paid handsomely! Write to us for more information.

A custom ASP.NET drilling DSS for one of the world's leading geothermal energy firms is dogged by UI performance issues.

PEA redesigns crucial sections of graph-drawing code and reduces response times by 80%.

The world's second largest two-wheeler manufacturer is anxious about the performance of its Siebel dealer management system.

PEA, called in to review their Big-4-authored performance test strategy, finds serious loopholes.

A product firm faced with a large and heterogeneous client base wants to optimize its sizing approach for unpredictable and bursty traffic.

PEA uses scientific modeling and extrapolation methods to build a robust capacity model for them.

The Performance Engineering CoE of a worldwide leader in industrial automation runs into rough weather.

PEA, called in to conduct an assessment, reviews the entire gamut of activities from strategic planning to the quality of Loadrunner scripting.

A serious performance problem threatens the release of one of the world's best known middleware products.

PEA, working remotely, performs their characteristically speedy diagnosis and isolates the bottleneck in a day.

One of North America's leading healthcare product firms runs into trouble with a performance baselining exercise.

PEA redefines the baseline exercise and gets them out of a sticky situation.

Performance Engineering. Done Differently.

Welcome to Performance Engineering Associates. We specialize in Performance Engineering for IT Systems. Why are PE practices at large corporations consistently ineffective, despite the best investments in technology, tools, processes and vendors? In a world of rapidly changing technology platforms, the most persistent performance issues are largely cross-platform in character: remarkably, the techniques used for the diagnosis and resolution of most performance issues do not depend for the most part on the specific brand of app server you use, or the specific flavor of hardware your app runs on. Or, for that matter, on the special breed of monitoring tool you love. We help you discover and exploit this remarkable real-world truth.

Explore our website to learn more about what we can do for you. In a hurry? Why not call or email us? You'll actually get sensible scientific advice, not a sales pitch - and it costs nothing.

NFR

Common Practice

Ask users what average response times they expect or desire. Worse, ask what the "maximum" response time can be. Document these as response time guarantees or SLAs. Then draw some pretty pictures in a nice expensive CASE tool.

Our Approach

Build a quantified model of response time tolerance. Use this to arrive at multiple percentile limits tied to multiple response time maximums. Define guarantees and SLAs tied to these maximums.

Sizing

Common Practice

Use past experience and intuition to choose a reasonably good-sized box. Add or subtract a few CPUs based on some handwaving logic. Memory is cheap, so double it. Then throw in a load balancer and say "good to go."

Our Approach

Use a statistical workload model built during NFR. Measure or estimate transaction service demands at CPU and disk. Use benchmark figures such as rPerf or TPCC to quantify relative box capacity. Use mathematical formulas to account for variations.

Testing

Common Practice

Buy an expensive load test tool. Have a thousand users? Buy a thousand vUser licenses. Get fanatic about ramp-up and ramp down slopes. Set up think times that randomly vary. At the end, wonder why the system crashed with only 100 vUsers.

Our Approach

Compute the required number of vUsers based on the workload model. (Have 1000 real users? You probably need only 100 vUsers.) Adopt transaction arrival rate mix as the test target rather than user number. Use a Monte-Carlo method for load generation.

Benchmarking

Common Practice

Run a benchmarking performance test for your product for each distinct operational workload profile. Do so by setting up a test environment that is as close as possible to the live environment. Wring your hands in despair for each small profile or environment change.

Our Approach

Create a reference workload model. Model operational profiles as variants of the reference. Create a reference test environment. Model test environments as variants of the reference. Create one reference benchmark test. Extrapolate results to multiple live environments and operational profiles.

Monitoring

Common Practice

Invest in expensive enterprise monitoring tools. Measure a million metrics. Ask the tool to generate fancy graphs, charts and tables. Shrug helplessly when asked "Where is the bottleneck likely to be 6 months from now?"

Our Approach

Use standard tools to log a handful of system and application level metrics. Conduct offline analysis on selected metric ratios to spot software scalability issues. Perform scientific extrapolation of utilization and throughput to predict the location of the next bottleneck.

What-If

Common Practice

What if the number of accounting users doubles? Buy more vUser licenses. What if we scale out the application server? Assume that the response times will halve. What if we upgrade the Web server? Ask the hardware vendor.

Our Approach

What if the number of accounting users doubles? Conduct a sensitivity analysis of the statistical workload model. What if we scale out the application server? Analyze service demands and throughput values to predict the results. What if we upgrade the Web server? Use TPC benchmarks to quantify the effect.

...and Strategy

Common Practice

Hire a Big 4 consultant or a CMMi L5 IT vendor. Get them to make snazzy presentations. Adopt a couple of 500-page industry-standard frameworks or processes. set up a Steering Committee, a PMO and a Governing Body. Draw a fancy org-chart. Then wonder why nothing changes.

Our Approach

Convince you that strategy and engineering go hand in hand. Abstract the elements of engineering to make it understandable by senior management. Demonstrate why simple, 1-page engineering techniques yield better results than 10,000-feet strategies. Charge you less than the big boys.