Performance and load testing services
Performance and load testing services: load, stress, spike and soak tests in k6, JMeter, Gatling and Locust, capacity planning before launches and sales peaks, bottleneck analysis in code, databases and infrastructure, front-end performance and Core Web Vitals, and performance tests in CI, with dedicated performance engineers for your team or performance testing projects delivered end to end.
Performance testing we do
Load testing
The traffic you expect, modelled from production logs and analytics as user journeys with think time and realistic data, run until response times, error rates and resource use show where the system stands against its targets.
Stress and spike tests
Load raised past the expected peak to find the breaking point and what fails first, and sudden surges such as a marketing email or a ticket release, to see whether autoscaling reacts in time and the system recovers on its own.
Soak and endurance tests
Steady load held for hours or days to find memory leaks, exhausted connection pools, growing queues and disks filling with logs, the problems a short test never reaches.
k6, JMeter, Gatling and Locust scripts
Grafana k6 in JavaScript, Apache JMeter for existing test plans and protocols beyond HTTP, Gatling in Java or TypeScript, and Locust in Python, with scripts kept in the repository beside the code they test.
Bottleneck analysis
Results read alongside traces, metrics and profiles in Grafana, Datadog, New Relic or Application Insights, so a slow response is traced to the query, lock, thread pool or external call behind it, and each fix is retested under the same load.
Capacity planning for launches and peaks
Load tests sized for a launch, a sales peak or a campaign, with the instance counts and autoscaling limits that hold at that load written down and the cost of running at peak estimated before the day.
Front-end performance and Core Web Vitals
Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift tracked from real users’ field data, with Lighthouse and WebPageTest in the lab to find the cause, then improved through image, script, font and caching changes.
Performance tests in CI
Short load tests with pass and fail thresholds on every release in GitHub Actions, GitLab CI or Azure Pipelines, larger runs in Grafana Cloud k6, Azure Load Testing or BlazeMeter, and each run compared with the previous build so a regression is caught before users feel it.
Resilience and failover tests
Instances, zones and dependencies taken down under load with AWS Fault Injection Service, Azure Chaos Studio or Chaos Mesh, to check that failover, retries and circuit breakers work and recovery meets its target.
Hire performance engineers
Dedicated performance engineers
Performance engineers who join your team full time, work in your tools and process, and report to your lead. You interview them; we carry the Ukrainian contract, payroll, invoicing and leave.
Performance testing projects
A defined piece of performance testing with a scope, a fixed plan and a named lead on our side who owns the result and reports progress in your channels.
Ongoing performance testing
Performance testing as a continuing service: the same people every month, a backlog you prioritise, and hours you can see in our portal and on the invoice.
The dedicated team page explains how specialists join your team, and the outsourcing page covers project delivery, take-overs and how we charge.
Who works on your performance testing
Performance engineers
Workload models, scripts and analysis
Site reliability engineers
Monitoring, autoscaling and capacity
Backend developers
Fixes in code, queries and caching
Database administrators
Query plans, indexes and connection limits
Front-end developers
Core Web Vitals improvements
How we run performance tests
Each test starts from a written target: the number of users or requests, the response time at the 95th or 99th percentile, the acceptable error rate and the cost. The workload is modelled on production traffic, test data is generated at production volume, and the test runs against an environment sized like production, or against production itself in an agreed window.
Results come with an explanation, not only a chart: which component reached its limit, why, and which change moves it, with each fix confirmed by a rerun under the same load. Scripts, data generators and thresholds stay in your repository, so your team can run the same tests before every release.
Other software testing services
Manual testing
Manual testing services: functional, regression and exploratory testing, test case design, cross-browser and cross-device testing and UAT support, with dedicated manual QA engineers or project delivery.
Test automation
Test automation services: Playwright, Selenium, Cypress and WebdriverIO suites, SDET work, API and visual tests, and CI integration, with dedicated test automation engineers or project delivery.
Mobile app testing
Mobile app testing services: iOS and Android testing on real devices and device farms, Appium, Espresso, XCUITest and Maestro automation, and store release checks, with dedicated mobile QA engineers or project delivery.
API testing
API testing services: REST, GraphQL and gRPC tests in Postman, REST Assured and code, contract testing with Pact, OpenAPI validation and service mocks, with dedicated API test engineers or project delivery.
Accessibility testing
Accessibility testing services: WCAG 2.2 audits, screen reader and keyboard testing, axe checks in CI, remediation support and conformance reports, with dedicated accessibility testers or project delivery.
Questions about performance and load testing
Which industries do your performance engineers work in?
Mostly e-commerce and retail, before sales peaks and campaigns; fintech and banking, where payment and trading systems have latency targets; enterprise SaaS products taking on larger customers; media and streaming services whose traffic arrives all at once; and telecom, cloud and hosting providers sizing their platforms.
Can you load test in production?
Yes, when staging cannot reproduce the real system. The test runs in an agreed low-traffic window, ramps up in steps with stop conditions on error rate and latency, uses test accounts and data that are removed afterwards, and has a named contact on each side watching it.
k6, JMeter or Gatling?
k6 for most new work: tests are written in JavaScript, run from the command line and fit a pipeline. JMeter where test plans already exist or the protocol is not HTTP, such as JDBC, JMS or plain TCP. Gatling for teams working in Java or TypeScript, and Locust for Python teams. We also work with whichever tool your team already uses.
How quickly can performance engineers start?
When the right performance engineer is available, the start is gated only by your interview and the NDA and IP assignment. Otherwise we run a search, which typically produces candidate profiles within two to three weeks, and nobody starts until you have said yes.
How do we hire performance engineers through BigTree108?
Tell us the work, the seniority and the hours you need. We propose one or two people with their profiles, you interview them the way you would interview your own hire, and you sign one agreement with BIG TREE 108 LLC and receive one invoice a month.
Who owns the work they produce?
You do. Every specialist has a signed contract with BigTree108 that assigns all work product to the company, and our agreement with you assigns it onward. Code, designs and documents are delivered into your own repositories and tools, not kept where only we can change them.
Expecting more traffic?
Tell us what the system does, how much traffic it gets today and how much you expect. You get an answer within one business day: a test plan with targets, candidate profiles, or a scope for a first load test.