sun.com performance
A couple of months ago, we went through a tuning exercise for our primary web site www.sun.com. A few execs noticed some strange pauses during page rendering (of primary the home page.) So a few of us started to look closer at the problem.
Before I get into it a bit, I just took a look at the daily reports again for today, and I'm happy to report that performance is still looking pretty good.
Although I'm not currently on the engineering team for the site, the I was one of the primary "architects" for the framework that serves the site, and I still have soft spot for it. I take offense when someone challenges the performance of the site. So, I decided to get involved, mainly to help gather some statistics for how the site is performing.
So what did performance look like when we looked into it? Here are a couple of charts showing what it looked like. The first chart shows the average response time to retrieve all the home page components. The second shows each component in detail.
Averages |
Details |
The charts don't look all that great. Very erratic, and pretty poor average response time. Now, the home page has about 70 components totaling about 396K. Making a very rudimentary guess at a theoretical minimum download time of all the components over say a 1.5Mbit DSL line, we're looking at about 2 seconds [ ((396 * 8 / 1024) / 1.5) = 2 seconds ]. Now lets compare that against what we see on the average duration chart. Assuming a sequential download of components, even a 100 millisecond response time would take 7 seconds to download all the comonents [ 100 * 70 / 1000 = 7 ]. Which wasn't far from the truth.
One thing to note, through our analysis, there is actually some parallelism going on to retrieving the page components. There is a great Firefox Extension that will show this visually called Firebug. So that helps reduce some overall download time.
Eventually we found the culprit. Having narrowed the problem down to some thing with Sun Java System Web Server, Chris Elving with Web Server Engineering helped us resolve the problem. As it turned out, it ended up being Reverse Proxy Plugin Bug # 6435723, which, fortunately had a fix available for it.
So, how are we looking today? Well, here's the charts as of Friday. Not much fluctuation in response times throughout the day.
Averages |
Details |
I'm sure you notice the occasional blips of response times in the over 1.5 second range. Well this is due to occasional cache flushes and page rendering due to content changes. Our rendering framework makes extensive use of XML and J2EE technologies to dynamically render the web site. I'd say in light of that, the platform is doing an incredible job at serving content.
For comparison... Here's similar charts for one of our competitors from Friday as well. Their performance hasn't changed much over the last two months. I'm not gonna tell them.
Averages |
Details |