Feeling adventurous? We’re building a team of PBwiki users to help us test out new features before they go live for everyone. We need about 100 testers who know their way around a wiki and aren’t afraid of the cutting edge.

If you’re interested in trying out new things ahead of time, don’t mind the occasional glitch, and are interested in giving us feedback, you can apply here. We can’t wait to hear from you.

When PBwiki 2.0 launched, it included lots of great new features, but one thing stayed exactly the same: the notification emails you got when somebody changed a page on your wiki.

We fixed that today — here is a sneak preview of the new version of notifications.

The new notifications…

• Let you see all changes made to your wiki
• Have shorter change logs, and are easier to read
• Respect your notification settings
• Won’t be marked as spam!

To get a sneak preview of these new notifications, go to your wiki settings and check the box that says “Sneak preview new version of notifications”

Keep in mind that they’re not quite done yet, so if you have any problems, just turn off the sneak preview (and be sure to send us feedback). Enjoy!

As many of you have already noticed, PBwiki recently added support for OpenID. What does this mean for you? It means that you no longer need to remember yet another password to log into your PBwiki account.

To use OpenID with PBwiki, you’ll need to do the following:

1. Get an OpenID.
   You may already have an OpenID! For example, you can use your Yahoo! acccount as an OpenID. Here is a list of OpenID providers. myOpenID is a great place to make an OpenID if you don’t already have one.
2. Log in to your PBwiki account using your password.
3. Click on your Profile tab:
   
4. Scroll down to the bottom of the Profile page.
5. Enter your OpenID into the the field labeled “Your OpenID”, then click on “Save”
   
6. Click on the OpenID logo on the login page. Or visit my.pbwiki.com/openid to log in to PBwiki with your OpenID. Yay!

If you want to learn more about OpenID, openid.net/what is a great place to start.

That’s geek code for “PBwiki loves South by Southwest!” One of the advantages of a tool that’s simple to get set up and running with like PBwiki is that you can use it to make quick, ad-hoc workgroups at conferences like South by Southwest. If you’re looking to post your own itinerary or put together a spontaneous birds-of-a-feather session, come set up a new wiki with us and email david+sxsw@pbwiki.com with the address and I’ll add it to the official PBwiki SXSW page.

Cheers,
David Weekly
Founder & CEO

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.

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.

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!

So we like to have fun here, too. You just can’t help but want to hack on neat projects with such talented engineers around, so Nathan, Brian, and I put together a computer that is attached to our wall with thumbtacks, displays hundreds of silly cats, and makes a sound whenever interesting things happen at PBwiki, like when someone upgrades. We tried having it make a sound whenever anyone edited, but the loud and continuous torrent of noises proved too much.

[flickr source picture w/ more technical details]

We’ve had a few people e-mail us with questions regarding the privacy and security of PBwiki. Is PBwiki secure? Is it managed by a 3rd party? Are PBwiki servers sitting in some guys living room or running at an appropriate colocation center?

In an e-mail written to one of our users, our master chief, David Weekly answered the questions above:

Our servers are in a 24/7 guarded facility in an earthquake-proofed building in San Francisco, behind several layers of locked, sealed, access-controlled portals. The servers are owned and operated exclusively by a select handful of our staff, who have had checks performed on them and have signed a strict zero information disclosure policy document. We do not use third parties to manage our servers.

The servers are secured with a custom-hardened version of the Linux kernel, with a hand-tuned per-server lockdown of services and custom assembled IP firewall rules to only permit legitimate traffic. We have many companies and organizations keeping some of their most confidential data with us; if they kept it on their own shared drives at their office, there would be a significantly higher chance of exposure from a break-in.

Yep, PBwiki is secure.

OK, not a billion times, but more like 6 times faster than we were a month ago.

When we first started out, PBwiki was super-fast because there wasn’t much going on. As we’ve grown two things have happened - first, we’ve added lots of useful features and second, we now have lots more traffic all the time. The new editor in particular has led to lots more users being comfortable with editing, and it’s a lot of code to serve up, so we were serving lots more data more frequently to lots more people. For a while we were working our original servers way too hard and the system wasn’t always keeping up with the strain.

Two things have changed: First, we purchased a big pile of fast new servers. Second, we rewrote a lot of the core of PBwiki’s code to scale more effectively. We wrote a lot of new code and also take advantage of a bunch of open source projects, including Pound, Lighttpd, Apache, eAccelerator, MySQL, Memcached, and MogileFS.

Shiny, happy, mostly idle servers

We’ve put in a lot of effort to optimizing the load times of wiki pages and in particular speeding up the new editor, since it’s a lot of javascript to load. The ’six times faster’ claim is for the time between when a user requests a wiki page and we’ve finished building it and start sending it to their browser — the ‘time to first byte’. What else does this mean? Well, last month we were averaging 50-100% CPU load on our servers. That means that at midnight in the US, our quietest time of day, we were still using 50% of all available CPU time to serve wiki pages, store edits, and build RSS feeds. During peak time around noon we were starting to back up a bit due to the load — 100% CPU load usually means ‘would go to 150% if we could’. We’re now ranging between 10% and 20% on all of the application servers, which means there’s always CPU time available for the next incoming request. The supporting servers, such as proxy, database, storage and email are even less loaded. This is a very good thing.

At the same time, we’ve got lots more storage headroom. We were running a little low for a while there and now we’ve got at least 6 months of space for new wiki data and attachments, assuming our current growth rates. Combined with our much-improved server monitoring system (thanks to mon, monit, cacti, and some hand-made stuff) we’ve got a great picture of how the service is running and for the first time in a while our servers are as happy as our users.