Optimization of Elgg

Performance is always very important for social networks. Our company focuses on development of high-load Elgg-based websites. We decided to share our knowledge with a set of articles. First two articles are available below, some new articles will follow shortly:

We encourage you to register or subscribe to RSS feed to receive notification about new content when it appears (no advertisements or other notifications will be sent).

  • Any simple takeaways that we can incorporate in Elgg today?

  • Evan, a few months ago I sent to Cash our report with a list of fairly simple modifications that can be done to improve performance of Elgg. I didn't receive any note from Cash wether those modifications were added to trac or used in code (last time I asked at 1'st March).

    I still have the list, I can resend it to you - please just give me your email via pm.

  • We've added a new article, "Profiling social network". It describes how to measure performance of a social network.

    If you have any questions regarding this topic - just ask :)

  • Mike, I've read the article about High Performance Elgg. Great, and I already had some thoughts in that direction. And nodejs is a cool idea.
    Can you provide me with a link to a living site?

    Do you have experiences on how search engines will index the javascript content?

    One more thing, regarding server performance: I asked cash for a possible substitution of mySQL with a noQSL database, because the manner of saving Elgg data is much more schemaless and mySQL is not a very good solution (it may be a good solution for small websites with small traffic and not so many users).

    I'm already collecting some experiences with mongoDB - very interesting. You may find some notes here:


    As Cash answers, unfortunately currently it would not be easy to substitute the database layer, because there is no clear separation between Elggs model and a database abstraction layer. May be in later versions :-(

    I also would like to have your list with performance suggestions.



  • Westor, so far we developed two Elgg-based websites on node.js, they're not live yet. According to plan, first website will be launched as public beta at 15'th June, I can send you a link then. We also used controllees technology in our vazco_store and this was used on approx. 8 live sites, although for easier integration, node.js was replaced with PHP views there - and it's probably node.js you're interrested in :)

    Indexing is not a problem. We have a way to support it, although to be honest I don't rememeber details right now, I will have to ask our developer :) Anyway, in worst case scenario you can service indexing spiders with separate content generation engine. In HTML5 there are some additional solutions for this problem.

    Our developer is currently talking with Evan about modifications to Elgg's database layer to make it more independent. We provided code which should make Elgg less dependant of certain database solution, although  integrating noSQL would still require much work.

  • Yes, to see behind your node.js solution would be interesting. Espacially how you integrate all the plugins and widgets, themes etc and where the limits are.

    But I'm really interested also in your indexing solution. Some of the big players are going back to render their content on the server, because of that reason.
    Of course you can provide the search engines with different content, if you are able to recongnize e.g. a googlebot for sure. But you have to be very carefully with that. If the content you deliver differs from the browser rendered contend, you may be adviced in suspected by cloaking. Nevertheless such solutions are not trivial.

    You are right, I also see a lot of work (currently) to replace the database to another one. Let's see how Elgg goes on to a more clear architecture, then it will be possible.


  • Waoo Westor do you have intention to move elgg into mongodb ?
    or maybe create a specific version for it ?

    That is very interesting.

    What about cassandra ?

  • I think the effort would be to much at current state of elgg. A specific version should be possible, but expensive and it would be very hard (or impossible) to be upward compatible.


  • Westor, I talked with our developer. We don't have problem with indexing as every page is a separate request, even in case it don't go to PHP. From google bot point of view, it's the same as a standard page. I guess problem with indexing is when you have either a content which is updated realtime throught sockets (in such case, you just have to be cautious what to update this way), or when you display website in a javascript application which uses only REST API to get data.


    We don't use REST for a few reasons, main one being we would have to make a few REST requests per page load.

  • Mike, why not post your list here so we can all discuss the suggestions?

Performance and Scalability

Performance and Scalability

If you've got a need for speed, this group is for you.