11 items tagged “friendfeed”
The principle reason they switched to a schemaless DB was to work around the challenges of having to make schemes changes in MySQL, which can lock the table and take hours if bit days to complete in large tables.[... 115 words]
It was written in Python, using the Tornado asynchronous web server (which the FriendFeed team developed themselves). They used their own schemaless NoSQL-style store based on keeping serialized objects in MySQL.[... 51 words]
We experimented with different async DB approaches, but settled on synchronous at FriendFeed because generally if our DB queries were backlogging our requests, our backends couldn’t scale to the load anyway. Things that were slow enough were abstracted to separate backend services which we fetched asynchronously via the async HTTP module.
Tornado Web Server (via) An extremely exciting addition to the Python web landscape, Tornado is the open sourced version of FriendFeed’s custom web stack. It’s a non-blocking (epoll) Python web server designed for handling thousands of simultaneous connections, perfect for building Comet applications. The web framework is cosmetically similar to web.py or App Engine’s webapp but has decorators for writing asynchronous request handlers. The template language uses Django-style syntax but allows you to use full Python expressions. FriendFeed have benchmarked it handling 8,000 requests a second running as four load-balanced processes on a 4 core server. # 10th September 2009, 9:32 pm
Paul Buchheit: Make your site faster and cheaper to operate in one easy step. Paul promotes gzip encoding using nginx as a proxy, and mentions that FriendFeed use a “custom, epoll-based python server” as their application server. Does that mean that they’re serving their real-time comet feeds directly from Python? # 17th April 2009, 5:19 pm
How FriendFeed uses MySQL to store schema-less data. The pain of altering/ adding indexes to tables with 250 million rows was killing their ability to try out new features, so they’ve moved to storing pickled Python objects and manually creating the indexes they need as denormalised two column tables. These can be created and dropped much more easily, and are continually populated by an off-line index building process. # 27th February 2009, 2:33 pm
FriendFeed launch a real-time API. This is huge: JSONP plus long polling Comet, with “everything since X” tokens to ensure you don’t miss anything. This is the first open Comet API I’ve seen anywhere. Combine this with FriendFeed’s regular API (which allows arbitrary message posting) and you’ve got a really powerful tool for hackers who want to experiment with Comet without rigging up their own infrastructure. # 22nd October 2008, 2:18 pm
View your FriendFeed in real-time. FriendFeed become the latest site to enable real-time updates using the long-polling variant of Comet. The real-time Web was something of a theme at this year’s FOWA, with talks on message queues, XMPP and scaling Comet at Meebo. # 16th October 2008, 2:06 pm
FriendFeed Blog: Simple Update Protocol. FriendFeed infamously poll RSS feeds on the 43 services they support millions of times an hour in an effort to keep their content as real-time as possible. SUP is a new proposal by FriendFeed for a sort of “master feed” of changes to a site—instead of hitting the Flickr feed for each of their users they would just poll Flickr’s SUP feed every minute or so to find out who had uploaded a new photo, and only retrieve the RSS feed for those users. # 28th August 2008, 12:16 pm
As duplicitous and sad as “fake following” sounds—and let’s be honest: the whole idea’s pathetic on a number of levels—for a certain kind of user, I can see why there’s a desire for this functionality. Especially on a site like FriendFeed, which has quickly become the platform of choice for the web’s least interesting narcissists—and the slow-witted woodland creatures who enjoy grooming their fur—this is a major breakthrough in the makebelieve friendship space. Yes, primate culture may be primitive, but it is not without its evolving needs.