Traffic model
Server logs plus GA4 or Matomo data tell us the peak minute and what people do in it. We then scale that to the campaign volume you expect.
Service · Software testing and QA
Load and stress testing
An İzmir home textiles label sells through its own web store and is preparing for November's big sales. Last year, when a popular influencer posted a product link at 9 pm, shoppers saw error pages for twenty minutes, carts were abandoned and customer service spent the next morning answering complaints. This year a TV advert is booked on top of a larger promotion. Nobody has to guess whether the platform will cope. Simulated shoppers can be sent through it in controlled numbers: browsing, searching, filling baskets and heading for payment, while every response time and error is recorded. The result pinpoints what gives way first. Perhaps the database, perhaps the application server, perhaps the call to the payment gateway, or perhaps the job that syncs stock with the marketplaces. Instead of a gut feeling that the site is quick or sluggish, management gets a report built on numbers.
p95 and p99
truer than an average
k6, JMeter, Gatling
picked per application
Realistic journeys
modelled on logs and analytics
Repeat runs
after each improvement
What the work covers in practice
The aim is not a pretty chart but a reasoned answer to one question: will the site stay up that evening?
Shopper journeys
Browsing, searching, filtering, adding to basket, logging in and paying via iyzico or PayTR in sandbox mode. Each virtual shopper picks different products and data rather than firing one request over and over.
Test shapes
A steady ramp, a sudden spike, an endurance run over several hours, and a stress run that keeps pushing until something breaks.
Numbers that matter
95th and 99th percentile response times, error rate and transactions per second. A one-second mean looks healthy, but not if every twentieth visitor waits ten seconds.
Locating the bottleneck
While tests run we track CPU, memory, the database connection pool, slow queries and queue depth, using your existing monitoring or dashboards we set up temporarily.
Other people's limits
Payment gateway, courier API, SMS and email sending, marketplace stock sync. Your own servers may cope and still be let down by an hourly or per-minute cap at one of these services.
Fixes in order of payoff
Missing indexes, caching, CDN rules, extra capacity and, if really needed, a virtual queue. Each proposal carries an effort estimate and is measured again once in place.
How we approach the job, from first call to handover
We plan backwards from your campaign date. Around four weeks leaves room for a first run, fixes and a second run.
01
Target statement
For example: “15,000 visitors between 21:00 and 21:30, 95% of pages under 2 seconds, errors below 1%.”
02
Environment and notices
A production-like set-up with realistic data volume, the scripts, and advance notice to your host, CDN and payment gateway.
03
Measured runs
Ramp first, then spike and endurance, with a quick review after each run.
04
Fix and compare
The highest-impact fixes go in, the same journeys are replayed, and both sets of results are reported side by side.
Tell your hosting and security providers before you test. A burst of tens of thousands of requests can look like an attack to DDoS protection or a web application firewall. The test gets cut short, and the load generators' addresses may end up blocked. Sharing the time slot and source IPs beforehand keeps the results meaningful and avoids needless alarms.
Frequently asked questions
Preferably against a separate copy that mirrors production. If the live site must be used, we pick the quietest hour, agree the window in advance and let your providers know.
Not quite. Real people read, hesitate and pause between pages, so we take think times from your analytics. What really counts is less the headcount than the number of requests and transactions per second hitting the servers.
There is a small infrastructure cost for the cloud machines generating load and, if needed, for temporarily enlarging the test environment. You see the amount as a separate line in the test plan beforehand.
Four weeks at the very least. The first run nearly always exposes a few bottlenecks, and fixing them and measuring again takes time. A test in the final week mostly just delivers bad news sooner.
Yes. We usually write them as k6 code and leave them in your repository. A slimmed-down version can join your CI pipeline, so any drop in performance after a big change shows up automatically.
Neighbouring services that often go with this one
Service
Functional testing
An independent check that the software you are about to accept really follows your business rules
Service
Test automation
Automated checks that flag a broken flow within minutes of a code change
Service
Usability and UX testing
See with real people where your site or app loses them, and why
Service
Penetration testing
Authorised, hands-on attacks that uncover weaknesses before someone malicious does
Let's put numbers on your busiest day
What is the critical date ahead of you, and how many visitors do you expect? We will suggest a target statement and a schedule planned backwards from it.
Availability
Weekdays 09:00-18:00 Turkey time (GMT+3); an answer follows by the next working day
Weekdays 09:00-18:00 Turkey time (GMT+3); an answer follows by the next working day
Calls
By video, over Microsoft Teams or Google Meet
By video, over Microsoft Teams or Google Meet
We have your enquiry
A reply will reach you by the next working day at the latest. If your message says work has come to a halt, it goes to the top of the pile.
- Filling the gaps. If we need more information to judge the job, we send questions by email or propose a quick Teams or Google Meet call.
- A written quote. It lists the scope, a euro price excluding VAT and a realistic start date. No hidden clauses, no items that appear later.
- Your decision. The quote arrives by email. Take whatever time you need, raise questions on any line, and decide when you are ready.