Most of the time, this is not an issue — I’ve never been able to duplicate the situation on any of my test setups, which are all fairly basic, standard server configurations.
My primary guess would be that this somehow relates to your server’s ability to communicate with external servers. Are you using a URL shortening service, as well? If so, you could see what happens if you disable that. If it’s a fundamental communication problem, you should get a performance improvement if you remove one of the external transfers from the process.
I did notice that Yoast seems to exacerbate the problem, so that may be a clue. Your advice sounds good for shedding some light on what mechanism may be involved.
My set-up uses the JobRoller custom post, which publishes the content in a slightly atypical manner. After the final approval screen, it gives you a confirmation/receipt page. It is during this screen that the Apache processes start flooding the top read-out, and physical memory is quickly consumed. Lingering on this page, I’ve watched the CPU load go as high as the 80’s! However, if I quickly hit “OK” on this page, WordPress returns to the user’s dashboard, and the spawning of Apache processes still spike up, but are limited to maybe a half dozen, and the CPU load tops out at about 4-8 then falls back to normal levels.
The installation is also a Network install, so another layer of complexity in tracking it down. I’ll try your suggestions, and see if the apache processes runaway on standard wordpress posts in that site, and others on the network.
I don’t know what’s going on in the background with that JobRoller posting method, but I can imagine some kind of odd situation where it continuously runs an autosave in the background, which would be caught by WP to Twitter. WP to Twitter ignores autosaves, but if it’s running constantly, it could cause some weirdness. Do let me know – you’re definitely in an uncommon situation there, but I’d appreciate any information you find out.
Your plug-in is tight. With closer analysis I realized the issue was related to W3 Total Cache running on the network installation. I haven’t had time to track down which of the different systems in that plugin is causing the issues, but as soon as I disabled it your plugin was tweeting with blazing speed. Thanks and high praise for the great plugin!
Glad to hear it! Thanks for following up.
