irritated beyond belief

..rant..

It was annoying when Friendster was slow. I got over my sighs when Friendster went offline. I can even deal with Bulletin Board messages going down every once in a while. But, this has me outright angry:

Profile is unavailable

Your connection to this person is temporarily unavailable. Please try again in a few moments.

Every time i try to surf to someone; every time i try to bookmark someone; every time i try to figure out who a person is that sent me a message… Every time i get that. So, i have to sit there and reload, reload, reload until i get annoyed and quit. The problem is that i’m trying to write notes down on “configuring the user” wrt Friendster and i need to be able to get to the primary text for analysis. Thus, i’m bloody pissed.

It’s one thing to have slow servers… it’s another thing to make a technical nightmare out of something that was working. I don’t think that i’ve ever so actively watched as a piece of software degrades so consistently over time. Classic software engineering problem. Throwing more coders, more money and more hardware at something dreadfully broken and already patched doesn’t work. Even Macromedia knew went to re-write Director. And it wasn’t even this broken! ::steam::

Tell me, Nielson, is this impacting the return user numbers as much as i’m hearing it is? I know no one who is willing to surf through this many barriers.

../rant..

Print Friendly, PDF & Email

7 thoughts on “irritated beyond belief

  1. Abe

    Still think Abrams and co are incompetent, but this tech break down [ http://socialsoftware.weblogsinc.com/entry/3341461825857782/ ] gave me a touch more respect for what they must be dealing with.

    As for usage, I can’t imagine this won’t drive people away eventually. But the pool of potential new users also seems damn high. The real issue for me is do people go elsewhere or just leave the space entirely? More and more anecdotal evidence points to people just leaving the entire space. I’ve yet to encounter someone who’s left Fster and managed to shift their personal network to another service. Lots of Tribe and MySpace accounts out there that never really got more then an hour or so of attention. Still shocked at how such high % of fster users seem to have made the efforts to fill out an account and build a network.

  2. Adam Megacz

    Feh, I don’t buy this for a minute.

    Friendster isn’t slow because this is a hard problem. Given even a very small hardware investment (around $50k), their site should be lightning-fast for what they’re doing. Here’s an architecture that could easily handle 2 million users for that investment:

    Assume n users and m machines.

    Represent every user by a 32-bit integer (enough for every human on earth to have an account). Represent a given users’ friends as a list of 32-bit integers (you can actually do much better using huffman compression to reduce the coding length of people with lots of friends, but let’s keep it simple for now). Assuming that people have on average 100 friends, this means that each person’s friend list requires 400 bytes. For Friendster’s 2 million users (n=2,000,000) that’s 800MB for the friend graph.

    Now buy m machines and put at least a gig of ram in each one. Divide up the userid space across the m machines (so that machine z has all users for whom userid % m == z) and put the users’ profile information on the corresponding machine (his/her “home machine”). Also put the entire friend graph on every machine, pinned into memory.

    Then buy a bunch of front-end machines that take HTTP requests, come up with a query, and pass of the query (ethernet broadcast?) to all m machines. The (tough) queries are in the form “I have userid $UID, please tell me all other userids within four hops that have the word ‘snowboarding’ in their profile”. Each of the m machines determines (locally) the list of userids within four hops for whom it is the home machine. It then executes the query on that subset of the userid space and returns the result to the front-end machine, who assembles the results into an HTML page.

    Salient features:

    * Since it’s in memory, walking the friend graph is so fast that the time required is insignificant relative to touching the disk to retrieve profile info.

    * Propagating changes across the friend graph can be done with ethernet broadcasts to all machines. If necessary, put two nics in each backend machine and put one of each on a shared subnet for broadcasting use. Even if you don’t do this, a friend-graph change is only 8 bytes of data (maybe 9), and the update is strictly in-memory, so you’re talking about almost zero network/cpu load.

    * The remaining performance barrier (actually running the queries on the profile info) can be made arbitrarily small by simply buying more servers, thereby spreading the work across more machines. If you want to get fancy you can try to inverse-cluster the userid space so that people in cliques tend to not be on the same machine (actually in some cases the exact opposite is a better idea). The point here is that you can buy *more* hardware (the cost of which scales linearly) instead of buying *bigger* hardware (the cost of which scales exponentially).

    * Buy machines with decent memory throughput. With an 800MB in-memory data structure, your cache is completely useless; you’ll actually get *better* performance out of a machine with *less* L2 cache. Most intel hardware has very poor memory throughput; belive it or not, you might actually get better performance out of three-year-old Sun hardware for the same amount of money. Avoid Rambus RDRAM architectures like the plague.

    * The data sent over the wire (between front and back end machines) is minimal; only the query and the results are sent. Other designs wind up sending lists of userids over the wire, which can easily be larger than 100MB before filtering.

    Now, personally, I’d use a custom-written transactional layer on top of BerkeleyDB, because you can make it obscenely fast on this sort of query (select * from users where userid=u1 or userid=u2 or…), but to get stuff started MySQL should work for a while; profile updates are pretty rare, and rare-write is the lone case where MySQL’s performance is actually decent.

    We all know that friendster wants to be fast and has plenty of cash. The only remaining conclusion is that their architecture was chosen unwisely.

    See also my post to hibernate-devel about in-memory queries on datasets that don’t fit into ram: http://www.mail-archive.com/hibernate-devel@lists.sourceforge.net/msg02952.html

    BTW, I consult on stuff like this. http://www.megacz.com/consulting.html

  3. k

    I have gotten tired of this problem too, but ironically I found a thread in the friendster sucks tribe where someone said to use the Opera web browser. Poof! Now the profiles show up, and I can see the pictures finally too! I still get some problems with the connections being unavailble, but maybe this will help you.

    By the way, I like your blog. I’m not sure how I stumbled upon it, but I agree that networks are rather interesting.

  4. Ryan Schultz

    The tip about using the Opera browser was from me. I was thinking about posting it to my network on Friendster. I got sick and tired of Windows Internet Explorer choking on displaying images, so I thought I’d give Opera a try. Worked like a charm.

    In fact, I like Opera so much it’s now my preferred Web browser.

Comments are closed.