Cloud Four Blog

Technical notes, War stories and anecdotes

Mobile Browser Concurrency Test

We need your help for a research project. If you have a phone that has web access, please go to http://cloudfour.com/mobile/ to test the number of concurrent connections your phone makes. Your phone’s browser will need to display images for the test to work.

We’ve also set up a SMS keyword to make it easier to get to the test url. You can simply text MOBILETEST to 41411 on your phone, and you will receive back instructions on how to test your phone.

Please share this test with your friends and colleagues. We need as wide a range of mobile devices and browsers to test as possible to build a comprehensive database. We are interested in both smart phones and regular phones.

Why Test for Concurrent HTTP Connections in Mobile Browsers?

As we’ve moved from web to mobile development, we’ve found it difficult to find detailed information about the browsers on various phones. There are some good sources of information including Detect Right, Device Atlas, UAProf and the open source WURFL Project. However, none of these sources have exactly what we were looking for.

In particular, we’re keenly interested in the factors that make web pages load and render quickly. We’ve seen how optimizing web pages for performance can both make your customers happier and save large amounts of money on bandwidth and infrastructure.

With mobile devices, the speed of web pages is even more important given bandwidth, processor and memory constraints. Yet, for those trying to take advantage of the techniques promoted by Yahoo’s Best Practices for Speeding Up Your Web Site, it is nearly impossible to find how mobile browsers differ from desktop browsers.

What is Unique about this Test?

To our knowledge, this it the only public test that attempts to determine the number of concurrent http connections by observing the behavior from the server instead of the client. This is useful for any browser, but it particularly useful for mobile browsers where it is more difficult, if not impossible, to implement client-side network sniffers (which is the other way of observing the number of connections).

What are We Looking For?

The test collects quite a few pieces of interesting information, but we’re looking in particular for three pieces of information:

What is the number of concurrent http connections that the mobile browser supports both per domain and overall?

Does the mobile browser support gzip or other methods for reducing the size of pages?

Does the mobile browser support caching if you set the Expires header far into the future?

We’re also collecting some other useful http headers and combining it with WURFL user agent information on the backend to help us when we start processing the results. We’re going to look for any interesting patterns in that data, but the main purpose is to gather the three items above.

What Do You Plan on Doing with the Information?

We’re also exploring how this data could be contributed to the user agent databases like WURFL.

How Does the Test Work?

Designing the concurrency test was a difficult challenge. In order to have the test work for as many mobile browsers as possible, we needed to support XHTML-MP 1.0 (WAP 2.0). XHTML-MP does not support javascript which meant that all of the testing needed to occur on the server.

The basic test works by delivering a XHTML-MP page containing 64 images distributed equally across 4 domains. When the first image is requested by the browser, the server opens a connection and holds it open without delivering the image. It waits 15 seconds to see if any other image requests come in. As each image request comes in, the counter for the appropriate domain is incremented.

Steve Souders formerly of the Yahoo! Exceptional Performance Team and now at Google has been the leader in getting people to pay attention to browser performance. He also provided helpful feedback on our test for which we are thankful.

Finally, we couldn’t have completed the project without Jon Maroney from Free Range Communications who loaned us a BlackBerry so that we could find the most obscure of BlackBerry browser bugs. And our own John Keith who did most of the heavy lifting on the programming. John’s adventures included calling someone to change code while he was at an AT&T store so he could test using the specific BlackBerry model that was giving us so much trouble.

15 Comments on “Mobile Browser Concurrency Test”

[…] need your help for a research project we’re conducting at Cloud Four. Read more about the research and how you can help by simply viewing a web page on your mobile phone. This entry was written by Jason Grigsby […]

I figured you’d get plenty of testers using iPhones, so I didn’t bother with that, but I did just run the test using the web browser on my Amazon Kindle, in both “Default” and “Advanced” modes. Hope it yielded some useful information! :-)

I suspect you are going to find (if you haven’t already) that this method is not going to be usable in some carrier networks because the browsers on devices in those networks rely in part on proxies operated by the carriers — and specifically, on proxies that do certain kinds of image manipulation.

I live in Japan and the KDDI/Au handset I use here has two browsers on it: One is a version of Opera 8.6, and the other is v6 of the Openwave browser. Both of them rely on proxies, and I think the same is true for preinstalled browsers on handsets for other carriers here (DoCoMo, Softbank, and Willcom).

Yes, the proxies are going to be challenging. We’re actually looking for them in the apache logs. It was one of the notes we made in our methodology document about the potential short-comings of this way of testing.

So we recognize that as a problem and are going to try to correct for it when we analyze the data.

I wonder what results are you expecting from the actual majority of handsets. As you must already know, most mobile traffic happens to be handled by the wap gateway in the operator. So basically what you see on your servers (where your test pages are hosted) is the behavior that the wap gateway has about fetching URLs in a page, not the actual phone’s. Let’s assume a phone normal browser does open several concurrent connections, all of them will hit the wap gateway, who will consider doing whatever is best for handling overall traffic – not just this specific phone’s requests. So the point is, the actual phone’s bejavior is obscured by the existence of a wap gateway in the middle. Felt the need to clarify this, wap gateway and proxies to a minor extent is IMHO a major short-comming for this kind of tests. It will only work with smartphones and networks that allow phones to reach the internet directly, rather than actually normal networks (every operator has a wap gateway and most traffic is handled by such network element).
Please kindly reply, I’m intrigued. marionetazorz at yahoo dot com.

In today’s world you have a number of choices to make: what device should your application use, what operating system, what networks will be relied on? And the list only keeps growing. Why not make things simpler?

Join us for a spirited, knowledge-packed day scouting the frontiers of responsive web design and development in lovely Portland, Oregon. Responsive Field Day is a welcoming and affordable gathering for web designers and developers.