karlcow

Know Your Engines: How to Make Your JavaScript Fast

(the slides contains a lot of materials)

David Mandelin (Mozilla)

In 5 years some javascript code is as fast as C.

eval("");

It is not really about making javascript but more how to not make JS slow.

In 2006,

1. Front End
2. Interpreter (run the bytecode)
3. DOM, Standard Lib, Garbage collector

JS is untyped and makes it slower. A simple thing such as z =x + y can mean many things. In addition there are internal types. Some object have different shapes. JS needs boxed values. So it has two values, the box and the unboxed.

For interpreting code, JS goes through a lot of steps.

In 2011

JS gets a lot faster by the addition JIT. In the future there will be type-specializing JIT compiler. Many steps are removed with the JIT. The JIT code can keep things in register.

There is a separate JIT for Regex. The performances have improved a lot recently.

ICs: a mini-JIT for objects called Inline Caching. It will improve a lot the properties. Global Variable acces, direct property access, closure variable access are improved by IC. Prototypes don’t create too much performance issues because of the IC. (Shape of new C objects determines prototype).

Some shapes slow down ICs. For example, when passing a lot of shapes, except on Opera. On Opera shapes doesn’t matter.

Properties in the slow zone (but there are variations across browsers): DOM access, Undefined properties, Scripted getter, Scripted Setter.

Type-Specializing JIT: Tracemonkey in Firefox 3.5+ and Crankshaft in Chrome. If JS had type declarations that would go faster. type-specializing JIT. JS will not get them quick. So a solution came up. run the program for a bit and monitor types, and then recompile optimized for those types. They optimize only the hot code because it is costly. tracemonkey does 70 iterations, crankshaft according to a profile.

Current limitations: what is happening if your type changes after the compilation. Just a few changes, no issues. A lot, the engine gives up and deoptimizes to basic JIT.

Type Inference for JITs

This is pretty much research and not deployed in any browsers. Basically trying to get rid of last few instances of boxing. Parsing the code you can understand what will be the types across the code.

A key to run faster in future JIT is type-stable javascript. Each variable having only one type.

Garbage Collector

Objects, arrays, strings, function objects, closure environments allocate memory. GC pauses your program. When GS runs, JS don’t. Basic GC algo is a mark and sweep by traversing all reachable objects and recycle objects that are not reachable. For safe GC, the JS is paused. Sometimes for 100ms. Which is long. For animation it creates deep issues.

• Generational GC: Optimize for creating many short-lived objects. Create objects in a frequently collected nursery area and promote long-lived objects to a rarely collected tenured area. Only chrome seems to do that. Overall, it creates fewer pauses. Basically you keep what is important and is likely to stay around.
• Incremental GC: Do a little bit of GC traversal at a time. (research @ mozilla)

Performance faults

tiny changes might affect performances.

• Strings sometimes faster than you think
• Arrays. important to dense array with contiguous indexes. 3-15x slower with sparse array
• Iteration over arrays
• Functions they use ICs
• Creating objects (constructor on chrome are fast)
• OOP Styling
• Exceptions
• eval and with

Top 5 things to know.

1. Avoid eval, with, exceptions
2. avoid creating objects in hot loops
3. Use dense arrays
4. write type-stable code.
5. Talk to us

JS engine devs want to help you.

Lessons from Yahoo’s Homepage: 5 tips for High availability

Jake Loomis is in charge at Yahoo! of VP. The most visited Web site in USA. over 600 millions global users. 300k+ servers, 100pb+ storage. The Yahoo! home page is the entry point. around 40,000 requests per second. When Yahoo! went down it made a lot of news. Amazon or Playstation outages have business consequences

Tip #1 Redundancy for everything

Down to the code, application features. Understanding your system’s failure points is very important. Everything can and will fail at one point. Redundancy at servers, network devices, colo loses power, user database. ad lookup fails, page fails completely (show a static page instead).

Tip #2 Error proofing change

Make changes in a safe environment. Practice how you play. Test also in environment which is very close from the production environment. QA environement has to be treated the same way that the production environment. Same logs, same type of catching issues. etc. Fork production traffic in the staging environment. We did that for Le Grand Club at RDS. You have to be able to recover quickly.

Tip #3: Global Load balancing

Route traffic to different places in the world. Ability to serve any market from any data center. If your site depends on one coloc, then there is an issue. By being close to the user, it offloads traffic, part of the performance issues.

Tip #4: Monitor everything

There are huge traffics you can prepare for such as a big planned event, like a royal wedding, but there are news coming by chance. These can generate stress on the infrastructure. At Pheromone, we were planning the days where the players of LNH are exchanged. Unplugging some features, etc.

Tip #5: Fallback plans in case of failure

What is happening and how do you handle in case of accidents? Isolate failure for not impacting users. You may want to drop features to add capacity. Learn from failures and followup.

Bonus Tip: Talent

“Having people who are talented is key. ” Well… lapalissade.

Opening Remarks - Jesse Demonstrates Caffeine IV

John Allspaw is being graduated as a co-chair of the program of the conference. (sponsors thanks).

Career Development

Theo Schlossnagle is talking about career. He has been a system engineer before being into Web Operations.

A career is a journey, a willingness to mature, a patience to become exceptional

Whatever we do we must treat it as a craft

• step 1: educate yourself
• step 2: be disciplined. It takes time to be a master, it is a long eay
• step 3: learn and share with your peers.
• step 4: be patient: experience takes time

your website is a SaaS, whatever the type of site as soon as you have users. The product (Web site) is one copy and has to evolve, perform and deliver. COO is someone responsible for daily operations. DevOps is bullshit. DevOps is incomplete and too limited. We need .*Ops You need operational mentality for delivering to users expectations. The job will require a lot of competences such as languages, and Ops’ Job were deployment, resources management, etc. There is no magic. The cloud is not a solution. Virtualization is the interesting part. Provisioning is not an operation jobs. Being in the cloud is not a guarantee. Security is not a feature, it is a state of mind, everything has to have security. Operations is the same. Everything have to be thought. We are responsible for everything and be on call. If you break things at 3am you have to be responsible for it, it means fixing it.

• rule 1 : what you build will break.

Operational thinking… there is a need for more ops into dev. To be able to debug in production because it is where things break. Titles don’t matter. Everyone of us is responsible. This mentality is the beginning of your career.

@postwait

JavaScript & Metaperformance

Douglas Crockford time! Javascript was not really efficient but it has changed. There is no time for optimizing because javascript is mostly executed on load. There is a trade-off between optimization and portability. Portability is the best thing for the Web. Java is the biggest failure in the histore of software development. Failed security model, lack of portability, awful UI toolkit, horrendous startup times.

Optimize as you go. It is a style which has been developed for the self language and applied later on to JS. The new engines are fast, but it is complicated to understand how they are faster. Having an accurate answer is almost impossible to know. Benchmarks tend to be written by people who don’t really know the language. There is a bias. JSMeter showed that benchmarks have no correlation with real use cases, but you need them to have numbers.

The browsers are basically a black box. Browser platform contains some deep inefficiencies with little visibility of them. The DOM is a bottleneck. The DOM is the PITA for making faster browsers. Optimizing JS code is not really effective. Premature is the root of all evil —Knuth. Web dev have a tendency to optimize in advance because they think they will not have a chance to do it later. They sometimes use the winner instead of something that will scale better. Benchmarks driving engine performance driving programming style and in the end discourage good programming practices.

JS has good parts (book plug). JSLint will help to improve the code. The benchmarks do not reflect the characteristics of a good program. JSLint.js is a benchmark. The results show only what they do against the browser.

from 2.80s to 0.54s with opera in the middle. (photo)

Because of this everyone is getting much much better.

Look at Your Data

