Skip to main content

Slowness, Unreliability, and Errors are Pervasive to Facebook

Facebook (FB) is already part of life for millions of individuals across the globe. It's already among the Internet giants like Google, Yahoo, YouTube, Amazon, & e-Bay. It has evolved as both a social interaction tool & a real-time communication tool (many Yahoo & MSN messenger users have switched to FB because of the chat feature). Unfortunately, most users will agree that FB is nowhere close the standards set by Google, YouTube, & Amazon when it comes to responsiveness, reliability, & availability. Personally, I have experienced extremely slow page loading, many error messages, not allowing me to login or post messages, and show only subset of postings by others. Hence, I don’t depend on FB to contact others & have a low appreciation as a useful service.
FB seems to be relying on extensive JavaScript & extended variants of MySQL, PHP, & Memcached. It's understandable that FB has to handle so much data, users, & their relationships. Unfortunately, heir underlying architecture seems to be not scalable. MySQL & PHP may be extended only to a certain extent. May be FB needs to look into completely new approaches like what Google (MapReduce, GFS) & Amazon (Dynamo) have done. Alternatively, many poorly written 3rd partly applications are breaking FB than making it. I don't have a solution for these problems, but I feel this is a good opportunity for research in handling large-scale data objects in a multi-user interaction based distributed environment.

Comments

Popular posts from this blog

1. Building P2P Simulators with OverSim - Where to Begin

This could be a series of blog posts about extending or developing your own OverSim applications & overlay networks. OverSim has a minimal tutorial on writing your own application & overlay network; however, it doesn't show the big picture. So, I'm wasting lots of time playing with code & trying to understand the rest. Good thing is, I like it more & more as I understand. You need to change/develop only a few things, but finding out which ones is a hell of a task. I hope this will not only make my life easy but also will be useful to new comers. Here's what you need to do: You need some background on OMNeT++ OverSim extend OMNeT++. But sometime it has its own way of doing things (to make your task even simple) so understand the differences . Develop several OMNeT++ simulators. TicToc is a good one to start with. Extend it as you imagine. Read Towards a Common API for Structured Peer-to-Peer Overlays , which is the basis for OvseSim's AP...

Key Application Layer Functions

Constructor  Can be use to set message to NULL . Better not to skip defining the constructor. Destructor Can be use to clear/delete messages using cancelAndDelete() . New version seems to be motivating to use a destructor so better not to skip. void initializeApp(int stage) Can be used to initialize the application, read parameters from omnet.ini file, set statistic collectors, GUI display variables, start timers, set UDP port, etc. stage - Indicate which stage your are in. MIN_STAGE_APP indicates this module is being created while MAX_STAGE_APP indicates all modules were created. We typically need MIN_STAGE_APP to i nitialize application & variables. void finishApp() Called when application is terminating. Can be used to summarize stat. New version seems to be motivating us to delete messages in the destructor.   void handleTimerEvent(cMessage* msg) Handle event timer. Use to generate new periodic messages, other events, or check for lost messages. Bett...

4. DHTTestApp & DHT

DHTTestAPP & DHT work together where DHTTestAPP utilizes the DHT to store & retrieve (key, value) pairs. DHT utilize the underlying overlay to route queries. DHTTestAPP Is a Tier2 application that periodically issue DHT put, get, & modify queries. The implementation consist of 2 modules: GlobalDhtTestMap - Provides a data structure & functions to maintain a global list of (key, value) pairs. Random keys are taken from this list to issue DHT get & modify queries. DHTTestApp - Issues DHT put, get, & modify queries after some delay derived from a truncnormal distribution.  Put messages - Use to add a random (key, value) pair into the DHT. A put message (represented as DHTputCAPICall ) consists of a random key, random value, expiration time ( ttl ), & whether (key, value) pair can be modified. Then the message is send to the Tier1 application using sendInternalRpcCall() method, which will store (key, value) pair in the DHT. When a successful re...