Tynor's New E-Commerce Site Was 30× Too Slow. We Had Four Days.

Denis Sautin

Author

Denis Sautin

Denis Sautin is an experienced Product Marketing Specialist at PFLB. He focuses on understanding customer needs to ensure PFLB’s offerings resonate with you. Denis closely collaborates with product, engineering, and sales teams to provide you with the best experience through content, our solutions, and your personal journey on our website.

Product Marketing Specialist

Reviewed by Boris Seleznev

Reviewed by

Boris Seleznev

Boris Seleznev is a seasoned performance engineer with over 10 years of experience in the field. Throughout his career, he has successfully delivered more than 200 load testing projects, both as an engineer and in managerial roles. Currently, Boris serves as the Professional Services Director at PFLB, where he leads a team of 150 skilled performance engineers.

The situation

Tynor committed to significant expansion over three years and built a new e-commerce site to carry it. The business expected high sales; the engineering team was not certain the site could take them.

Two constraints shaped everything: no in-house load testing skill, and a week until go-live. Tynor's CIO found PFLB through a Google search and got in touch.

“We knew that the business expected us to support high sales. But no one was completely sure that our new site was ready for it. Moreover, our team lacks competence in load testing, and we had only a week left before the launch.”

Pankaj Mor, Chief Information Officer, Tynor

What was done

PFLB proposed Quick Load Testing: a four-day project run jointly with Tynor's in-house engineers on the PFLB Platform, delivering test results plus specific recommendations on what to improve. The proposal included a month's platform subscription so the client's team could run further iterations without waiting for anyone.

The first tests were bad news, precisely stated:

• At eight concurrent users, page load time already exceeded 2 seconds.
• Against the SLA, the maximum number of simultaneous users the site could serve was 16.
• Response time grew almost linearly with concurrency - the signature of a system with no headroom rather than one with a single slow component.

Tynor's engineers, working with PFLB, analysed the site's behaviour under load and located bottlenecks at the database and network levels. Then came several rounds of fix and re-test.

Results

• Performance improved by more than a factor of 30.
• Average page load under load: at most 2 seconds.
• Maximum simultaneous users: 16 → 500.
• Site capacity: more than 10,000 users a day.
• The site went into its launch with the numbers known rather than hoped for.

Response time before and after performance optimization.

Questions this engagement answers

How long does pre-launch load testing take?

This one took four days from start to recommendations, because the scope was deliberately drawn around the launch risk rather than around full coverage.

What if the team has never done load testing?

It is run jointly - here PFLB engineers worked alongside Tynor's own, and the month-long platform subscription meant the client could continue testing after the engagement ended rather than losing the capability with the consultants.

What does "the site is slow" usually turn out to be?

Here, database and network-level bottlenecks - with response time rising almost linearly against concurrency, which pointed at systemic headroom rather than one bad endpoint.

Is a 30× improvement realistic?

It is when the starting point is a 16-user ceiling. The useful number is not the multiplier but the outcome: 500 concurrent users and 10,000 a day, measured against an SLA.