[ This is my personal blog so all opinions expressed here are mine. I am a product, scalability, operations and monetization advisor and currently employed as Director of Business Operations & Technical Strategy for a top 50 website that delivers billions of page views per month. I was a keynote panelist for Scaling Up or Out keynote at MySQL Conference and speak regularly at conferences and user groups.
]
Next session is High-performance Ajax Applications by Julien Lecomte (Yahoo!).
Plan for performance from day 1
work closely with designers and product managers
understand design rationale
explain the tradeoffs between design and performance
offer alternatives and shw what is possible (prototypes)
as a last resort, simplify design
Engineering high performance: a few basic rules:
don't do anything unnecessary
less is more
break the rules
work on improving perceived performance
users can generally deal with a little bit of discomfort if they can see something is happening.
can't compromise security but someother things can be compromised
in general avoid presentational markup
Measuring performance:
test performance using a setup similar to your user's environment
profile your code during development
automate profiling/performance testing
keep historical records of how features perform
consider keeping some (small amount of ) profiling code in production
Yahoo!'s exceptional performance rules
make fewer http requests
use a content delivery network
Asset optimization:
minify CSS and JS files
combine CSS and JS files
optimize image assets
Reduce unminified code size:
loading and parsing HTML, CSS and JS code is costly
be concise and write less code
make good use of javascript features
consider optimizing your large JS files into smaller files (bundles) when the parsing and compilation of the script takes an excessive amount of time
load code (HTML, CSS and JS) on demand
Optimize initial rendering (1/4) misc tips
consider rendering the first view on the server. (server should generate the markup)
this will speed up the intial rendering.
close your HTML tags to speed up parsing
consider flushing the apache buffer very early on
load only essential assets/load assets on a delay or on demand.
don't always wait for onload
most DOM operations can be accomplished before he onload event has fired
post load script loading:
a well designed site should be fully functional even without the JS enabled
therefore you may be able to load scripts on a delay
conditional preloading:
preload assets that you know user is likely to need very shortly
however, one must be smart about when the preloading takes place. Otherwise the preloading may actually worsen the user experience.
Part 3: High Performance Javascript:
look up is performed in JS everytime a variable is accessed.
declare with the var keyword and use variables in the same scope whenever possible and avoid global resources at all costs.
never use the with keyword as it prevents the compiler from generating code for fast access to local variables.
cache the results of expensive lookups in local variables.
The prototype chain:
accessing member found in the primary object is about 25% faster
optimize object instantiation:
if you need to create many objects, consider adding members to the prototype instead.
Don't use eval
eval is evil
the string passed to eval (and its relatives, the function constructr and setTimeout and setInterval function needs to be compiled and interpreted (extremely slow).
optimize string concatenation:
on IE concatentating two strings causes a new string to be allocated and the two original strings to be copied.
therefore, it is mch faster on IE to append string to an array and then use Array.join
optimize regular expressions.
don't use the RegExp constructure unless your regular expression is assembled at runtime. Instead, use regular expression literals.
use the test mehod if all you want to do is test for a pattern. (the exec method carries a small performance penlty.
Caching
caching can be justified when there is a high cost associated with getting/accessing the data and when data wouldn't change over time.- increases memory consumption (tradeoff)
memorization
long running javascript running process (longer than 300ms):
the entire browser UI is frozen.
to maintain a decent user experience make sure that JS threads never take more than 300 ms.
misc:
function calls have overhead associated with them
consider using primitive operations since they are often faster than the corresponding function cals
if possible, avoid using try..catch in performance critical sections
if possible, avoid for...in in perormance critical sections
branch outside, not inside, whenever the branching condition does not change
Next session is Stress, Load and Performance Testing in Quality Assurance by Goranka Bjedov of Google.
I have been wanting to hear Goranka for some time now as her sessions usually end up becoming the highlight of the event. For record, she passionately hates Power Point (I don't blame her).
I couldn't find a video of her Velocity talk but here is a video from her previous talk that's equally interesting.
Goranka spends all her time doing performance testing at Google. She tests Adwords, AdSense and hates any kinds of presentation tools.
focus on the backend. Steve Souders is the client side performance guy.
she works on the servers.
what are the bottlenecks?
QA people should be able to tell you what to expect.
2 purposes: what is going on in application? and monitor application for changes.
a small code change can cause tremendous performance decline.
first thing is if a mistake is made, everyone should know right away. Finding it later can cost a lot
80% of the performance problems can be worked out with one front end and one backend as long as you have the right database.
figure out what is happenging with important transactions
if you don't know what important transactions are, make a guess. it's better than nothing. don't be paralyzed, then worry about perfection
there is nothing as perfection in performance testing. she cannot guarantee the exact results. All tests are run as statistical tests and run 5 times or so.
big proponent of open source tools: jmeter, grinder and funkload. In Windows environment look at Open SDA.
Vendor tools do reasonably job. (and solve the problem of having too much money)
Open Source tools do exactly the same job. they are not free completely as time is required.
if you're not willing to spend time on OS tool, then why even spend half a million dollars?
she is happy that OS tools don't have monitoring built into it.
monitoring is absolutely essential and must be done separately.
for majority of things you can troubleshoot and benchmark within 3 weeks.
check google blog for her posts: open source performance testing tools
Notes from Velocity Conference continue: Next up is a Keynote by Artur Bergman (Wikia). Wikia runs 7000 Wikis and has 400 million page views per month.
Google, Yahoo and Amazon are what people rely on
Friendster.com, Twitter and boo.com have serious reliability problem
Value of performance/ reliability
brand value (they rely on you)
more page views (fixed amount of time + faster site)
Match user expectations:
World of Warcraft:
$520 million in profit last year
99% reliable
down every week, scheduled
server crash
"We pay them money, so we have to accept the downtime."
Operations:
efficient use of resources
end user performance
reliability
bad operations wastes R&D and cost of sale money
Business
cost per pageview. How many actually know this?
cost per page
revenue CPM - cost per pageview
Gross margin
Reliability example:
20% of wikia pages
200ms -> 15s to load
35% reduction of page views out of the slow pages
15% reduction of the fast pages
slow pages made people abandon the site.
Happy users - Lower cost
for the users: service industry
for the business: cost per page view, lower capex.
VC love to give money to IBM, HP, Dell
better for the environment.
May performance project:
50% cpu usage cost
delay investment 6 months
3 engineers - 4 weeks
Cache miss
300ms -> 190 ms
Perception
Ads
Ads are slow
Load ads after content load
Dramatic change:
significant % increase in pageviews
We lose money
but edits increase
Stay in loose and simple area, stay away from the complexity.
Next up is Scott Ruthfield (WhitePages.com) talking about Jiffy: Open Source Performance Measurement and Instrumentation. WhitePages.com is a people search power. They own 411.com. They have data on 180 million people doing 2 billion searches / year and 500 searches per second during peak. A top-50 comscore site.
Very important performance lessons: Scott says "Slow is bad." Customers just don't want you to be slow. "We're slow." A detailed analysis on their end revealed that the slowness wasn't their fault.
Reflection:
YSMV: Your slowness may vary
YCMWYCM: You can't manage what you can't measure
Jiffy:
means: Small unit of time; tick between system clock interrupts
is an end-to-end system for measuring and reporting on page load activity
Four goals:
real data at scale: what are customers seeing?
measure anything.
real/near time reporting
~0 impact on page performance
he says "it works"
What are the components of Jiffy?:
jiffy.js - library for instrumenting your pages and reporting measurements
apache (httpd.conf) config - receive and log measuremens
Better late than never. At Velocity Conference I took a lot of notes and didn't get to publish them earlier. Now that I find some time on my hand, I am going to go ahead and publish them.
At Velocity, there will be two product launches. Vik Chaudhary (Keynote Systems, Inc.) and Abelardo Gonzalez (Keynote Systems) are on stage now.
The first product is KITE (Keynote Internet Testing Environment). Keynote has been in business for 12 years. Providing a single performance testing environment for everyone (web developers, QA and system administrators) has always been a challenge for both startups and major players. This presentation sounds very promising.
Keynote collects 200 million internet measurements everyday.
With KITE, You can test from desktop to the internet cloud.
Keynote built it to provide a single performance testing environment for web developers, QA and IT operations team.
Sites are making upgrades every single day. Customers want to be able to test it from multiple locations
KITE is Ideal for 3 things
recording , scripting and playback of web transactions
instant web tests from desktop
scheduled testing for higher productivity
KITE Web Performance Engine allows for:
performance analysis for multi-page transactions, not just single pages
Javascript programmability for scripting and DOM analysis
testing from the desktop, Last Mile and the Internet Cloud
Native IE integration which in turn allows for easily analysis of AJAX, Flash and Javascript
Recording of test scripts which can be played back in "burst" mode and share scripts
Next is a demo by Abelardo Gonzalez.
You get a script repository that you can save for performance benchmarks.
There is a record button and a free global test button.
They will be testing iGoogle.
You start a session then as you take actions, they are recorded in the console.
KITE helps with three main things:
user experience time
network time
cache network time (for repeat visitors)
You can download very deep into each page and each performance metric. Tests from Global Network are also possible where you can replay exactly the steps you made from your desktop from all supported areas (e.g. Atlanta).
