Why is Revoloution so slow?

Can anyone explain to me why the backend of Revolution is so slow?

Is their a sticky or something on it?

I know there have been a lot of complaints about its poor performance both here and on the web, so I'm wondering if there's anything that can be done to make it faster, or if there is anything planned to make it faster.

Even on a fresh install with no content it takes forever to navigate around the backend and load resources.

I read here

http://anselm-hannemann.com/blog/2012/03/20/why-i-really-learned-to-hate-extjs/

that it's because Revo uses extJS.

Is that really the issue?

Quote from: markg at Apr 18, 2012, 06:38 PM

Can anyone explain to me why the backend of Revolution is so slow?

I think it's because it is much more complex, EXTJS is heavy and there are lots of ajax calls. Every time you refresh/save a page it has to reload the tree menu again, and if you have a 5/6 levels deep menu, it becomes quite annoying. The issue with speed is particularly visible when you install it on a shared hosting. I have read of some people that didn't notice any problem with it, but in my shared hosting it was impossible to use Revolution, every refresh took between 6/10 sec on the Back End and between 6/20 sec in the Front End (uncached). I can feel that is heavy even if I run it on localhost, I don't think it is a problem of a poor shared hosting.

I think they are considering to make a lighter manager, but I don't know how much time it will take.

I agree pretty much with everything it was said on Anselm blog post.

I recommend the latest version of Chrome for any work in the MODx Manager. I find it performs fairly well but more performance would be nice.

Yes, it takes soo much more time to build AND fill simple/normal websites into Rev as into Evo.
It's one of the biggest reason to stick with Evo when possible.

It's very frustrating.

What I find surprising is that a company like Dell would use Modx if it was this slow

http://modx.com/why-modx/applications/versioning-enterprise-search/

Surely Dell wouldn't tolerate such slow performance?

I strongly suspect they tweaked it to make it fast.

I gotta say - Revolution is only slow in some environments, not for everyone and I've not personally had issues with speed both in the manager and on the front end.

I would assume Dell are running this install on a high end dedicated server, however I have one client running a complex site with a booking engine containing many uncached snippets and it is very snappy - running on shared hosting with 1and1.

I have a low end VPS1 with Site5 hosting a couple of heavily dynamic sites totalling around 2-4,000 hits per day. Average front end page load is less than 1 second.

One of those sites requires spending a lot of time managing custom content via CMPs which I do locally using MAMP before uploading changes to the server. The Revo manager allows me to do this twice as fast as I ever could with the Evo version of the same site, saving me two whole days every month. Context menus, editing windows, autosave from grids, keyboard shortcuts, drag and drop... saves heaps of time.

I use Chrome for best performance when working in the manager and recommend it to my clients.

So it's certainly not slow for everybody, but I would agree that it's not the right tool if you are planning to run it on a weak shared server.

Rather than complaining, how about everyone with speed issues posts their hosting specs (and provider) in this thread so we can get some idea of what works and what doesn't? [ed. note: okyanet last edited this post 14 years, 5 months ago.]

Lucas,

I wasn't complaining, I was asking for some explanation or clarification on the issue, that's why I asked if there was a sticky or any advice on how to make it perform better.

Certainly there's been enough talk about slowness, so I do feel that the performance aspect needs to be addressed in a more formal way, if only just to clear the air.

I half agree with your last point, but rather than everyone telling us what environments don't work, I think it would be more useful if people posted what does work and from that we could develop some sort of best practice or recommended setup and environment guide.

I can say from our experience with people reporting, that people who run on low-cost or free shared hosting will experience slowness due to those servers having one of the following:

* being overpopulated with other shared accounts and not able to handle processing
* having suhosin improperly setup (which is documented in RTFM)
* having too strict open_basedir restrictions for most apps
* having improperly setup symlinks on the server
* running on buggy mysql versions (such as 5.0.51a)
* running on buggy PHP versions (5.1.6/5.2.0, or really anything pre-5.2.6 these days is a bad idea)

And etc. On the mgr side, running the manager in IE is going to be slower, because IE is a slow browser. Also, running the mgr in Firefox with a lot of extensions will be slower, because Firefox slows down with lots of extensions. We recommend a vanilla Chrome install for optimal usage, but Firefox and Safari work fine as well.

Also, if you have to disable the "compress_css" and "compress_js" settings in the manager, your manager will run slower. You should only have to disable these if you have an improperly setup or too restrictive environment that is causing issues with minify. [ed. note: splittingred last edited this post 14 years, 5 months ago.]

Thanks Shaun,

what about locally?

At the moment I'm still trialling it on a local wamp setup using Apache 2.2.11, php 5.3 and mysql 5.1.36, and it is markedly slower than my Evo installations

As for the live environment, I have a pretty reputable host, so it's at least reassuring to know a live version should be faster.

I think I may have an issue because of my PHP version then, I have one which is before 5.2.6. I'll consider another hosting company in the future, Site5 seems good.