Saturday, June 30, 2007

Basket Pipeline Performance

We're nearing the end of development for one of the projects I'm on right now. This site utilized some AJAX and these functions needed to be snappy to really work, so I started looking into tuning performance. After profiling, I found that by far the site's biggest bottleneck was the basket pipeline.

Like most e-commerce sites, this one has a shopping basket summary on every page to show the user how many items they have in their basket, and the basket's subtotal. We were running the basket pipeline before rendering this summary to make sure that the total was up to date, which means that the pipeline was running at least once per page. It also ran additional times if any items were added to the cart during that request. As it turned out, even running it once was our bottleneck by a long shot.

This information led us to a new approach:
  • Whenever the basket is modified (e.g., when an item is added), the basket pipeline will be run and the basket saved.
  • The basket summary will use the totals saved from the last time the pipeline was run. These totals may be stale if any item's price has changed since it was added to the cart.
  • The user will be required to review their cart before checking out. This page will run the basket pipeline again to make sure that the user is being given the most up-to-date prices.
This approach means that the summary might have a stale total if prices change after items are added to the basket, but we considered this acceptable since they are required to review their basket before checking out. Max Akbar also validated this approach, and based on his response I think this is how we are expected to handle these summary controls.

No comments: