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.
[Edit: We removed this after trying it out for a few weeks!]
Now you can follow the daily activities of the PBwiki crew – realtime! PBwiki makes fairly heavy use of IM already, so we built an IM bot that forwards certain messages to our newest wiki page. This means the page will receive tons of fresh insight into our inner minds. (Note: This may frighten small children!) But we think it is important to find new and useful ways to keep the PBwiki community updated on what we are up to. Enjoy!
It’s been on our to-do list for a long time but now it’s good enough for general use — our PDF export feature now supports more interesting characters such as what you’d find, oh, anywhere in the world other than the US. We’ve also thrown in image embedding and some basic support for tables and hyperlinks. It turns outÂ the PDF standard is pretty hard to do well, and we’ve been gnawing away at this matter for months. (Aside: guess what an ‘Acrobat error 135 is’ — we had to, it’s not documented) In order to fully support the kinds of html you can (and have) put in your wikis we’d have to basically rewrite the layout and printing engines of a web browser, and we’re not really equipped to do that right now. What we’ve come up with is a good balance between utility and scope — making it incrementally more capable would require a pretty substantial rework.
We’re thrilled to welcome Mike Bulajewski to the PBwiki family as a UI engineer:
Mike couldn’t decide if he wanted to create intuitive and beautiful designs, or write web applications that work, so he he came to PBwiki to do both. Mike brings skills in visual design, a love for intuitive interfaces, and the technical skills to bring them to life. He has worked as a freelance graphic designer, a performance engineer for Amdocs and a UI designer for Dun & Bradstreet, and holds a B.S. in Computer Science from Cal State Sacramento.
What this really means is that Mike can badmouth engineers with the marketing team, and then turn right around and mock marketing with the engineers. Clever, Mike.
Please welcome him to our team. And stay tuned for some dazzling UI changes.
(To see other job openings at PBwiki, visit our Jobs page.)
I’ve been running some internal stats on the various activity levels across the PBwiki landscape. This set of numbers breaks categories down by volume of activity rather than unique users.
How much activity on private versus public wikis?
Around 2/3 of our activity is on private wikis. Takeaway: Our users have found lots of uses for PBwiki that we don’t know about, and we’d love to hear your stories.
How much activity on free versus premium wikis?
More than 16% of user activity is on premium wikis. Takeaway: Lots of people are taking advantage of our great premium features and enhanced security. Yay!
How much activity among major browser families?
Around 56% IE, 39% Firefox, 5% Safari, <1% everybody else.
How much activity over SSL versus unencrypted?
5.5% of our activity is over end-to-end SSL, which is available for our Platinum and custom SMB and business packages. Lots of companies trust PBwiki with their most sensitive documents.
And Fridays are very serious.
Apparently some kid by our local Vietnamese place was making balloon … pbj sandwiches. They’re not usually that chewy.
These drives we’ve pulled from some old servers are about to head to the big drill press in the sky (i.e. destroying them and the data on them) but I’m kinda obsessive-compulsive so I had to sort them into piles by model. Horray, order!