Black Friday And Cyber Monday Through The Eyes Of An Apm Solution

By Author: Joseph Mathew
Total Articles: 11
Comment this article

Application performance software collects a lot of data about how applications perform during different times of day, week, month and year. In this article we’ll look at how a large eCommerce application fared during the past Black Friday and Cyber Monday, the two biggest shopping days for eCommerce organizations. Typically this time of year accounts for most of the revenue for eCommerce giants, but only if their applications can support the spike in load on their applications – now is not a good time to have a code deadlock Java or another critical application performance issue appear.

Business was great over the Black Friday weekend for this particular eCommerce company, which saw a 300-500% increase in transaction volume over the holiday period. Transaction throughput peaked between 24,000 and 31,000 transactions per minute (TPM) over the Black Friday weekend, which is significantly greater than their peak loads during the rest of the year. Let’s see how their application fared with the increased load.

-For the most part, application response time was stable. However, there was one “blip” during the ...
... first minutes of Black Friday (12m EST). The blip in the application related to the web container thread pool becoming exhausted during peak load when the Black Friday promotions went live.

-Two business transactions, “Product Display” and “Checkout,” were breaching their performance baselines during that period. Looking at the average response times of 516ms and 733ms tells one story; looking at the maximum response time and number of slow/very slow transactions (calculated using SD) tells a completely different story.

The customer investigated the “Product Display” business transaction, which was classified as very slow with a 66 second response time.

-When they drilled into the code execution and SQL activity, they saw a simple SELECT SQL query had a response time of 588ms. The problem in this transaction was that this query was invoked 102 times, resulting in a whopping 59.9 seconds of latency, its therefore no surprise that thread concurrency inside the JVM was high waiting for transactions like these to complete. If these queries are simply pulling back product data, then there is no reason why a distributed cache can’t be used to store the data instead of expensive calls to a remote database like DB2.

For the most part, Black Friday and Cyber Monday went off without a hitch for this organization. However, very large spikes in traffic often reveal lurking application problems at an inopportune time. It’s a good idea to have some sort of JVM management solution in place in the production environment to help prepare for these issues and solve problems on the fly to minimize the business impact.