MODx Revolution Extremely Slow

My main site was is built in the latest version and has around 1000 pages, 50 or so tv’s and numerous chunks and the manager area is pretty fast, certainly not like you are experiencing, the front end also loads frighteningly fast, much faster than it ever did in evo so I agree with Bo Allen in that I am personally surprised to hear all of this.

We’ve tried about every option we could find, and we get as far as the "This will overwrite your site", click "Yes" - then nothing happens. No messages, no error messages .. nothing.

What’s in the import log? This should tell you how far your getting, I’ve seen the import stall on large sites, this times out the backend in your local revo install and hangs the import.

Quote from: Bo at Feb 08, 2011, 05:45 PM

I’m personally surprised to hear all of this. I’m working on porting a *large* site from another CMS and I’m loving the on-demand resource loader!

The site currently has 5000+ resources (500 of which are containers), 3 templates, 42 TVs, 3 chunks, and 38 snippets.

The UI is snappy for me, and the on-demand tree loader is essential.

As for front-end execution... the caching is spectacular and proved its worth in my benchmarks vs. ExpressionEngine.

http://modxcms.com/forums/index.php/topic,57666.msg329760.html#msg329760

The site is currently on Revo 2.0.5.

Questions for those with slow MODx Revo:

• Where’s your database? Is it on localhost?
• How beefy is your server (CPU + RAM)?
• Is it a shared server? How busy is it?
• Are you running Apache with mod_php?
• How much memory are you giving PHP?

Just curious

13 templates, 10 tv’s, 39 chunks, 22 snippets, 65+ pages.

We’re doing (did) a side-by-side comparision of Revo and Evo on the same server (different accounts/domains on a dedicated server). The hardware set up for 1.0.5 is "EXACTLY" the same for Revo.

The only difference is, Revo is a dozen times slower at the Manager U.I.

Our site builds are developed collaboratively by several contributors at different times so the domains are always in the cloud. That’s never been a problem until Revolution, so for us the solution is to not use Revolution then use the manual migration method .. unless there’s other hidden surprises with that method?

For the time Revolution has been out we would have thought a system to upgrade from earlier versions would be something of an item of necessity. So to be greeted by this message nearly a year after its initial release, suggests even for the developers its a problem with no easy solution due to the additonal complexity thats been added to Modx as a run-up to commercializing it.


Automated upgrading from 0.9.6.*/Evolution is not yet available in MODx Revolution 2.0.0. A migration tool will be provided sometime after the release of MODx Revolution 2.0.0.

Have things been done to Revolution to ensure Modx can’t be forked (as easily) the same way Modx was forked from Etomite? And by doing so is the end product with no ’backup for dummies’ and ’migrations to clients servers’ where the least of ones concerns should be what parts of a CMS to move to "hopefully" get it to "hopefully" work properly on the clients server.

On an 3.2GHz Imac i3 27" with 4 x 2GB DDR3 SDRAM SO-DIMMs running Opera - Revolution probably runs as fast as everything else. But we develop on "average" machines to emulate the "average clients set-up" rather than telling clients they need to spend 10k upgrading their systems just to use a CMS.

Revolution looks like someone got carried away with a heavy spec PC which is exactly what happened with Windows Vista so it wouldn’t be the first time.

Hell, we have a hard enough time explaining to half our client’s what an IE cache is and how to clear it! Until they understand that they sit around wondering why the changes they requested never get made. Now try adding "you can’t open too many browser windows when your using Revolution otherwise Revolutions scripts will stop working" into it. They only thoughts they have is that Google works fine so everything else should, so we’re the dummies and they should have known better.

Anyway, I’ve spent too much time on this now (off to deliver some bad news) but thanks to everyone for their help and comments.

Just to chime in here, but there’s GOT to be a solution going forward. Ever since Revo came out, the manager has been very slow. I realize it’s the javascript and I also realize the new caching mechanism makes it a better solution for very large sites. That said, I’m developing on my local machine with 2.0.7-pl (brand new install, only the home page exists). It’s not beefy by any means, but it’s a 2GHz AMD64 with 3.4GB RAM running XP Pro. I’m using plain old Chrome with nothing else and I’ve disabled both feeds, per another earlier post. When I hit Login, it takes 1 min 10 sec to finally get to where everything’s loaded and I can edit the home page. In fact, every action takes about a minute.

If there’s not a way to make this fast on the local machine with decent hardware and resources, etc., then nobody is going to use it.

I’ve read some posts from others who are seeing a very fast manager UI. How can that be? Is there an Apache or PHP setting I can tweak? What can I look at to make this better?

Thanks.

Something is definitely wrong, though it’s hard to say what. I’m on Vista/XAMPP and nothing takes more than 4 seconds (and that’s FF with FireBug installed). I would expect XP to be much faster. The only things I can think of is a slow drive with no cache, a nearly full hard drive, or a very low memory_limit setting for PHP. Are any of those possibilities?

None of those. I’ve got 12gb free on the drive, memory_limit=128M. I’m going to try installing on a different machine, but I’ll still welcome any other performance enhancing suggestions.

just an idea...
How about if someone would provide a testinstall of Revo 2.0.7, which gets refreshed every hour or so, together with a short list of relevant things to do in a sequential order, while measuring the time for each item?

Then everyone could report their time, browser, OS and Hardware, so that we can see if there is any cause for these different experiences on the non server side.

Good idea, I’ll toss one up tomorrow.

Like http://www.trymodx.com/latest-revo (granted, it’s still 2.0.6...) ? That’s from the Revolution Demo submenu item on the new http://modx.com