PBwiki versus the speed of light

Here’s some timing data for a simple request to one of our development servers.

  1 ms - server A (San Francisco) -> server A (San Francisco)
  7 ms - server B (San Jose) -> server A (San Francisco)
 55 ms - PBwiki office (DSL + Ethernet, San Bruno) -> server A (San Francisco)
137 ms - PBwiki office (DSL + WiFi, San Bruno) -> server A (San Francisco)

Here’s something I hadn’t really put my head around before: The convenience of using WiFi comes at a huge cost — it adds 80 ms to an otherwise identical request.

Hmm. What this data says is that no matter how fast we make our servers, and no matter how efficiently we tune our code, the speed of light and other things we don’t really have control over (like that 48ms of ‘DSL stinks’ penalty) are major factors for your perception of PBwiki’s speed and overall ‘snappiness’. Let’s say wiki pages take 80ms to generate instead of the trivial test above that took 1ms. Let’s say we optimize our in-memory caching, then tune some other things and end up shaving 10% off of that, down to 72ms. An end user with DSL and WiFi would see their 220ms round trip time go down to 212ms — less than 4% improvement, and that’s assuming they’re right here in the Bay Area, which most of you aren’t.

That 80ms WiFi penalty is coincidentally about the same lag you get for being on the East Coast when accessing anybody’s servers in San Francisco. That’s one of a number of reasons we’re drawing up plans for an additional data center, likely in Virginia. We have a lot of users in New York and Washington DC in particular. That east coast presence will go a long way to improve the browsing experience for our European users as well, and as demand grows and revenues permit we’ll be bringing on a Continental data center, too. We’re working hard behind the scenes to make your wiki experience better.

Published by pbwikinathan

I'm the CTO of PBworks, Inc. We help organizations work better as teams with their clients and partners.

5 thoughts on “PBwiki versus the speed of light

  1. I found that I could use ‘curl’ to time connections to web sites. For example,

    curl -w ‘\nconnect %{time_connect}, total %{time_total}\n’ -o /dev/null http://kernigh.pbwiki.com

    Here in the eastern USA, I find that it takes about 122 ms to connect to kernigh.pbwiki.com and 500-700 ms to download the wiki page. (A ‘ping’ needs about 95 ms.) However a real browser would be slower because it would have to download images/css/js, and I have not found a timer in Konqueror.

    Maybe there is a Firefox extension that times connections…

  2. DSL stinks?
    I guess “fragrance is in the nostrils of the beholder”.
    DSL is massively more fragrant than the dial-up we used to have.
    Nonetheless, those are very interesting data points – I think you’re surfing on the surplus brainwaves available in the Bay area and Silicon Valley. You get a speed boost that way.

  3. The Akamai service is a great and affordable way to go as well. (I’m not a salesperson… πŸ™‚ ) They have 15,000+ servers all over the planet – and they figure out which server is closest to the user. That buys a lot of peace of mind.

  4. @Bloodbeard,

    Asia is next in the queue after East Coast US and Western/Central Europe.


    Yep, curl is one tool we use (almost the exact same syntax, actually) and there are a couple of other things we do to measure download speeds and times. The Firefox extension FireBug is very good for this kind of testing as well.


    We’re looking at a number of possible solutions, including Akamai (simple, expensive), our own hosted servers (tricky, expensive), co-located proxies (relatively cheap, relatively simple) and simply placing a couple more static asset servers around the world (relatively cheap, very simple)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: