Thursday, March 30, 2006

Thanks for stopping by

I began focusing on performance of systems when I was VP of IT at Barnes & Noble.com. Certainly, I had spent a good deal of my career focusing on architecture of systems, application development, integration of systems ... before that. But the early days of the Internet explosion was a unique period in the history of IT. There were many more unknowns that needed to be solved in a shorter period of time than ever before. This was especially true for one of the fastest growing, most used websites in the world. It was a unique opportunity to understand performance testing, the interdependencies of applications, network, and servers. Like any good IT group working to satisfy the needs of the business, need to understand the complexity of the systems was coupled with a need to support rapid change.

At Barnes & Noble.com, we were very fortunate to have a geographically distributed website. We had something that was and continues to be rare in IT, a 50% sized performance test environment that was always kept current with production. With appropriate planning to avoid risk the business and to our customers, we could shift all web traffic to one site and performance test against the other. Most IT organizations only have a similar luxury when they are launching a new large system and can use the future production environment as a performance test environment prior to go-live.

We got to be very good at performance testing. We learned that our performance test strategy was more appropriately based on work volume rather than virtual users. We also learned to leverage external load injectors to understand the vagaries of the Internet while adjusting for the affect of our Akamai network that was used to serve images.

The challenges of understanding the performance of changes can be summed up in a few items:

  1. Understanding the topology of the test and production environments
  2. Understanding the user behavior and transaction load throughout the business cycles
  3. Defining the goals of all performance engineering activities (development, testing, modeling, management)
  4. Planning for the right amount of performance engineering
  5. Acquiring the skills and knowledge of the end-to-end application system, network and supporting application architecture
  6. Managing execution of performance engineering activities
  7. Leveraging the typically virtual team of subject matter experts for analysis, adjustment and feedback to the development cycle

I currently manage the practice at Genilogix LLC for performance modeling. There are some significant AHA's about the relationship between performance testing and performance modeling that I hope to discuss next.

No comments: