Elgg memory load on server RAM

I am interested in understanding more about the efficiency of the elgg script and its associated plugins as I was suspended by by hosting company the other day for exceding their fair usage of RAM... it is only a test site at the moment with a handful of users and the only active ones are all me!!

It would be good to hear from others who know more about this stuff... I ran Yslow ( http://developer.yahoo.com/yslow/) on a couple of pages, and yes... they did not perform very well... but I think there is more to do throughout the system.

The new style guides in elgg 1.7 will be a start no doubt,but this should have good practice (see Yslow above) included as well.

The other thing I find frustrating is the CSS theming... why can't the css be in one place and why is it so hard to get themes W3 Validated... all these things could be better more consistantly organised... surly?

Having css files everywhere and extending things left right an centre does smack of ineficiency, the YSlow referance points to some really good practice, but I do not know what to do about any of it though, it all seems overwhelming.

  • Hi Mark,

    Elgg is not a content management system but rather a social application engine driven by plugins. It makes sense, therefore, that the CSS is decentralised as each plugin needs to add its own.  And yes, the Elgg plugin model does exchange some degree of efficiency for flexibility and ease of development.

    You can, of course, create your own theme that over-rides all the core and plugin CSS in one place.

  • Hi Kevin,  Thanks for that clarification... I did not appreciate the differance, interesting.  PS... are you working on the caledar plugin still?  It is an important tool for many (well... 2634 for v0.81 beta). Regards, Mark

  • That validation does not work, is no excuse. Unfortunately, in the community it never was a big thing. I support the idea of more structure and solid validation. This should lead to more performance and far easier debugging. Further, I expect, that performance could be a lot better if we would be able to " pre-compile"/cache  more, for example to assemble all css in one file. Smarter ways to call the start.php when they are only needed etc. etc.

    Still.. with all the work we have to do, Elgg is a great project with fantastic potential...! )

  • As always, keep in mind that the software gives you a basis to create something brilliant off of an already amazing platform.  ...What is the most frustrating thing is conflicting over-rides and trying to figure out what to put under what in the plugins administration.  Many times, the plugin developers don't even know what to put under what, when running many (what we consider important, critical) plugins for our sites.  So, CSS becomes an issue too, as conflicts may arise.  Ultimately, it is possible to strip the CSS out from the plugins (or over-ride them, as Kevin said) and bring it into your theme and try to get more control and centralization over it all.

    @Mark - it sounds like your on hosting that is SO cheap, they ought to pay you to use it!  I use VPS' and have not had a problem with Elgg or RAM.  I mean, any CMS or eCart or social engine needs RAM.  Some of the CMS' are rather intensive and your hosting company would give you trouble with them too.

  • Hi Tom & Kevin,  I can't help agreeing that things could be better and that some rethinking about how elgg works would be beneficial.  There are lots of slick ideas and best practice out there; elgg and its community should be striving to utilise this and push it forwards.

    Better and more comprehensive guides/manuals (the forum is a little chaotic I think)

    Unifying code design (style Guide, consistant use of code, building on previous plugin work [evolution - I see on Joomla, for example, 10 slightly diffrant plugins to do almost the same thing... a waste of resource!])

    Plugins tested for efficiency/speed by developers before release and Employing best practice (optimised code for speed and industry standards [YSlow check])

    Themes W3 validated before release - or help file re errors as a "heads up"

    New plugins can be provided with a directory of CSS tags for incorporationinto the main CSS Theme file (Tidypics provided the tags with their plugin (in docs folder0 - good practice!)

    I am sure there is more that some of the professional coders and web developers could add.  Alas, I am not a coder, php programmer, themer or anything else to do with computing, but I can see huge potential for improvement.

  • What I have liked, on Elgg, is when teams develop around a plugin.  For instance, the TidyPics plugin, the Translation Browser plugin, the Polls plugin and others.  If one guy is able to handle keeping up with the changes of Elgg versions, fixes, feature enhancements, great.  Jeroen is doing a phenominal job, for instance.  But, typically, certain plugins almost die off or get swallowed in the sea of plugin contributions.  (One of the most powerful, by ShellCode, seemed to get abandoned. Did the guy croak or what???)  I think that if an ideal plugin comes out and there is a lead developer for that, then a team should surround them, to help keep it going, rather than coming out with multiple plugins that do the same thing (re: Mark, in other words, I agree about Joomla!).  I think multiple plugins should be eliminated or at least put on [SINK] like in the Vanilla Forums, so that they get burried at the bottom and the important ones are always up at the top and easy to find.  ...I was very impressed with how WordPress is handling their plugins.  You can even get the plugin, easily, based on what version of WordPress you are using.  If Elgg could develop that, this would be amazing.

  • Hi Yakiv... I am now migrating to a Clustered Cloud Hosting solution, which seems to me to be the best solution... it works like this:

    It seperates the database from the email and the web front end servers via a load balencer so all those memory woes are in the past... but I still want a slick and efficient script!

    image

    I agree about community/co-operative development (and funding if necessary) of the essential core plugins (i.e. Groups, Calendar, Blogs, Forums etc).  As Kevin says above, it is the plugins that make elgg sing.

    image

  • @Mark.. That looks like a diag I saw once on a webhost called justhost.

    @Tom

    You can centralise your css if you want.. all you have to do is take out the css that comes with the plugin and add it to your css.php in your views/default directory. Even though the css is extended to the css that comes with the plugin, if it is not found, elgg will always go fetch it from css.php in the default. 

    And yes, you can call/initiate the start.php only when needed.. but the difference is that will be called every time the plugin is called (multiple times during the same session).. the way it is now, start.php runs once with the loading of your site.

     

    @Mark again

    Someone mentioned this host to me yesterday.. they mention that they are a Elgg hosting provider and they sound affordable.. I never tried them personally as I host with Hostgator. But if you are after a shared server, it might be worth looking into the arvixe guys.. http://arvixe.com .

    My suggestion to everyone is that before you sign up on a hosting account, don't concern yourself too much with bandwidth and disc space, more importantly, you should inquire about the hardware and its usage.. this is what happened in your case... So, it pays to ask questions about RAM and network adapters.

     

    @all

    In terms of standardising,  Elgg docs provide uniform methods of plugin building, but many plugin developers do things their way anyway.. It still works but it may leave some people confused and take longer to figure things out.

    What is needed is a Elgg Standard check on plugin release, for example: No Docs, no Release.. I did fall into that trap myself.. I only ever wrote one plugin, but even though it's a GPL, I am still required to support it.. I had to go back and write a full tutorial for a new user who did not even acknowledge they got it.. but you can tell how frustrated he was not understanding the plugin.. mind you it is the simplest code you can ever imagine.

    So, I think the best people to set the standards are the non-coders, non-programmers.. because coders and programmers wont give a hoot about the doc or manuals.. they just get into it and write what they want in it... while non-coders are the ones who need to have clear and helpful information.. so, it is them that must set those standards and ask Elgg to push plugin devs to meet those standards.

    Another 2 cents.

  • @Carlos, thanks for the 2 cents worth... always good value :)

    The Clustered cloud removes all limits of shares servers, VPS or even dedicated server and the resourced are borrowed from the cloud if required.. obviously, the more you use, the more you pay, but it is pretty reasonable compared with the other options... www.uptimehost.com for info.

    Standards are great, and set by users is super too... how do we take this forward... there needs to be some authority behind a The Design Authority.

  • @Mark

    You're welcome, and, here's an idea:

    Create a group/discussion and ask people for a wish list in plugins.. Give them a little guide so you don't end up with people wanting irrelevant things.

    Example:

    This groups is created to get feedback from Elgg users on the issues they need addressed and dealt with in plugin development. For example, if you think that all Elgg plugins should contain Docs/Manuals to help you understand, install and operate the plugin, then we need to hear from you. We would then bring this group to the Elgg team attention and ask that they follow up on your requirements and set a plugin standard to minimise the confusion and provide knowledge about coding for Elgg.

    I think this could be a start.