#VelocityConf: Mobile Performance from the Radio Up

I seem to be going to a lot of really deep, low-level talks this year. I think it's good to get a refresher and see what has happened in these spaces since I learned the first theoretical bits over 10 years ago. Unfortunately, most of the material in this talk didn't exist 10 years ago, so it was fairly new. There are obviously two types of radio we deal with on a regular basis: Wi-Fi and 2g/3g/4g.


Leaving out a lot of the detail, Wi-Fi is Ethernet over the air. This means that the collision detection and avoidance systems are exactly like Ethernet. Of course, it's been a while since we used Ethernet hubs, so the collision issues are really about whether you are trying to send while receiving, so they don't happen very often. In Wi-Fi, you may be colliding with someone using the same frequency on a different network, so it's much worse than Ethernet ever was. Because of this, the protocol is not necessarily adapted to the task of wireless communication.


The cellular protocols, on the other hand, are designed for stability and scalability. They are also designed to optimize battery life. As a result, there is a radio resource controller (RRC) that will handle assigning time slots, powers, and modulations to any data-sending tasks. Once this has completed, the controller may choose to power down the radio. Unfortunately, this power-saving mechanism also means that the first packet is often very slow, sometimes many seconds are needed just to re-create the network connection.

The key to this issue is to ensure that your mobile applications and sites respond instantly, if only to let the user know that something is happening. After that, you may be at the mercy of the network.

#VelocityConf: The CSS and GPU Cheat Sheet

Today, I also attended a talk on CSS and GPU interactions and exactly how they work, at least in Chrome. The insights are very helpful, though. My biggest concern with this information is how little it may translate to other browsers. If Chrome chooses a certain way to split rendering tasks, what is to say that IE or Firefox will choose the same mechanism.

In any case, the idea of the web page having layers is very important. All of the translate, scale, and rotate properties that deal in 3 dimensions will move the element into its own layer. In Chrome, this gives it a different frame buffer to work with. Doing this can give you some big benefits, especially when elements move in relation to each other. The best analogy is to consider the layers as reference frames from physics. Each component that moves in relation to another is in a different reference frame from the target. That way, the GPU can optimize how it deals with the various frame buffers and combines them.

Obviously, a lot of frame buffers will cause a performance degredation as the browser will spend a lot of time (and graphics memory) trying to manage them all. However, I wonder how this works on the browser with dozens of tabs open. At what point doesn't this matter anymore. I know we want to provide the best possible user experience, but limited memory for the GPU means that there is a limit for the entire system. It seems that your website performance may be affected by another tab using all of the graphics memory. If the user switches back to your site, you may have some significant responsiveness issues that are completely outside of your control.

#VelocityConf: Resolution for a Faster Site

After the keynotes today, I decided to just dive deep and go to a talk about how DNS resolution affects website performance. There are some really interesting things that I learned about how the different operating systems actually deal with DNS resolution. It explains a lot about how slowly things fail when your network goes completely down.

First, I want to say how absolutely terrible it is that Windows resolves DNS entries at half the speed of Mac and Unix. We're talking 600ms vs. 200-300ms. That's pretty insane. Part of that seems to be due t othe way that failures are handled and how IPv6 integrates into the equation.

It seems that when doing standard DNS lookups in an IPv4 world or IPv6 world (but not dual stack), a complete resolution failure is going to take at least 20 seconds, no matter what platform you are using. This is largely because these are the timeouts set, which allow the operating system to hit 3 DNS servers and then try the first one again. All of this is done serially, so it can be pretty painful with the various backoffs.

When you add a dual stack with both IPv4 and IPv6 into the mix, different operating systems will behave differently. Except on Mac, IPv6 will be preferred. In Windows the IPv6 version is requested first, requesting the IPv4 record only if the IPv6 record fails. Mac at least requests both in parallel and will use whichever it thinks is fastest. On the other hand, that doesn't encourage people to use IPv6 very much, does it?

Round robin can add entire new problems once the connection is being established. Trying to determine which host to use can be tricky as they may fail. Failover to the next option can take a very long time.

