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.