John Rauser is introducing on how to look to your data. Timeline series give us hindsight. Analogy with a piece of arts and how we analyze them. Is it not always meaningful.An average and the medium are very lossy compression algorithm. There is a lot of complexity behind the mean. A simple line might hide a lot of stories.

How can we look more deeply at our data?

Histogram is a first step, but be careful they can hide things too. Each curves have hidden meaning. For example do a latency vs count in histogram. If the customers are well behaved you get a game curve. But with more complex shapes you might show different types of customers.

(remind me the story of RDS data)

By manipulating data you will reveal little by little patterns and become aware of what seems to be wrong in the data. Sometimes you have to look at individual hits to understand.

Some low techniques can help a lot, grep, printing on paper, etc. might help to understand. The screen is sometimes too limiting. You have to sculpt the data. Your brain and your eyes are a tremenduous pattern matching tool. The size of impacts can be sometimes smaller than a pixel in a curve but might give a very bad experience for users.

Look at your data to understand your business and your customers.

Testing and Monitoring Mobile Apps

Vik Chaudhary, Manny Gonzalez giving a sales speech.

Advanced Postmortem Fu and Human Error 101

Etsy is hiring. A Website is always a complex, dynamic system. There are always fundamental surprises. A love affair is a fundamental surprise for the one who is discovering has been cheated. There is always a balance in between Efficiency and thoroughness. Organizations are the blunt end. They provide the scaffold for people at the sharp end, operators. Post-Mortem is about telling the past. We do them to understand the system we are working on. Networks, Servers, Applications, Processes, People. The People are part of the system.

The conversation with Gene Hackman

To check that.

You need data and graphs to understand. IRC logs, annotation traces. It is important to inject the history of events into the graphs.

• When are things starting,
• when it has been detected? TTD
• When do you resolve? TTR

Basically how do you monitor the system and your ability again to resolve a bad situation.

Severity

We have to define what is important to your system. Not the same type of severity for every Web sites. John has levels of severity for Etsy. Post-Mortem being about the past it is filled with a lot of stress and mis-representation of what it actually was.

Ignoring how people feel is a huge mistake. It has to be taken into account. Some crisis patterns include things which have not been fixed for a long time. It ensues shame.

When the response is very long. There is a complex system field which involves stress growing exponentially until it is stable. What happens during this time have a strong influence on the way the company evolves and the technology. It challenges everything: people roles, capabilities

There are situations where you are not stuck enough and some where you are too stuck. Heroism is wrong. If the person doesn’t fix it, we lost time. If the person does fix it, we rely on singular people.

Improvisation is key to success. It helps to fix unexpected events.

Hindsight bias

Knowledge of the outcome influences the analysis of the process. In reality is a lot more complex than the scenario you had imagined. Before the accident: The future seems implausible. After accident: Obviously clear. “how could they not see the mistakes.” People have a tendency to want to be right instead of being objective.

Root Cause Analysis

There are many methods. A popular one is the five “why?”. Repeating why a few time and finally we get to the root of the issue. It is a good method for making people talk about it, but it is a sequential model when systems are more complex. Sequence of events model is easy to explain, and easy to understand, so they are reassuring, but it doesn’t take into account the surrounding circumstances. It is not helpful.

The domino model is better but still unhelpful.

There are always multiple contributors. Systemic is a lot closer from the reality, but we have to include into it sickness, people are not here, budget, etc with a lot of interdependencies with the computing systems. The blunt end always need to be included. Functional resonance are important: people with bad mood, the finance department.

Causes are constructed, not found.

Preconceived notions on “causes” and behaviors. We have to talk about contributors, not causes. There is no single root cause of your failure.

Human error

Nobody comes to work to do a bad job. The work always makes sense to them. It is not by bad will. It is useless as a label and ending point for discussing stuff. “Be more careful” doesn’t fix anything. Human cause isn’t a cause it’s an effect. Why it didn’t make sense at the time for the person? Error categories? Slips, Lapses, Mismatches, Violations. Useless, they do not help to prevent them.

