Sameer Parwani

Elgg is the cream of the crop of open source social network software, a group which includes other products such as Dolphin, PHPizabi, LovdbyLess. It’s also significantly superior to low cost white label social network software such as Handshakes, phpFoX, SocialEngine, and so on.

Elgg stands out because
a) It looks beautiful and has a good feature set out of the box
b) Encourages the community to contribute to the project with plugins and themes. It aims to be to social networking what Drupal/Joomla are to CMS systems.

However, if scalability is a top or immediate concern, be warned Elgg may not be suited for you. Elgg attempts to make plugin development extremely easy by avoiding the need to directly work with or even think about the database. All blog posts, blog comments, wall posts, forum discussions, plus data your plugins may save are stored into a single metadata table. Over time that table will become huge and umanageable. 

Further, the database is laid out in a highly normalized form which is not ideal for performance, as it requires joins to be performed over multiple tables. A quick look at the db profiler shows many page loads that require over 100 db queries. 

Therefore I would recommend that only small scale web sites use Elgg for now unless they are confident in their abilities to optimize the architecture. 

Scaling the Elgg Database Hardware

If you plan to leave the core of the Elgg engine untouched you will likely have to rely on standard database replication to scale the database.

Replication is a process in which a “master” server receives all writes and pushes the queries to its “slave” servers. Reads can be split between the master and the slaves. Unlike with partioning, replication requires that every database server keep a copy of the full data set. Therefore, you can’t use commodity hardware to split the work up between many small servers. Instead you will have to rely on small number of superservers to be able to scale Elgg. Thats the only way that the metadata table will not kill your performance.

Introducing a Cache

Elgg does not use persistent caches. If you are willing to modify the engine of Elgg (which will make upgrading much more difficult), using a cache will likely improve performance greatly. I prefer to cache granular data; for example I would cache the user row from the database instead of the user profile page. However, with Elgg’s use of join queries, it may be difficult to properly invalidate and update the cache when data changes.

You will have to selectively search for the appropriate places to introduce a cache (I suggest memcached). Start with simple queries that are repeated on every page load but rarely change such as loading the site settings. Then, look for other queries that work on single tables (no joins). If your social network is not a walled garden, there are probably even many pages that you can cache on a full page basis using either memcached or even squid. For example, Wikipedia has customized user pages but for the most part they can cache full pages.

Conclusion

Elgg looks like it is shaping up the be the premier open source social network tool by far. It is in active development and has a growing community supporting it. Plugin development is simple and allows for rapid deployment. Use Elgg if you need to get your site live ASAP and are focusing on a niche area with under 100,000 users unless you are prepared to do some heavy optimization. But if you want to be the next Facebook or MySpace or even something like Hi5, there is no chance Elgg will be able to scale in its current form. On the bright side, the Elgg developers promise significant speed improvements in the 1.1 version which is scheduled to be released shortly.