Anyone else having speed/performance issues with manager - Revo-beta3?

I’ve been developing locally and have been somewhat frustrated with the slow performance of the MODx manager. Where I would expect very snappy speed because of a fast computer and the near lack of network latency, the manager is painfully slow (lots of AJAX calls, sometimes followed by full page refreshes). This has also made me wonder how it would perform once my project was pushed to a remote server. I got my answer today when I migrated to a remote server and found that the manger is almost unusable.

Since I didn’t find any other posts about this on the forum or in the Beta4 priorities, and the only seemingly related JIRA ticket I could find (http://svn.modxcms.com/jira/browse/MODX-132) was closed over a year ago, I’m wondering if something is peculiar about my setup.

My local setup:

Browser: FF/3.0.11, with Firebug disabled
OS: Mac OSX 10.5.8
PHP: 5.2.9
MySQL: 5.0.51a
Apache: 2.2.11
RAM: 4GB
PHP RAM: 1GB (don’t ask why, it’s a dev box)

My remote setup:

Browser: FF/3.0.11, with Firebug disabled
OS: CentOS 5.2
PHP: 5.2.6
MySQL: 5.0.45
Apache: 2.2.3
PHP RAM: 128MB

So, anyone else seeing these speed problems? Is manager performance a known issue?

Thanks

EDIT: I’ll also note that often while waiting for a manager page to load, I notice that CPU usage on both my CPUs (core2 duo, 2.2GHz) is pegged at 100%.

Hmm, your using a quite old Firefox here, ’Browser: FF/3.0.11, with Firebug disabled’, also I believe having firebug disabled doesn’t turn it off as such, its better to remove it completely. Your using PHP 5.2.6 on Centos, which is better than the stock 5.1.6 so this would seem Ok. Try and access the manager from the latest FF(3.5.3) remotely or even Chrome say and see how that feels. Personally I locally install FF on Centos so I can use the latest version, memory footprint wise its far better than the 3.0.xx ones.

Quote from: stephenrs at Oct 21, 2009, 01:47 PM

My local setup:

Browser: FF/3.0.11, with Firebug disabled
OS: Mac OSX 10.5.8
PHP: 5.2.9
MySQL: 5.0.51a
Apache: 2.2.11
RAM: 4GB
PHP RAM: 1GB (don’t ask why, it’s a dev box)

From: http://svn.modxcms.com/docs/display/revolution/Server+Requirements

MySQL 5.0.51 goes nuts with PDO and other things; it’s a buggy release, and isn’t supported in MODx Revolution.

My remote setup:
Browser: FF/3.0.11, with Firebug disabled
OS: CentOS 5.2
PHP: 5.2.6
MySQL: 5.0.45
Apache: 2.2.3
PHP RAM: 128MB

Completely remove Firebug, then get back to us. Firebug disabled can still hog memory.

Also, locally, after you upgrade MySQL, try the manager on Safari and see if it is as slow.

EDIT: I’ll also note that often while waiting for a manager page to load, I notice that CPU usage on both my CPUs (core2 duo, 2.2GHz) is pegged at 100%.

This makes me think that you have a server configuration problem. I’m guessing locally it’s because of 5.0.51a.

Quote from: shamblett at Oct 21, 2009, 02:27 PM

Hmm, your using a quite old Firefox here, ’Browser: FF/3.0.11, with Firebug disabled’, also I believe having firebug disabled doesn’t turn it off as such, its better to remove it completely. Your using PHP 5.2.6 on Centos, which is better than the stock 5.1.6 so this would seem Ok. Try and access the manager from the latest FF(3.5.3) remotely or even Chrome say and see how that feels. Personally I locally install FF on Centos so I can use the latest version, memory footprint wise its far better than the 3.0.xx ones.

I usually like to lag a little on browser updates to give add-on devs a chance to catch up and fix bugs (lest I unwittingly become an alpha/beta tester of tools that I rely on daily), but in this case you’re right - I’ve gotten a little out of the game. I’ll upgrade and report back. Thanks for the nudge.

But since firebug is an important part of my routine, I won’t be removing it. I might do so as a test to provide info back to the community, but getting rid of firebug is just not a viable solution for me in this case.

Quote from: stephenrs at Oct 21, 2009, 04:04 PM

I usually like to lag a little on browser updates to give add-on devs a chance to catch up and fix bugs (lest I unwittingly become an alpha/beta tester of tools that I rely on daily), but in this case you’re right - I’ve gotten a little out of the game. I’ll upgrade and report back. Thanks for the nudge.

But since firebug is an important part of my routine, I won’t be removing it. I might do so as a test to provide info back to the community, but getting rid of firebug is just not a viable solution for me in this case.

To be honest, I’m not too worried about Firebug; I think most of your issues are due to the MySQL version. Make sure, though, that Firebug isn’t doing its Net logging or script profiling that slow ajax/js down a ton.

By the way, I am very comfortable with the quick, clean and responsive UI of Evolution 1.0.0, both on local and on remote server. I am sorry to say that I find the Revolution 2.0.0-beta-3 manager UI a involution in respect of Evolution’s one.

Maybe it’s Ext that’s too heavy, or it has not used in the right way... I don’t know: but what I know is that Evolution’s manager is a breeze to use, while I cannot write the same for Revo’s one (and I hoped to say not "the same", but better).
I read that in beta-4 you’ve removed the accordion effect, good move; but many more efforts will be necessary to reach the level of the Evolution 1.0.0 manager UI with Carbon theme.

Unfortunately, for both me and my collegue the manager UI has a key role, so we’ve decided to stick with the good Evolution until Revolution gains the manager UI it deserves.

Quote from: insert_nick at Oct 21, 2009, 04:47 PM

Maybe it’s Ext that’s too heavy, or it has not used in the right way... I don’t know: but what I know is that Evolution’s manager is a breeze to use, while I cannot write the same for Revo’s one (and I hoped to say not "the same", but better).
I read that in beta-4 you’ve removed the accordion effect, good move; but many more efforts will be necessary to reach the level of the Evolution 1.0.0 manager UI with Carbon theme.

Like what? What don’t you like? Have you used it extensively in conjunction with Evolution, in a real-world environment? Can you, in Evolution:

1. Add custom system settings to be used anywhere?
2. Drag and drop documents in your tree to sort them and structure them as you like?
3. Quick edit a resource without reloading the page?
4. Add custom top menu pages that hook directly into 3rd party components?
5. Rearrange that top menu to your heart’s desire?
6. Rename or hide any field or tab (without using MgrMgr)?
7. Install Extras straight from the manager - no manual copy+paste or download/upload needed?
8. Have subnested categories?
9. Have custom properties and property sets for your Elements?
10. Do a complete ABAC security system with permission ACLs?
11. Comprehensively manage every single language string for the core (and every installed Extra) straight from the manager?
12. Manage an infinite number of subdomains or subsites (through Contexts) from one single manager?
13. Drag and drop Elements and Resources straight into the Content Pane?

and more?

Unfortunately, for both me and my collegue the manager UI has a key role, so we’ve decided to stick with the good Evolution until Revolution gains the manager UI it deserves.

That’s fine - and why we’re keeping Evolution around - but you have yet to show exactly *why* the current manager UI is not up-to-par.

We are totally okay here with constructive criticism - just ask the tons of other users here who’ve helped make Revolution where it’s at now - but simply saying something "isn’t up to par" or good enough without stating objective, concrete reasons is not appreciated. We’ve worked countless hours, days and weeks on this free product to give the community what it has been craving - and getting criticism that says the new manager is "not up to par" without saying why is a bit insulting.

I don’t mean to rant, but I don’t think that vague, unsubstantiated criticism helps. If you have reasons, I’m all ears to hear them. Otherwise, please, it’s a free product.

Quote from: splittingred at Oct 21, 2009, 04:35 PM

To be honest, I’m not too worried about Firebug; I think most of your issues are due to the MySQL version. Make sure, though, that Firebug isn’t doing its Net logging or script profiling that slow ajax/js down a ton.

I remembered reading about the (join?) problems with 5.0.51a some time ago, but hoped it wouldn’t bite me before I got off of that version. Unfortunately, I’ve got other pressing things happening at the moment that puts upgrading MySQL in the short term very low on my list of completable tasks.

I can report this though: Using the manager on my remote sever (with 5.0.45), from Safari is still unbearably slow. For example, loading the System->Settings page takes 30+ seconds. Granted, the remote server is a shared one and not the speediest, but the Safari-->remote combination would seem to eliminate the Firebug/MySQL/Firefox theories as potential causes.

From what I can see (when Firebug is enabled), loading many of the manager pages causes a nontrivial number of POST requests to be generated, which is going to cause problems in any networked environment. Also, combined with just watching how the pages load, it’s possible to see that maybe there’s some inefficiency going on, and it just feels sluggish compared to other similar UI’s (which may be partially fueling my remarks in other threads about not wanting to use it to manage code). It feels like the overuse of AJAX has caused more problems than it has solved, and maybe all the data that needs to populate the interface could be fetched in a much better way. My 2c.

I’m open to any other theories or suggestions, however.

Even if i have to agree with you on the speed of Evolution, i really think that the UI of Revolution is quick enough (and i use both with and without firebug).

The only things that bother me so far are:

- UI refinement who does reflect the quality of MODx Revolution. There are some little UI "mistake" here and there, and sometimes the html markup seems complicated for what it does. I know that’s due to lack of contribution/proposition, times available in a day and the way ExtJS play with a lot of divities and imbricated table for all and nothing.

- Sometimes in the manager, i’ve noticed in firebug, that some Ajax calls are being launched 2 or 3 times at page load (i checked the json response, and it was for the same component). But i thought it was either a beta issue or a firebug issue.

- At last, some operations requires a lot of click when it could have been more simple and user friendly to limit interaction with the mouse or automatize some actions.

ExtJS is a good move for the back end, very powerful.

The manager need to be polished, but i really think that the solution will come from the communauty, i do like the fact that the dev concentrate on the CMS itself. At the moment, what i’ve seen and play with is really really good!

I think part of the problem is that the new Evolution Manager is so fast and Firebug, when disabled, doesn’t seem to slow it down at all. Revo is definitely sluggish by comparison, at least with Firebug installed. IE7 still isn’t supported in Revo so FF is all I have (I’ll switch to Chrome when it supports Roboform -- it’s in alpha now so it shouldn’t be too long).

The Revo Manager is so much more powerful and efficient in terms of both workflow and capability, however, that I much prefer it to Evo’s, even with the slower response times.

People bothered by the speed might consider blanking out these two System Settings for now. That speeded things up for me:

MODx News Feed URL
MODx Security Notices Feed URL

PC users who don’t use Roboform should definitely try Chrome in the Revo Manager.