July 3, 2011 by mensming.

At work, we use Jenkins as our continuous integration server. This machine was built over 3 years ago and has been very stable. One thing I had tried to debug at various points in the past is that our builds on this machine take 2-3 times longer than on our local machines. Other than that, the server has been rock solid stable.

This week, we made a change to our build scripts which worked fine on our local boxes (Windows) and on some VMs (Linux). However, the build failed with class not found errors on the build machine. As part of debugging this issue, I noticed that Java had never been upgraded on the build server. So, we upgraded Java from 1.6.0_07 to 1.6.0_21. It did not solve the problem but it was a needed change to the build server so we kept it. (FYI - the issue with the build was a dependency order issue which was resolved by simplifying the build scripts.)

When we thought we had everything fixed, I kicked off a full build from Jenkins. I was planning on coming back to check it in about 30 minutes (the expected full build time) only to be surprised when I got the build working normally email after 8 minutes. Unexpected. I checked the logs. Everything ran. I checked the build artifacts. All looked good. However, I did not believe the changes we made would speed up the build that quickly. Especially since our local builds did not speed up.

I kicked off a branch build (old build scripts) and it too completed in about 8 minutes. This leads to the java upgrade. I changed the active java version back to 1.6.0_07 and the build took nearly 30 minutes. Changed it back to 1.6.0_21. Build takes 8 minutes. Our automated tests are all running successfully. No build related issues have been discovered by our testers. Looks like this simple change has sped up or continuous integration server dramatically.

Posted in performance | No Comments »

May 28, 2011 by mensming.

Latency: Why You Should Worry and What Up You Can Do About It
Philip Tellis, Yahoo! Inc.
2010 Velocity Conference
June 22-24, 2010
(15 min, 40 sec)

Here are my notes from watching the presentation:

• Bandwidth is easy - It is not the problem…
• Bandwidth vs. Latency - How bad is it?
• More resources on a page, latency more of a problem
• It’s Still the Latency, Stupid http://www.stuartcheshire.org/rants/latency.html
• Javascript adds latency

What to Do About Latency?

• How did CPUs solve latency? Cache, Parallelise, Predict
• These apply to the web as well…
• Pre-fetch content is a way to predict

How to measure?

• Announcing Boomerang http://github.com/yahoo/boomerang
  
• Measures page load time from the unload of the last page to this page is loaded
• Measures bandwidth
• Measures latency
• Include a script on the page, include a beacon on your server to send the data…
• BSD license

Posted in performance, test tools, conferences | 1 Comment »

March 12, 2011 by mensming.

The following are my notes from this presentation at the Velocity 2010 conference:

The Top 5 Mistakes of Massive CSS
Nicole Sullivan, Consultant
Stoyan Stefanov, Google
2010 O’REILLY Velocity - Web Performance and Operations Conference
June 22 - 24, 2010

(Length 37 minutes, 54 seconds)

(Some demo isssues the first couple of minutes of the video…)

Why optimize CSS?

• It blocks progressive rendering
• Does not minimize as well as javascript

Top 1000 Alexa Sites Study

• 42% don’t gzip CSS
• 44% more than 1 CSS file
• 56% serve CSS with cookie
• 62% don’t minify
• 21% have > 100K of CSS

Object oriented CSS is a way to make CSS smaller.

• Concentrate on the selector
• Example: Grids projects, 574 butes, 14 lines

Granularity Fail + Stale Rules + Unpredicatbility + Duplication + Specificity Wars = Massive CSS

#5 Granularity Fail

• should not match underlying programming object model
• compare to legos - use CSS similarly
• How to determine if correct
• 1) Perform a visual inventory
  • Take a site object
  • Break it down into component CSS objects
  • Look for repeating patterns, for example headings
• 2) Develop library of component parts

#4 State Fails

2 types of stale:

• Truly stale - no longer in use
• Rules used after user action or on subsequent pages

• Try dust-me selectors
• Track over time

#3 Unpredictability

• Elements should be consistent across site (like lego bricks that don’t change behavior depending on where they are used…)
• How to test? Search for repeating definitions of same item (for example grep h[1-6]

#2 Specificity Wars

• Programmers making items more specific in order to prevent others from overriding their settings

How to simplify:

• Use hacks sparingly
• Avoid styling ids
• Avoid !important

What to do

• Style classes rather than elements
• Give rules the same strength

#1 Duplication

• Grep is your friend
• grep for margin set to zero - too many, may need a reset stylesheet
• grep for float - too many, may need grid system
• grep for font-size - may be heading disguised as something else
• Example from Facebook

Posted in performance, operations, web testing, conferences | No Comments »