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 15 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.

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

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

A worldwide leader in industrial automation wants to set up an IT Performance CoE.

PEA provides strategic advice and licenses its methodology packs for technology transfer.

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

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

A start-up wants to include performance testing in their service portfolio.

In a crowded marketplace, PEA strategizes the USPs for their new service.

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. "Performance Engineering" (PE) means different things to different people. In a world of rapidly changing technology platforms, it is sobering to realize that 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. PEA helps you discover and exploit this remarkable real-world truth.

Flip through the tabs below to get our perspective on why PE practices at large corporations are consistently ineffective, despite the best investments in technology, tools, processes and vendors. Then explore our website to learn more about what we can do for you. You may want to begin with our little Quiz to appreciate the variety of problems that cross-platform techniques can address.

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.