Load and Performance Testing

Find the real ceiling before launch — including the infrastructure around the application.

iBeta load-tests websites, APIs, and mobile apps against the infrastructure that serves them: application servers, databases, cache, and load balancers. We script the journey that happens on the day, raise load until the first component in that stack breaks, then retest after you change what broke. The goal is ready for the date, not just a graph.

Tests have run from a few hundred concurrent users on transactional systems to event-style runs at tens of thousands of concurrent users, and, when the question required it, larger laboratory ramps into the hundreds of thousands. Those figures are test-environment results, not a promised production capacity.

Connect with an Expert

two-colleague-web-designer-discussing-data-and-digital-tablet

Performance testing here is not a homepage hit count. We model the path a real user takes on launch day or event day — register, pay, check in, buy, submit — and raise load until the first component in the application-and-infrastructure stack breaks.

That component is often not the application code. It may be cache policy, a load balancer that is not sticky, session handling, database capacity, or how many app instances were actually provisioned. We name that ceiling, you (or your vendor) change it, and we run the journey again.

Work covers client/server, web, and mobile. Analysis splits what users feel (response time, errors, timeouts) from what operators see (CPU, memory, database).

What the ceiling looks like in a report: a system that is still acceptable at one operating point and not at the next — for example, holding target load at about 100 concurrent users (about 3,000+ visits per hour) and throwing user-visible errors near 450 concurrent; or staying sub-second into the mid-hundreds of concurrent users and showing a clear knuckle near 600–1,000. The useful sentence is which component failed, not a single peak number.

When the first pass is not the last, later runs on the same journey have shown on the order of 20–30% faster key steps, about 25% lower average transaction time after a replatform pass, or a new site about twice as fast as the legacy one. Those are before/after measurements on specific builds, not an average improvement we sell.

Request a Consultation

Call US

img - top-view-of-designer-hand-working-with-laptop-computer-and-smart

iBeta has a large infrastructure and highly skilled engineers ideal for testing the scalability of your product. Whether your product is client/server, mobile, web-based, or something else, iBeta’s engineers can design tests that will meet your specific needs.

Load, soak, and surge tests on the real user journey — not only page retrieval
Finding the ceiling on the application and its infrastructure: app servers, database, cache, and load balancers
Multi-pass tests after a config or code change
Pre-event or pre-launch burn-in against an agreed date
Results you can act on: what broke, at what load, what to change next
Operating points documented from hundreds of concurrent users up through event-scale tens of thousands — and larger lab ramps when that is the question — with the limiter named

img - laptop-with-loading-speed-progress

scalability:

Where the system stops being acceptable as concurrency or transaction rate rises, and which part of the application-and-infrastructure stack fails first. Example findings from past tests: about 1,500 transactions per second at one operating point, or errors starting near about 3,000 visits per hour. The number that matters is your target.

Stability:

Whether the system holds a target load for the soak window without leaks, accumulating errors, or failovers users would feel. Past tests have included multi-hour soaks, a 12-hour pass with no leak noted, and four-hour holds at 100% of an agreed target. Soak length is scoped per project.

Resource Utilization:

Application, database, cache, and load-balancer views from the test and from the operators watching the environment under test.

Response Time:

Time to complete the steps that matter on the day, not only time-to-first-byte on the home page.

Journey Correctness:

Whether the scripted path still completes (login, pay, check-in, submit) as load rises. That is a functional check under load, not a separate QA program.

Tool choice follows the application and the client’s standard. Most engagements are scripted in JMeter. LoadRunner is used when that is the required or existing stack.

JMeter:

Primary tool for journey scripts, ramps, soaks, and multi-injector load.

LoadRunner:

Used when the product or client standard calls for it.

Request a Consultation

Call US

What a load-and-performance engagement looks like

A typical engagement starts with the business question and the load you actually expect. We script that journey — including mobile clients when that is how users arrive — and run against the most production-like environment you can give us.