The short takeaway is that DNS resolution is not a trivial part of the request. If you're going for sub-1-second latencies, this can eat a significant portion of your perceived latency before you even know what the user wants.

#VelocityConf: Speeding up Your Mobile HTML5 Experience

Talk slides and resources

As usual, Max Firtman did an excellet talk on mobile HTML5. Luckily for him, the space changes so much that he can give a talk on the same topic every year.

The slides and resources are good, so I just want to point out a few things.

If we take the convention that 1 second is a fast page load and 100ms is a fast interaction response, the latency of mobile devices is pretty terrible with 2G topping out around 1 second and even 4G topping out around 180ms. When you consider that the radio might be idle, this gets even worse.

He also covered a lot of things that are good practices. The one I liked the most was his investigation of responsive design. In my job, we have mostly written it off as sending too much data only to have it hidden. He went further and pointed out the conditionals for IE that will never be needed on mobile. The large images and tons of unused CSS just make it more absurd. I fully agree with his statements to focus on mobile and do it well.

#VelocityConf: Bits on the Wire

Talk link

This was a really cool talk that walked down the network stack to really show how abstractions make our work possible.

The first thing to understand is that there are tons of abstractions that we rely on every day. Unfortunately, abstractions are usually not perfect, they leak concepts of their implementations into the interfaces they expose. This is a common problem in most software. The other problem is that abstractions, by producing more layers of code, are typically slower and less efficient.

He also made the statement that abstractions create problems you can't see. I don't completely agree with that. This is a rather long argument, so I may write that post later tonight.

Now, when you start dealing with abstractions and distributed computing, it is very important to understand how that changes the problem. One of the teams near me used to have a sign on their door with SOA fallacies. They included things like: "The network is reliable." He recommended a paper that I haven't read called "A Note on Distributed Computing". I will have to look that up. In any case, the general upshot is that the partial failure modes and concurrency in distributed systems can cause headaches for anyone used to a localized world. I cringe to remember the days of working with WebSphere and getting the "success: maybe" log messages.


As we've learned, especially when trying to write a REST service, HTTP is hard. It's a really complex spec that was apparently rushed in the first place. The new version of the HTTP 1.1 spec is apparently going to be better-constructed and in 6 parts rather than a single 170-something page document.

From the wire perspective, the key to HTTP is the headers. With headers, I have my second new tool of the conference: REDbot. This thing is cool. It will tell you everything you're doing wrong with your headers. I think we need one of these at my job. There is also htracr, which will show you the actual network impact of your HTTP requests. As a colleague reminded me this morning, the waterfalls produced in most of our tools are how the browser percieves things, not necessarily how the network behaves.

Problems with HTTP

Other than its paralyzing complexity, HTTP has problems created by some of its "solutions". The best example is pipelining. Pipelining has been part of the spec for a long time, but no one uses it due to the fact that the client cannot know the best way to use the connection. Therefore, it is absurd to think that the client should direct the pipelining, which is what the spec requires.


Obviously, there are good and bad intermediaries when dealing with HTTP. The good ones are proxies and gateways. These are configured by the client or the server for very specific reasons understood by the party configuring them.

On the other hand, the bad ones are prevalent and occasionally malicious. They include virus scanners and content modification systems. The fact that there are prevalent specs around content modficiation scares me. Now, I'm really starting to think everything should be done over TLS.


He also talked at some length about DNS, which was interesting but not necessarily good material. The cool things I found were a tool called dig, alternative DNS services (OpenDNS, Google, and Comodo), and how terrible our ISP routers and modems are. I also learned how easy it is to spoof DNS responses and requests, both of which can be used for very malicious attacks.

TCP and IP

The lower-level stuff was all interesting, but I think the slides are pretty good on those. The one thing that I found really interesting was around the congestion windows for TCP. The fact that packet loss is used as the determination for when a network is congested must be a nightmare for mobile devices. Even wifi must suffer from this at times. It seems like we need a better mechanism for determining when the network is congested.

Next Page ยป