This website is slow

Well, last 30 minutes I observe severe pereformance issues with THIS site - it takes now minutes to save message, to perform search etc.

What is the actual reason of such behavior? I see no hundreds of ppl right here right now online, so reason is probable hosting server. Am I right? Anyways, I don't think its good idea to have elgg.org running slowly.

 

 

 

  • Thousands of concurrent users? It'll take more than apache vs nginx to serve that up with no matter software you're running.

    Some of the biggest Elgg site I know run fine on Apache (under Windows, no less..blech) and some are on nginx.  For hobbyists, it doesn't generally matter.  If you're to the point where you have to make that decision, hopefully you're also to the point where you can hire a system engineer.

    Which web server to use is almost akin to "Emacs or vi?"  For the general population, it really doesn't matter, so use which ever you're more comfortable with.  Properly configured, either server will work fine.

  • "Hobbyists?".... Ex-squeeze me! When I am wealthy I will take on hobbies, this is business!

    I am constantly concerned whether I am playing a 1.5 year fools game with this "shareware". The fact this sight runs like absolute ^%$# is NOT encouraging, yet for the "hobbyist" of course who finds it quaint.

    The computing game is about speed and elegance, simple as that!

    I have spent 1.5 years of my life mostly working on the elegance part, and still searching for the speed (which includes reliability when running Formula 1 races).

    Find something for us to hang our hats on please. I know your team is trying, but the speed of the system here reminds (I am sure) many of us that Elgg is a big dream that has yet to even lift off the ground.

    See "Kittyhawk's first flight atempt!"

    TB

     

  • Cim, I do not know if you are running any of the following, but it would be a good idea for me to put them together:

    1. Opcode cache. Elgg, like any other PHP framework, is a long series of include after include being called. You absolutely need an opcode cache.

    2. Tweak your MySQL conf and bump up the query cache values. 

    3. Run Evan's awesome Minify plugin: http://community.elgg.org/pg/plugins/project/489179/developer/ewinslow/minify

    We have been managing fine with a fair number of users doing all of this and bit more. System load is rarely over 0.3.

  • for evan's plugin minify, should i turn on or off the site's cache?

  • Keep the site cache on. All that Minify does is to remove whitespace from the CSS and JS that is finally served out to the users.

  • ok thanks, i read that php6 will be having a built-in alternative php cache (APC) in each install. it's going to be the "de-facto" standard php caching mechanism. can't wait for that.

  • @Brett    Sorry about the shareware comment. I know the difference, it's just that when the "mothership" (elgg.org) runs at such sporadic speeds, it just, well, makes the whole thing seem a little wacky sometimes. But that's part the exciting thrill...it's like an old Dodge Dart, you hit the gas and ANYTHING could happen. :)

  • Cim,

    It will be good to have APC in core. It is a pain at times to get APC to build against some of the newer PHP releases. That said, you should also try XCache and compare and go with the one that milks the best performance for Elgg.

    Another thing, change page_elements/header.php to pull the JQuery and and JQueryUI files from one of the CDNs (Google, MSFT etc).

     

    http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js
    http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js

    This should save you a lot on bandwdith and get better response times. But do make sure that when you do an Elgg upgrade to see the versions being used in the release are the same ones that are being linked to.