analysis of elgg performance using the newrelic online app

after some exploration of the extensive server monitoring and performance analysis app - www.newrelic.com

i have found the following with my elgg install (1.8.16):

  • minify: the minify plugin's minification process was being triggered in places where it didn't need to be and was hugely slowing down the website. solution/workaround: disabled the plugin and now use cloudflare's inline minification..
  • language translation: where specific language strings are missing from translation files a helper process of some kind is run to locate a suitable string (i don't know much more than that presently) - which was slowing the performance. temporary solution: disabled all non english languages until this can be resolved more effectively.
  • 'your groups' topbar menu: i am running a version of the plugin which adds a dropdown to the topbar to allow access to all the groups that you are a member of. this is very slow to process the required sql.. solution: find a more efficient query structure (details below.)
  • videolist thumbnails:the php file for the videolist thumbnails is the slowest non core file on my site by quite a long way. the server trace shows that the entire elgg setup of all plugin initialisation processes is being run each time the thumbnail.php file is run.. this is hugely inneficient. solution: the thumbnail php file access process needs to be redesigned.
  • pagehandler.php:some traces for pagehandler.php list the plugin initialisation process as running for 12 seconds per page load! 4 seconds for elgg_load_plugins and 8 for the various plugin initialisation processes. i do have 40+ plugins on my site, however, i think that there is a design flaw in the process here.. why are these plugins reinitialised over and over on each page load? and why are they ALL being loaded regardless of whether they are needed on the current page? surely there is much scope here for improvement? next step: pass to core team for comments.
  • elgg_view: the repetition of the elgg_view function so many times on some pages appears to add an overhead that amounts to potentially seconds of delay.. i haven't done in depth analysis of this, however, some pages (such as the activity river) trigger this view 30+ times per view - this soon mounts up. question:has anyone performed any detailed efficiency tweaking of this?

 

re: the your_groups query.. the present query used is:

    $content = elgg_get_entities_from_relationship(array(
        'type' => 'group',
        'relationship' => 'member',
        'relationship_guid' => elgg_get_logged_in_user_guid(),
        'inverse_relationship' => false,
        'limit' => 0,
    ));

does a more efficient query exist here that can get the current user's groups? can this be cached in a way that it isn't already?

any comment and answers welcome!

  • i'm looking at icondirect.php in profile/views..
    it begins with the engine loading line and ends with the engine loading line if there is no database connection, yes. i see that the second use would not be activated unless an error occurs.. though i don't know why booting the elgg engine is an appropriate fallback step at this point.

    the observation i desire to share most is that the elgg engine boot process involves running through all the plugin init files and i do not see any reason for that to happen more than a maximum of one time per page load.
    icons are not really pages, though php is serving them as if they are by way of header pushes. so the icons are triggering the boot process at least twice per page and potentially 10-15 times per page depending on the content of the page (a videolist index page for example would contain many icons).
    am i missing something here?
    isn't this is a considerable loss of efficiency?

  • @ura Note that engine gets loaded only on 75th line On line 10 we load only settings file.

  • aha, oh yes.. i was distracted by the hot sun here and all these pidgeons.. ;)
    lol.

  • awesome.. i have rewritten the videolist icon code to match the method used in the profile plugin.. the icons now load in 23ms instead of 2000-3000ms :)

  • so.. another issue i notice..
    is javascript loading in plugins is not context sensitive..
    hence i have a list of about 10+ javascript files loading on every page and some are for elements that only appear on one page on the whole site..
    is there any reason why this is done? or just that the coder didn't think to add the context check in the plugin's start.php file?

  • You should use elgg_register_js and elgg_load_js to load it only when necessary (ie. in view requiring particular one). It depends on your code though. If you _must_ load it every time, it's probably better to just extend js/elgg view to reduce amount of calls.

  • as an example - the river_addon plugin uses its own js file plus some other 3rd party ones..
    these are loaded using elgg_register_js and elgg_load_js - yet that by itself does not load them in a context sensitive way. they are loaded on all pages.
    i wrapped the plugin's main init function in a context check and now another 5-10% speed increase on most pages. ;)
    just another 40+ plugins to check now. lol

  • /engine/start.php is not a /airplane/engine/start ! if you think so? you need to provide good fuel for this airplane engine.

    NewRelic is dumb for me, see community.elgg.org is very old website and it is working fast and smothly! 

    If your server is good , no matter what type of application you are running on it.

  • all websites are unique and can be optimised uniquely.
    server cost money and burns trees.. code optimisation = free, clean and healthy. i can have a bunker full of technology or one server for $2 a month.. lol
    newrelic is helpful to me presently. such is the uniquness of individual expression.

  • @ Liang Lee - If you have a bad code, no amount of servers will save you when you have larger traffic. With bad code, scaling out is often also not an option, as by adding new servers you're not necessarily speeding things up.

    I know some Elgg-based websites which use servers for 2000 USD/month just to support 20k users, when they should optimize instead. Even excluding costs, at some point you reach a border you can't cross. I estimate that for Elgg this absolute border is (more or less) around 50k active users that use website for 1 hour per week - then no matter the server solution, you have to rewrite the code.

    Yes, you can improve performance by having a good server, however you can't do this indefinitely.

Performance and Scalability

Performance and Scalability

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