Skip to main content

Sitecore

Sitecore Symposium 2019: Punch it Chewie

Chewie

This session was presented by Matthew Dubbs, Sitecore test specialist, and Jason St-Cyr, Sitecore manager, test evangelists. Overall, the session discussed getting more out of your installation and performance testing. Here are my key takeaways:

  • Why performance test?
    • Avoid late night support calls
    • Being down is bad:
      • Amazon was down for 15 minutes in July and it cost an estimated 2.5 million dollars in lost revenue
      • Loss of brand trust
      • Lost operational costs for the people working to fix the problem instead of their planned work
    • Confidence is key:
      • Knowing that your site can handle the traffic
    • Learn about the product at a deep level;
      • Helps you know how to scale and which direction
    • Guides you to install monitoring tools:
      • You cannot improve if you don’t have the right data
    • Types of performance testing:
      • Load
      • Endurance
      • Volume
      • Scalability
      • Peak
      • Stress
    • How do you test?
      • Expected traffic patterns
      • Testing above the maximum capacity
      • Ensuring maximum capability
        • Aka: Avoiding the “Black Friday” effect
      • Long period testing
    • Things to watch out for:
      • Contacts
        • SC_ANALYTICS_GLOBLAL_COOKIE
        • Controls a new contact versus a returning user
      • Robot detection
        • Robots are handled differently than a normal user
        • Robot traffic is not handled in XDB
          • So you are not hitting the database in the same way as a valid user session
        • Simulate source IP addresses
          • Add custom headers and IP addresses to load test scenarios
        • Session Timeout
          • Defaults to 20 minutes
          • Run your tests for at least 2 times longer than session timeout
          • Session cleanup on the server takes time and resources
        • Define your targets – What is important to your performance
          • Users – maximum concurrent
          • Requests – peak versus response time goals
          • Visits – requests per visit
        • Load test workflow
          • Result validation
          • Diagnose areas to improve
          • Iterate

So what are your next steps? You must always test! Performance testing is an ongoing process and can’t just be done once a year. You also need to know your path to define what needs to be tested. Lastly, you need to monitor your application so you can make the data available so you can continue to improve.
Don’t forget to continue to follow my session reviews throughout the rest of the conference!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Eric Sanner, Solutions Architect

More from this Author

Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram