Erm right then... 314 database queries on the dashboard!
First off this may sound slightly confrontational however it's not. I'm just shocked that's all.
Does anyone from Elgg care to discuss why the dashboard is using above 340 database queries for one page! Seriously. 340. How can this be feasable for any site to have this many database queries on 1 page? This isn't even including the ajax loaded widgets. Each of those has about 210 or more! I did a tally and the total number of queries just to get the dashboard to load is 1364!!!!!!!!!! And thats only with 5 widgets. Get a sudden unexpected surge in traffic and you are doomed. Get dugg and whoops there goes the server.
Hey I like the metadata based approach to the database design, it's seriously adaptable. But seriously how can you write a page that requires so many queries? Is it a matter of how the data is being pulled from the database? I was expecting a high number but come on, there must be some way of reducing this. For example, pull ALL the config info out of the database and keep it in php files.
This may sound harsh but there is no way I can launch a live site with Elgg if this is the state of affairs. And I was so looking forward to it too.
Actually I'm not going to through in the towel just yet but Elgg requires some serious hacking.
Hi folks,
This is our #1 development priority, and to answer Tom's points, we have extensive experience in maintaining scalable web applications (four years on Elgg, plus many years running popular applications prior to that). Elgg 0.9x runs extremely swiftly, and those lessons have been taken on board for Elgg 1.x. That said, we are aware that performance isn't where it needs to be.
We've made some serious database enhancements for the 1.1 release, and have further major enhancements in progress. (If you're watching svn, you'll see some schema enhancements etc start to creep in.) The techniques that Oliver has provided are, I believe, a good step down the right road. We're experimenting with variations on these approaches, which will mean a drastic reduction in database queries.
We're delighted with the positive approach the community has taken, providing examples of code and solutions. This is where open source really works. I'll keep you up to date with what we're doing, and in the meantime will engage in discussion about how to make Elgg the most efficient it can be.
Thanks for taking the time to reply Ben. It's good to know that this is your number 1 priority. If I come up with any more optimisations do you want me to post hacks as I have done before or put them somewhere else.
Also, have you considered making the compactor plugin part of the core plugins? With it's caching functionality it does speed up Elgg sites quite considerably.
It'd be good to talk a little about what compactor is doing - it's possible it would be more efficient to look at how these techniques could be integrated right into core rather than as a plugin. There may also be other techniques that are more efficient when looked at in this way.
Feel free to keep posting hacks; I think, though, it'd be good to talk about the underlying technical goings-on in the forum and open it up to discussion.
@Ben The compactor does several things, mostly it just applies YSlow's recommendations to any outputted content. There is only one aspect of the compactor that could benefit from absorbtion into the core and that is the file caching. Because the cache files are checked on the system init event, there is still a lot of processes that go on before it that don't really need to happen. It caches css, javascript and dynamic images (gif, jpeg and pngs). Each cached item means it doesn't have to be regenerated freeing up a lot of resources. At the moment because each file is cached based on "md5($_SERVER['PHP_SELF'].$_SERVER['QUERY_STRING'])" the caching is permanent until the cache directory is cleared (automatically in hourly, weekly, monthly intervals etc) and I still have to hook into the avatar update event to regenerate the avatars when they are updated.
Apart from the caching functionality as mentioned nothing else would really benefit from absorption into the core code, but due to the speed increases seen from it I think it should be one of the default plugins. It doesn't just free up server resources with the caching but also speeds up delivery of the page to the browser with it's white space stripping and defalting (gzip) methods. It also searches for any external js sources and then collects them all into one resource so instead of loading 3-4 js files it loads 1. If the js file can't be combined with others (ie if it is server dynamically through php) it leaves it alone, but the output of the dynamic js is still compacted, deflated and cached all the same. The same method is applied with css.
It can also perform other functions such as moving all the discovered css to just below the opening <head> tag and the js to just above the closing </body> tag for optimisation purposes, but they are rather superfluous and I coded them just for shits and giggles.
The basic results of the whole plugin shrink the required output of one Elgg page load from 300kb to 44kb, then with the etag and last-modified headers a page can load in as little as 2kb. Vastly speeding up the delivery, saving 298kb in bandwidth (saving an estimated 1.5GB per day based on 5 (max) page loads per second over 24 hours).
So as you can see, it may well be worth it.
Even if not you really should include the htaccess additions supplied with compactor
fyi, performance via Firebug's Net panel
obviously, ignore the 2mb swf header, it's just a placeholder design.
Hi Oliver, there is bug i just found at the Compactor plugin.
when i check the
Compact Javascript Resources: Attempt to join any external Javascript files into one file. option to enabled, the tinymce plugin will not work properly,for instance at the blog edit post part,anyway you do an excellent work,thanks for sharing:)
What is the status with Compactor? Still useful/workable/worthwhile with Elgg 1.2?
Has this been fixed in 1.5? I hope!
- Previous
- 1
- 2
- 3
- Next
You must log in to post replies.