What and why do things go right?

You have to look at what you do right. There will be more things to look at. Why don’t we fail all the time? Be open about your mistakes and clear such as “don’t do what I just did”. Examine how changes (at all layers) will produce new vulnerabilities? Use technology to support and enhance human expertise. Automation is not an holy grail. There will always be a machine-man boundary. Explore with new forms of feedback. The systems are not inherently safe. Somehow pre-mortems are better than post-mortem. It is what I call Optimization.

Adjust culture

No Blame. No Name. No Shame. It is not helpful. Punishment is not leading to good results. Punishing deterrents is a losing proposition. Firing people, reducing pays, etc. cause more stress and will certainly entail to hide future failures, which is bad. Making errors are not choices. so Why are they happening. There are discretionary spaces where humans have controls over situations at any levels and then there is an idea of accountability. There is a blurry line between unacceptable and acceptable. The question is not necessary where is the line, but who draws the line and are people aware of this line? You need to make people aware of the position of the line. Supporting learning then you increase accountability. Basically you make people responsible of their failures. “I screwed and I will fix it”. People can own their own stories and allow them to educate the organization. Anyone will benefit. It creates anticipation over failures. Accountability means also authority. People must have the possibility to fix things.

Questions

How to include people outside of the organizations in the process? Different vendors have different ways. If they do not align with your ways, then you have bad luck.

It might be difficult to engage the manager in that new culture.

The search for causality in our cultures has to be blamed on René Descartes.

You might want to test your infrastructure by creating failures. But you can also put the team in a disorienting scenario will look like a failure to detect what will be the challenges to fix in case this scenario appears.

Performance Tools

Room is full. Mention of the Hyatt strike again. Maybe is it because I’m French, but I would say to O’reilly staff… please, get over it. People fight for their rights. That is good. No need to be sorry.

In August 2009, ninety-eight Hyatt housekeepers in Boston were let go and replaced with cheaper, outsourced labor and the union has consistently held up Hyatt’s actions as an example of unethical decision-making in the hotel industry.

The Hyatt contract covers 1,800 employees who have been working without a contract since Aug.

Follow their fights on their web site : Unite Here!

WebPageTest

Introduction of Web Page Test tool. Patrick Meenan is switching through pages, but not very dynamic in his presentations. From the back of the room, the Web pages are barely readable. He is demonstrating the record of Web pages to show how fast the page is loaded. Eric Daspet introduced all of these in a better way at SudWeb Conference, including comparing two pages in different conditions.

The code is opensource and some companies are running private instances of the code, but it is difficult to know how many are doing it. There is also an API for plugin the tool into other applications.

MobiTest

Craig Conboy helps discover how fast the Web site performs on Mobile devices with MobiTest. You can choose the devices you want to run on. The tool doesn’t provide a lot of choices for the devices and more exactly the combination browsers X devices. I should go on their booth to ask them about testing with Opera Mobile and Opera Mini.

I don’t want to go quantum, but when you measure, it impacts results.

They had to make changes to the code of Web Page Tests and these are back to the source code. But they haven’t (yet) open the platform. When capturing videos, the performances go down. They use videos capture every 1s.

ShowSlow

Sergey Chernyshev is talking about ShowSlow: archiving the performance tests results. It helps to access the progress made when improving performances. That would have been useful when improved the performances of RDS and Le Grand Club when I was working at Pheromone.

It’s very hard to do visualization properly, specifically in an automated way.

Dynatrace Ajax Edition

Alois Reitbauer talks about some advanced features of Dynatrace rendering analysis, javascript tips and tricks, markers, xml comparison, benchmarking, beacon upload, external testing. The Web site of choice for demonstrating performance issues is CNN.

There is a common pattern for all these tools. They do not scale very well on small screens.

I didn’t know about Speed Of The Web Web site. It compares the Web site with the mean on other sites.