Since upgrading to 1.3, I’ve noticed an increase in the time it takes to load the control panel.  Normally it’s just a couple seconds, but I’ve seen in increase in timeouts when either loading the control panel or updating posts.  When this happens, I’m unable to open any control panel page/tab/function while the rest of the site runs just fine (this includes searches).  I usually have to close any and all browser windows and wait a few moments before making another attempt.

The only deviation from the install settings is that we’ve turned off Page Throttling (because as I’ve stated previously we control spide/bot activity on a server level), but when watching the server load/cpu load numbers I’m seeing much higher spikes than we previously encountered while MySQL and open httpd connections shows no noticable spike.

Is this common (ie, is EE now more process intensive with 1.3) or is there some setting I need to adjust?  As stated previously, this problem is localized with the Control Panel and related pages, not the main site itself, so I’m unsure how to proceed.  I’ve already done a repair/optimize via the Admin functions.

Thanks.

One of the first things to check with this kind of thing is to go to Admin -> General Configuration and turn “New Version Auto Check” to off.

Does that function get hit when I’m submitting or updating a post?

Edit: That did seem to alleviate some of the wait time while loading CP.  I’ll have to keep checking to see if the timeouts continue. 

Thanks.

No, the wait when submitting a post is usually due to one of your ping servers being slow.  Try unchecking all of them and seeing if the submit is faster.

The other item that may cause this is EE trying, unsuccessfully, to clear the cache.  So if unchecking ping servers doesn’t help, try checking the permissions on your cache files.  You could also try clearing them via the CP or via FTP to see if that helps.

I’m still seeing timeouts/lockouts when working in the publsh page.  Everything that is posted is a future entry, so pings are not the issue (as nothing is being ping’d).

As far as I can tell, this is the scenario that causes the timeout/lock:  When editing a post that has previously been saved as a draft, when I change the status to open and hit ‘update’ I’m getting locked out 7 times out of 10.  In every case I’ve added an image to the post as well, but I don’t know if that’s part of the problem or just coincidental. 

If I hit ‘quick save’ after inserting the image, changing the date, etc.  It works fine, and (if I’ve done quick save) hitting update will work as intended. 
I know that the short term fix is to use the ‘quick save’ function, but I don’t relish having to add extra steps after every change made to any given post.

Edit: When I say “timeout/lockout” what happens is that the update button is clicked, but kmy browser doesn’t show any activity (ie no loading message, etc), nor can I navigate out of that page within EE (meaning that I can still go to other sites).  I have to close out the browser completely and re-open the control panel.  When I return to the Edit queue, my changes have not been saved.

alphamonkey,

I have seen this too since the upgrade.  I’ve just been too busy lately to worry about it much.  Like you I’m not pinging anything.  I also noticed that it goes away for a period sometimes and then reappears.  I’m not usually adding images so I don’t think that has anything to do with it. 

I think it actually might have something to with the Cache.  I’m using caching quite a bit and when you change an entry it will have to clear out portions of the cache. 

What I really want to know is if it is my server that is causing the problem or if it is some inefficiency in the EE code that deals with caches.  If it is caching that is causing the pause in the first place.

Jamie

I know that on my end it’s not the server, as I can watch the CPU / Server /httpd load when it occurs.  There is no noticable spike in these instances.

Yeah, I ran top a few times during a pause and didn’t notice any spike in httpd but I seem to remember seeing something that was related to php taking up some serious processor time.

It was a few weeks ago though.  I’ll have to do it again a few times and see if I notice anything.

Jamie

Has there been any investigation into this issue?  I’m starting to get e-mails from my contributors saying they’re having the same problems.  It’s happening with enough frequency that it’s more than a minor inconvienence (especially since all edits and changes are lost when this occurs)

Changes aren’t saved when it occurs for you?  That is weird.  My chagnes are always still saved I just have to wait fora minute or so before I can used the CP again.  I ran top a few times last night during a pause and there was absolutely nothing on top to indicate why the long pause was occurring.  httpd was only taking 1% of processor time and it was the only thing top saw using more than 0% besides top itself.

Jamie

As Lisa mentioned, the two most common things that would cause a “slow” Control Panel when submitting or editing entries are:

1. Sending pings.  If the site you’re sending the ping to is unresponsive then there can be a delay as EE waits for a response before giving up.  Make absolutely sure as to whether or not you’re trying to send pings when you submit.

2. Clearing caches.  If you have EE set to clear your caches upon entry submission (which is the default setting) then EE tries to clear out/delete all your cache content whenever you submit or edit an entry.  If EE is unable to delete the content for some reason (permissions or ownership, typically) then that can cause delays as EE tries and fails to delete the content.  So, you could go look inside the immediate subdirectories of system/cache/ and make sure that the cache content is successfully removed when you do post/edit an entry.

Aside from that, I could suggest that you download a fresh copy of EE and then replace the following directories on your server:

system/core/
system/cp/
system/db/

That should make sure you have the latest code for running the CP.

You should also be able to look at server logs or other diagnostic information and see if it sheds light on what’s causing the “slow down”.

This particular install of EE was done on Sunday evening, with a copy of EE that was downloaded that day.  I’m assuming there hasn’t been a change since then?

These are entries set for future dates, so no pings are being sent.

The permissions for the cache directories are set as per EE’s instructions, and it looks as if the cache is being sucessfully cleared with each new entry.

From the server side, mySQL isn’t spiking, nor is CPU load.  WHen the submit/update button is pressed, it opens a httpd connection, but beyond that it just hangs.

No further thoughts, eh?  The issue is still ongoing, and now everyone of my contributors has sent in a report concerning the same.

alphamonkey -  If you could send me an email containing information for logging into your site as a Superadmin and FTP access for your server I will see if I can duplicate the problem and determine where it might be occurring.