Scaling Out the Performance Testing Client Layer

27 04 2010

Rudi Hacopian, Quality Assurance lead on one of Shopzilla’s highest scalability challenges yet, “Inventory LIVE!”, has posted an excellent account of his performance testing challenges (and ultimate successes).

What’s the optimal approach for performance testing an application with;

  • 200 million domain objects
  • 90 JVMs, constituting an Oracle Coherence data-grid, and 12 load-balanced Tomcats
  • RESTful web-services, using FastInfoset, JAXB and streaming over HTTP
  • A core requirement to deliver 100′s of gigabytes of data within a short time frame

In Rudi’s article, “The Web-Service May Not be the Bottleneck!“, he discusses the key challenges inherent with performance testing at such scale, and how scaling at the client layer helped achieve higher network utilization and throughput.

One core goal of the Inventory LIVE! project was to deliver a ‘snapshot’ of our 200 million domain objects to our clients in a short time period. Once the functional testing effort was out of the way, we focused squarely on the complexity of performance testing. I was personally thrilled and excited about our new and unique approach to shipping such an inordinate amount of data to our clients!

With our Coherence grid fully loaded at 200 million ‘mock’ domain objects (we use a mock data loader), we launched multiple clients against the web-service to test the performance and timeliness of our HTTP streaming approach. An hour into the test, I was puzzled and had A LOT of questions for the team. Why had we only streamed 2MM offers so far? Why does it seem so much slower at scale?

Read on!





Fire Chief – Cover Man Means Cover Man

12 03 2010

Upon joining a new team at Shopzilla.com, it was fascinating to see how much our myriad legacy systems were impacting our ability to evolve. I am lucky enough to work with a very mature engineer who is passionate about both cross-trained teams, and the evolution of our legacy systems. My recent blog post details how we were able to craft a fun and interesting way to;

  • Improve our legacy systems and services
  • Maintain our production uptime
  • Build a high performing team, focused solely on net-new systems and services
  • Create a fun, light-hearted but professional atmosphere for the above
  • Promote passion for our team and what we do within the organization

My teams deliver high-performing solutions to serious business problems, but they have a ton of fun too! From the article;

On a team with myriad legacy systems, production problems will often be a significant burden for the team. In my experience, without a strategy for managing the team’s approach to tackling these production ‘fires’, the team’s yield for new value creation will be far below it’s potential.

Our approach has been to define a new role – the Engineering Fire Chief. Simply put, our Fire Chief is an engineer (or two) who actively accepts the role of providing distraction-free “cover” for their team. (yes, we actually bought a Fire Chief hat.)

(Keep reading!)

The Fire Chief concept (and hat) is popular.

The Fire Chief concept, and hat are popular.

A fire chief wearing multiple=

A fire chief wearing multiple hats, and proud to fight fires!





I am a Lead Engineer

15 02 2010

This article is a cross-post from the Shopzilla Tech Blog.

It’s been a thoroughly eye-opening experience to frame our roles at Shopzilla. Petter and I were charged with defining the Lead Engineer role at Shopzilla.

I am a Lead Engineer:

  • I hold “excellence” as my yardstick.
  • I am a software craftsman, I am proud of our code, and I promote this craftsmanship and pride amongst other engineers.
  • I lead by example, and I love getting my hands dirty.
  • I love to learn and teach through conversations about code.
  • I favor reuse over reinventing the wheel.
  • I am passionate about performance and know there is no such thing as “perf spray”.
  • I engage other engineers, and in seeking them out I foster communication.
  • I heart QA.
  • I ensure my decisions are based on not just my own competence, but that of the whole team.
  • I am a mentor, and I understand the difference between posing questions and mandating solutions.
  • I am approachable.
  • I encourage my teams to develop their own technical voice.
  • I ensure my engineering team is not an island – our discoveries are shared; our struggles are too.
  • I help strike the balance between quality and getting functionality out the door.
  • I help business owners translate ideas into technical solutions.
  • I find the bumps in the road before we hit them.

I am a lead engineer and my success is the sum of the success of the people around me.








Follow

Get every new post delivered to your Inbox.