Do you ping extra update services? (Besides pingomatic, that is.)
There seems to be an issue with that in 2.7. In my case, once I removed everything except pingomatic, the time to save a post dropped to a few seconds.
its the additional ping services, try to remove it, and update us about what happened
Thread Starter
branch
(@branch)
No, it’s not additional ping services. I never use anything but the pingomatic that comes already set. I’d think it would be very strange if that affected the time it takes to save a new setting, in any case. It’s everything that’s slow, not just posting–saving, uploading, everything.
i actually find 2.7 to be a little slow as well.
I’m using one custom field, and 9 plugins, and Ive removed all the feed stuff from the dashboard.
I’m inclined to think its just the result of bloat.
I’ve done some tests on the load-times for the admin UI, and TinyMCE is a major culprit on my install. I think I’m going to shut off all of the TinyMCE plug-ins. They are taking a hell of a long time to load, and are mostly unnecessary.
Thread Starter
branch
(@branch)
It isn’t the loading slowness I’m worried about. I saw the ticket for that, but my page loading slowness, while it doesn’t thrill me, isn’t the problem I’m talking about.
It’s writing information of any kind, and it’s taking at least half a minute every time, for every such action. I’m not exaggerating this, I clocked it to make sure; and thirty seconds of staring at my “things processing” cursor spin after I hit ‘save settings’ or ‘post’ or ‘upload’ is a really, really long time.
@branch: If you open a second browser tab, and try to access the post that you are saving in the first tab, are the changes registered before that 30 second period?
Same goes for a set of saved settings, etc.
I am curious if the issue is the database access, or something very slow in returning the request to your browser.
(And I put together a quick plug-in to modify the TinyMCE init, dropping all languages other than English, and all unnecessary TinyMCE plug-ins, including the spellchecker. It had a very positive effect on my overall load time for the UI.)
I am curious if the issue is the database access
its not db access, I can tell you that much.
@whooami: Humor me, and drop in this plug-in. Let me know if you find any increase in the UI response for post/page editing. It will make no permanent changes anywhere:
<?php
/* Plugin Name: TinyMCE - Stripped
Plugin URI: http://www.wearefamiliar.com/
Description: Strip plugins (including image editing, spellchecker, fullscreen) from TinyMCE.
Version: 1.0
Author: Familiar
Author URI: http://www.wearefamiliar.com/
Tags: wordpress tinymce
*/
add_filter('tiny_mce_before_init', 'familiar_tiny_mce_before_init', 0);
/* We'll use this filter to strip unnecessary plugins */
function familiar_tiny_mce_before_init($initarray) {
$initarray['plugins'] = 'safari,inlinepopups,autosave,wordpress';
$initarray['spellchecker_languages'] = '';
return $initarray;
}
?>
Thread Starter
branch
(@branch)
@familiar
Okay, I tried that on a Settings page. The changes did not show up in the second window until the first window (in which I had clicked save) finished processing/loading. I reloaded four times, over the course of the first window’s delay, and none of those page loads (which were of reasonable speed) showed the new setting until the first window was done.
I have no idea how diagnostic this is, but my browser’s “what I’m doing” message, for the first window, was “waiting for domainname.org…”.
done, and Ill be honest and say I dont see a difference.
I’ll still use though, since i dont, and never will use tinymce
getting rid of it cant hurt.
@ Whooami: In that case, change the line that reads
$initarray['plugins'] = 'safari,inlinepopups,autosave,wordpress';
to
$initarray['plugins'] = 'wordpress';
That will keep it from misbehaving, but it’ll lose most extra functionality.
The difference on a fast connection will likely be less than a second (lucky you). But my connection here is hellishly slow, so (with Firebug) I can see exactly what is causing it to choke, and the TinyMCE plug-ins are at half a second each on load-time for me. I might clean this up, make it configurable and drop it into the plug-in database for people who want granular control over their TinyMCE install.
@branch: Ugh. OK. In that case (whooami is probably right it not being the database) it’s not even sending the request for some time. Your browser is just sitting there. WP runs a few processes (both local and server-side) before the submit actually happens. Have you tried alternate browsers?
Thread Starter
branch
(@branch)
@familiar: Yes, I’ve tried this in Camino (Gecko kernal browser for Mac) and Safari, and both of them have the delay.
*frowns* Now I think about it, you know, I don’t think this was happening when I was using the 2.7 pre-beta nightly builds. I remember doing a lot of comment-threading testing with the later versions, again in both browsers, and I don’t remember this huge delay.
It could be a very slow response from wp-ajax.php. That’s what it sounds like, but it’s tough to say for sure.
Thread Starter
branch
(@branch)
This is still a problem, but it has gotten a little less so with RC1. Updating/posting/etc. now seems to take about 15-20 seconds.
Whatever is being done… um… do more of it?