First pass names the ceiling and the component in the application-and-infrastructure stack. You or your vendor change configuration, code, or capacity. We run the same journey again. Reports have included finding a load balancer that was not sticky before launch, a cache-refresh pattern that overtaxed the application tier, and an “add more app servers” plan that would not have moved the ceiling because the limiter was not the local application instances.

Scale is set by the question, not a package. The same bench has been used for modest transactional targets (for example about 2,400 new visits per hour with no errors at that level) and for event-style laboratory loads in the tens or hundreds of thousands of concurrent users. We will not put a single “up to” number on this page as if it were a product spec.

Request a Consultation

Call US

The cost of load and performance testing services depends on project intricacy, duration, and specific testing needs. Most load and performance projects are priced on an hourly basis based on a customized scope. iBeta also offers some fixed-price packages for simpler websites.

Request a Consultation

Call US

img - two-colleague-web-designer-discussing-data-and-digital-tablet

The turnaround time for load and performance testing projects will vary depending on factors such as the complexity of the application, the complexity of the simulated user flows, and the expected volume of traffic. For simpler websites iBeta offers performance scan packages with fast turnaround times:

Quick Scan

The Quick Scan package performs web page retrieval at gradually increasing load levels to evaluate system scalability. The Quick Scan takes two days to complete.

Basic Scan

The Basic Scan package performs web page retrieval at gradually increasing load levels to evaluate system scalability, plus it also includes user registration and login scripting. A Basic Scan takes three days to complete.

E-Commerce Scan

An e-commerce performance scan measures web page retrieval rates at gradually increasing load levels to evaluate system scalability as well as user registration, login scripting, and scripting for shopping cart flow processing. E-Commerce Scans take five days to complete.

Request a Consultation

Call US

Know the real ceiling

Capacity planning on the application and the infrastructure that serves it. Example shape: good at about 100 concurrent / about 3,000+ visits per hour; errors near 450 concurrent.

Fix the right thing

Avoid buying more app servers when the limit is cache, balancer, or database. Re-runs after a change have measured about 20–30% faster journeys or about 25% lower average transaction time on that build.

Retest after the change

Some engagements are one measurement pass; others are a series of passes until the launch note is earned.

Check the date, not only the lab

Soak and surge against the window you actually have to survive. Soak windows have run from hours to a 12-hour continuous pass.

SLA and acceptance

When you have a stated target, the run is scored against it. Where a written API target of under 3 seconds existed, the report scored pass/fail against it.

Request a Consultation

Call US

How does load and performance testing contribute to capacity planning?

We reproduce the load you name and report the first thing that fails in the application-and-infrastructure stack. For example, a mix that stayed sustainable near about 850 concurrent users on that architecture. We do not invent a cluster size. If you do not have a production forecast, that field stays empty.

What role does stress testing play in load and performance testing?

Stress is the part of the plan past expected load. It is how you learn the knuckle: still acceptable, degraded, or failed. Example shape: still fine at 500 concurrent, degraded near 600, multi-second at 1,000. Your knuckle will not be those numbers. Stress is not a separate product.

How does load and performance testing contribute to stability and reliability of software?

Soak at target load. Look for leaks, rising error rates, and failovers users would notice — not only a clean first ramp. Past tests have included 4 hours at 100% of target and a 12-hour pass with no leak noted. Duration is scoped.

Can load and performance testing help verify compliance with service level agreements (SLAs)?

If you have a written target, the report says pass/fail against it. Many projects do not arrive with an SLA; then the deliverable is the ceiling and the recommendation, not a compliance stamp. On one mobile-API program, an under-3-second SLA held at target load; that is scoring, not a default SLA.

How does load and performance testing contribute to cost and resource optimization?

The useful saving is not buying the wrong hardware and not finding a balancer or cache problem after go-live. Hours billed are not published on this page.

Request a Consultation

Call US

Load and Performance Testing

Load and Performance Testing Services