The content of the presentation is basically in the slides (Powerpoint). The summary is that most of the time even in some surprising cases JPEG will achieve a better result in terms of size without hammering the perception of quality.
Posts tagged with "velocityconf"
The content of the presentation is basically in the slides (Powerpoint). The summary is that most of the time even in some surprising cases JPEG will achieve a better result in terms of size without hammering the perception of quality.
(the slides contains a lot of materials)
David Mandelin (Mozilla)
- Front End
- Interpreter (run the bytecode)
- 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.
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.
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)
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
- eval and with
Top 5 things to know.
- Avoid eval, with, exceptions
- avoid creating objects in hot loops
- Use dense arrays
- write type-stable code.
- Talk to us
JS engine devs want to help you.
It turns it is basically a webkit talk… sigh
- DNS (SYN),
- HTTP GET request,
- the server answers HTTP OK
How long does it take to get the response back: latency. Two types on 3G/4G networks.
- initial connection setup: > 1s (on older 3G)
- Round trip time (RTT): 80ms or higher (typically) the common is 100ms to 200ms
Every new lookup takes 1 RTT + lookup time. These lookups are expensive and may take until 1s. Domain sharding. Use of multiple domains, requests will be sequential in fact and you will not improve the performances on mobile.
Browsers typically use 4-6 sockets per host. On Android, there is thread per socket model and do 4 HTTP threads at the same time. Only 4 sockets can have outstanding HTTP requests (“active”). It has an impact on all domains.
It is possible to use pipelining, Android does 3 requests at the time when pipelining. Pipelining is not implemented in major browsers except on Android.
HTTP Caching. Webkit maintains a memory cache. The default size is 8Mb. Android has a persistent (file system) HTTP Cache.
Cache eviction policy is also a source of performance. Android policy: Prioritize base on expiration date. Far future expiration dates have higher priority. Evict lowest priority items first. It has consequences.
Experiment by visiting different web sites with an initial clear cache.
sqlite3 webviewCache.db 'select expires from cacher order by expires desc;'
Expiration Year far in the future will never go away of the cache. This is a problem. Cache eviction policies affect performance.
Power is another issue for performances. Web pages strain the battery. Checking the battery power consumption along the page download is enlightning. Any network traffic brings up the radio for several seconds, around 10s-15s. Using long periods for any periodic Ajax calls, etc. If the call is happening every 15s, you might be consuming a lot of power.
TCP FINS and power. Android closes TCP sockets after 6s of inactivity (IDLE). Sockets get closed at different times. Every socket close generates a TCP FIN. extend the dormancy timer. Solution: Close all sockets after the page is downloaded.
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.
The situation has changed a lot with regards to CSS3. Browsers have made huge progress on this area. There is a place in between no features but fast and the other one full featured but slow. The middle ground is possible. Drop shadows can be given up for making IE faster, exactly like rounded corners. Nobody opens a Web site in 5 different browsers except the dev community. You can give up some features.
Figuring out the user best interest is tricky but can be a part of your strategy of development. For example Sales Forces has decided to give a different design depending on the browser.
CSS can really improve the performances of your web sites. There are micro-improvements.
- Selectors are matched from right to left. For example if you have a * on the right you match everything.
- Selectors look like a regex with attributes selectors are slow.
- Kiss principle div.classname is slower than .classname.
- Opera’s selector test framework is very cool and helpful for understanding.
- CSS Stress test
- Transparency can induce a lot of complicated calculation. It will be expensive.
- Combining effects have side effects. It is important to test them.
What is the favorite feature of CSS3?
Images are a huge part of how much a web page performs. Some images can really be removed. Major image reduction is possible using gradients and unicode characters. Shadows can be used for giving bubble effetcs.
- zurb’s awesome buttons can be used on any background colors.
- Rgba syntax is very easy. (red, green, blue, opacity)
border-radius has issues with different borders width or stackness. Be careful.
they can achieve many things.
CSS Lint is a tool for checking the quality of CSS.
John Allspaw is being graduated as a co-chair of the program of the conference. (sponsors thanks).
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.
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.
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.
Vik Chaudhary, Manny Gonzalez giving a sales speech.
You are guilty. Users hate you. Mobile Web is slow, because developers are doing it wrong. There are issues such as slower networks, higher latency, slower hardware, different browsing experience, different context (beach, bathroom, in line, on the move, …). Browsers have different behaviours. For the same devices there are different possible networks with the same device. There are verbose HTTP headers for mobile browsers. There are browsers supporting 1, 2, 4, 6 parallel downloads. There are too many mobile browsers, some are too limited, and some are too innovative, some are proxied (doing transformations on the content). Some mobile browsers does not have documentation. Some of them do not have a name. And many browsers do not have debugging tools.
Features Phones (big market share) ← Social Phones → (big mobile web usage) Smart Phones
There are a few things to forget about:
- static designs
- Desktop frameworks (not always)
- always connected
- unlimited power
A few things to learn about:
- server side detection
- progressive enhancement
- responsive design
- best experience for each context
- top-model approach
Users need to perceive speed. It’s not really the real speed.
For debugging there are only two browsers who have a debugging tool : Opera Mobile with Dragonfly, and the Blackberry on Playbook. Most of the emulators are not good such iOS. There are not real emulators. There are free. You will need a proxy such as proxy Charles Proxy or Fiddler. Proxies will modify the real experience. It is not exactly like the devices. There are remote debugging tools weinre, jdrop, mobileperf
There are differences among devices for the support of html5.
Don’t be fanatic, be multiplatform.
Basically do not develop for one unique platform. Strange the speaker seems to associate the list of HTML5 devices with… OSes instead of rendering engines.
Some websites are too heavy for the mobile. As a result, people should think mobile first. A desktop website only doesn’t work for users. Mobile metatags and viewport will improve the experience. The speaker recommends server-side detection. I strongly disagree. There are PITA. People do not fix their web sites. WURFL gives server side detection.
Too many redirects kill the experience. united.com → www.united.com → mobile.united.com. Basically, it is important to not do it. It is important to deliver the homepage right away. In case it is absolutely necessary, only one redirect and cache it.
Simplicity is a key to success. Simple, semantic DOM will help. A complex structure will slow down the experience. New HTML5 rules and tags to reduce the load of useless nested div and span tags. Links without real href are likely to fail on blackberry phones where the JS has been disabled by the company.
- XHTML: 18kb, 180 dom elements, 145 class definitions, etc.
- CSS: 137kb, 6700 lines, 681 selectors
Optimizing starts with very simple tips. Using the html5 doctype, no xml ns, no insane attributes, there are new elements such as article, section, footer, etc. When redoing the Web site of United.
- HTML5: 1.3kb, 31 DOM, no class, <1kb CSS
same design using CSS. If CSS is not there, no design but working.
It is important to compress the components with gzip. Caching is a good friend. Stylesheets at the top. reduce dns lookups, external css and scripts t be cacheable.
A resource is not necessary an HTTP download. We can reduce HTTP requests. Every request hurts a lot, specifically in the mobile space. The ideal would be closed from 1 only request initial load. Sometimes no request is possible. There are techniques for doing that.
Images have to be limited to only the necessary, no effects, no ornaments. It is possible to leave it plain. It will be better for the user anyway. Use the possibility of css 2.1 and css 3. Images can be compressed. An image with the right context for every devices is sometimes better.
colorzilla has a tool for creating gradients.
CSS Sprites help reduce the HTTP requests with a very good support on Mobile. There are services such as spriteme.org. DataURI is also a good way to save an HTTP request.
For some very simple images, it is possible to use canvas drawing API and use toDataURL() method. Using Canvas it is even possible to download images and cache them locally instead of the originating server. It is possible to use emoji codes which have been introduced on Unicode. There are available right now only on iOS.
W3C Selectors API is available on the last generation of smartphones. Create your own mini-library. Use mini-framework. XUI, zepto.js, microjs.
United is using 3 framework on the homepage and two are not used.
Using cache is important.
It makes the application available immediately. Update process is tricky. HTML and resources into it, and then use localStorage for others. localStorage is easy and fast. Storing strings is twice faster than objects. It is possible to store images, code, styles, html elements and data. It can be mixed with cookies and create a resource storage library. On Mobile, it is possible to store until 2MB without issues.
Bing is using this technique.
On touch devices the click event is delayed in between 300ms to 500ms. It can be changed with
ontouchend with a progressive enhancement technique.
onhashchange for history management. use html over json over xml in terms of performances. HTML5 server sent events.
Basically do not decide for the user. The users may have a context that will enable them to enjoy the experience the way they want. W3C Network Information API will help to test the quality of the network.
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.
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.
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.
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.
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.
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.
Chef is a powerful tool for maintaining and describing the software and configurations that let a machine provide its services.
The more we can decouple, the more we can scale.
They define Chef as a
make for machines and as Git for machines. If the code is a 100 lines range, it is very easy to be maintenable. Smaller codes help a lot. Chef helps describe a good high level mental model for your machine. Even if you do not know Ruby, you can read the recipes for configuring the machine.
Code is inventory, the more lines of code, the harder it will be to move away from them.
A written code is legacy. The bigger the code, the closer from the Web it is. Plenty of legacy constraints.
Product’s job: give me, Engineering says: No way^W^W Yes!
It reminds me of long discussions between developers and product owners. The issue is always the same and comes from a lack of dialog and understanding of the consequences of decision. People should have clear KPI to be able to take decisions.
Do not try to solve problems you would like to have.
Or basically the old “If it is not broken, do not fix it.”
The two speakers are introducing Resque
“Resque (pronounced like “rescue”) is a Redis-backed library for creating background jobs, placing those jobs on multiple queues, and processing them later.”
They also used Flume for log aggregation.
Flume is a distributed, reliable, and available service for efficiently collecting, aggregating, and moving large amounts of log data.
do not write unit tests for High perf sites. Real world will always bites you. Watch matrix and spend time on recovery techs
Typically you can spend a lot of time writing tests that will never fail, but you are loosing time. It is better to be reactive and monitoring metrics and improve your techniques of recovery. How the code is designed to be tolerant for failures. Basically how is your code planned for failures?
Even if the code smells funny inside, but is super effective, then it is beautiful code
The important is to have code which is resistant to performance issues. Software purity doesn’t achieve that much in face of real world.
do not spend time in meetings, write code.
Engineers spending too much time to try solving issues in a meeting room instead of writing code and testing the results live is wasted time. Play with the real world data.
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!
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.
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.
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
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.