wordpress　記事投稿が遅い

返信および、ご丁寧な回答ありがとうございます

＞topコマンドは普通にサーバーへSSHでログインすればいつでも使用できますよ。

SSHでログインとは具体的には何かソフトをインストールするのでしょうか？

＞一応確認ですが、電波状況が悪い等、といった環境的要因は無いでしょうか？

有線接続で光なので大丈夫だと思います

＞アクセスが非常に多い

日に500PV位なのでそんなに多くはないと思っております

＞同一サーバー内で他に重いプログラム、cronが動いている

自分としてはどれが重いプログラムなのか今一つ把握できておりませんが

wordpressで1ドメインのみで他には使用していません。

cronも特に設定していないので使用していないと思います

＞WordPressが推奨している以外の無茶な方法でカスタムをしている

twentyfourteenでレイアウトの調整くらいで特に無茶な設定はしていません

＞特定のプラグインを複合で使用している

身に覚えがあるのはカテゴリーを自動で割り当てるAuto　Set　Categoryが重くしてるのではないかと思っています

ただ、このプラグインは非常に重宝していました類似のプラグインがなく

どうしても使用しています

以下が記述なんですが、同じ機能で動作を軽くする記述はありますでしょうか？

<?php
/*
Plugin Name:Auto Set Category
Plugin URI:http://milkveil.com/
Description:本文中にカテゴリーと同じ文字列があった場合、そのカテゴリーをセットするプラグイン。
Version:1.0
Author:taku-k
Author URI:http://milkveil.com/
*/


function auto_set_category ( $post_id ) {
global $post;
$new_post = get_post( $post_id );
$content = $new_post->post_content;

/* ループ開始　全てのカテゴリーを１つ１つ調べる */
$cat_all = get_terms( "category", "fields=all&get=all" );
foreach($cat_all as $value):

/* もし本文にカテゴリーと同じ文字列があれば（デフォのカテゴリーを外してから）カテゴリーを付ける */
if ( stripos( $content, $value->name ) !== false ) {
wp_remove_object_terms( $post_id, 1, 'category' );
wp_add_object_terms( $post_id, $value->name, 'category' );
}
endforeach;
/* ループ終了　全てのカテゴリーを１つ１つ調べる */

/* もしカテゴリーが１つも無かったらエラーになるからデフォのカテゴリーを付ける */
$catcheck = get_the_category($post_id);
if ( is_array($catcheck) && count($catcheck) === 0 ) {
wp_add_object_terms( $post_id, 1, 'category' );
}
}
add_action( 'save_post', 'auto_set_category' );

え…？　 SSHを知らずにどうやって自宅サーバーを運用されてるのですか？
ターミナルソフトは使ってらっしゃらないのですか？

まぁ…使っていないにしてもCLI上でコマンド叩けば問題ないので
一度まず、CLI上でtopコマンドを試されることをおすすめします。

http://q.hatena.ne.jp/1128171453

manabufukai さん、再度の返信ありがとうございます

SSHの件、不勉強で申し訳ありません

現在は使用していません

＞一度まず、CLI上でtopコマンドを試されることをおすすめします。

どのようにすれば、Windows7で

topコマンドを実行できますでしょうか？

Kosuke_Shibuya さん、コメントありがとうございます

コマンドプロンプトでtasklist　/Vで表示されたのですが

これをテキスト形式でデスクトップに保存するにはどうしたらいいのでしょうか？

Kosuke_Shibuya さん、テキスト形式でデスクトップに保存できました

お騒がせしました、ありがとうございます

ああ、なるほど失礼いたしました！サーバーのOSがWindows7なのですね？
完全に勘違いしていました…

不勉強で申し訳なかったのはこちらのほうです、「WindowsをWebサーバーとして運用する」というケースをほとんど知らなかったため早とちりしてしまいました、申し訳ございません。
なので、SSHとCLIのことは忘れてください。

しかしながら、Windowsをサーバーとして利用したこともなく、Windows自体正直詳しくないので何ともですが
他の回答者さんとのやりとりを見る限り、WordPressの動作にも問題がありそうに思います。xhprofや、先述のPrime Timelineを使用して各処理を追ってみられてはいかがでしょうか？

manabufukai さん、返信ありがとうございます

tasklistでtopコマンドの表示のようなことはできましたが

正直どれがwordpressを重くしているのか不明です

以下で重くなっている原因等分かりますでしょうか？


イメージ名: System Idle Process
PID: 0
セッション名: Services
セッション#: 0
メモリ使用量: 24 K

イメージ名: System
PID: 4
セッション名: Services
セッション#: 0
メモリ使用量: 11,180 K

イメージ名: smss.exe
PID: 372
セッション名: Services
セッション#: 0
メモリ使用量: 1,224 K

イメージ名: csrss.exe
PID: 436
セッション名: Services
セッション#: 0
メモリ使用量: 9,776 K

イメージ名: csrss.exe
PID: 496
セッション名: Console
セッション#: 1
メモリ使用量: 19,588 K

イメージ名: wininit.exe
PID: 504
セッション名: Services
セッション#: 0
メモリ使用量: 5,892 K

イメージ名: winlogon.exe
PID: 552
セッション名: Console
セッション#: 1
メモリ使用量: 8,272 K

イメージ名: services.exe
PID: 600
セッション名: Services
セッション#: 0
メモリ使用量: 13,116 K

イメージ名: lsass.exe
PID: 608
セッション名: Services
セッション#: 0
メモリ使用量: 18,280 K

イメージ名: lsm.exe
PID: 616
セッション名: Services
セッション#: 0
メモリ使用量: 4,880 K

イメージ名: svchost.exe
PID: 716
セッション名: Services
セッション#: 0
メモリ使用量: 14,904 K

イメージ名: ekrn.exe
PID: 784
セッション名: Services
セッション#: 0
メモリ使用量: 186,100 K

イメージ名: nvvsvc.exe
PID: 804
セッション名: Services
セッション#: 0
メモリ使用量: 7,612 K

イメージ名: nvSCPAPISvr.exe
PID: 828
セッション名: Services
セッション#: 0
メモリ使用量: 6,328 K

イメージ名: svchost.exe
PID: 884
セッション名: Services
セッション#: 0
メモリ使用量: 13,948 K

イメージ名: MsMpEng.exe
PID: 980
セッション名: Services
セッション#: 0
メモリ使用量: 219,072 K

イメージ名: svchost.exe
PID: 396
セッション名: Services
セッション#: 0
メモリ使用量: 31,904 K

イメージ名: svchost.exe
PID: 428
セッション名: Services
セッション#: 0
メモリ使用量: 249,672 K

イメージ名: svchost.exe
PID: 416
セッション名: Services
セッション#: 0
メモリ使用量: 35,960 K

イメージ名: svchost.exe
PID: 868
セッション名: Services
セッション#: 0
メモリ使用量: 66,444 K

イメージ名: svchost.exe
PID: 1284
セッション名: Services
セッション#: 0
メモリ使用量: 12,936 K

イメージ名: TrustedInstaller.exe
PID: 1328
セッション名: Services
セッション#: 0
メモリ使用量: 54,052 K

イメージ名: svchost.exe
PID: 1608
セッション名: Services
セッション#: 0
メモリ使用量: 41,400 K

イメージ名: spoolsv.exe
PID: 1744
セッション名: Services
セッション#: 0
メモリ使用量: 11,600 K

イメージ名: svchost.exe
PID: 1784
セッション名: Services
セッション#: 0
メモリ使用量: 21,040 K

イメージ名: svchost.exe
PID: 2004
セッション名: Services
セッション#: 0
メモリ使用量: 20,932 K

イメージ名: svchost.exe
PID: 2044
セッション名: Services
セッション#: 0
メモリ使用量: 23,396 K

イメージ名: mysqld.exe
PID: 2052
セッション名: Services
セッション#: 0
メモリ使用量: 310,616 K

イメージ名: NisSrv.exe
PID: 2676
セッション名: Services
セッション#: 0
メモリ使用量: 17,592 K

イメージ名: svchost.exe
PID: 2936
セッション名: Services
セッション#: 0
メモリ使用量: 10,728 K

イメージ名: nvxdsync.exe
PID: 2432
セッション名: Console
セッション#: 1
メモリ使用量: 18,616 K

イメージ名: nvvsvc.exe
PID: 2428
セッション名: Console
セッション#: 1
メモリ使用量: 13,156 K

イメージ名: taskhost.exe
PID: 2952
セッション名: Console
セッション#: 1
メモリ使用量: 13,904 K

イメージ名: egui.exe
PID: 2604
セッション名: Console
セッション#: 1
メモリ使用量: 37,144 K

イメージ名: dwm.exe
PID: 2516
セッション名: Console
セッション#: 1
メモリ使用量: 36,960 K

イメージ名: explorer.exe
PID: 320
セッション名: Console
セッション#: 1
メモリ使用量: 118,484 K

イメージ名: GoogleCrashHandler.exe
PID: 3304
セッション名: Services
セッション#: 0
メモリ使用量: 564 K

イメージ名: msseces.exe
PID: 3344
セッション名: Console
セッション#: 1
メモリ使用量: 20,272 K

イメージ名: GoogleCrashHandler64.exe
PID: 3408
セッション名: Services
セッション#: 0
メモリ使用量: 528 K

イメージ名: GWX.exe
PID: 3428
セッション名: Console
セッション#: 1
メモリ使用量: 1,192 K

イメージ名: SearchIndexer.exe
PID: 3556
セッション名: Services
セッション#: 0
メモリ使用量: 132,616 K

イメージ名: Hidemaru.exe
PID: 3596
セッション名: Console
セッション#: 1
メモリ使用量: 7,680 K

イメージ名: wmpnetwk.exe
PID: 4072
セッション名: Services
セッション#: 0
メモリ使用量: 12,300 K

イメージ名: svchost.exe
PID: 4140
セッション名: Services
セッション#: 0
メモリ使用量: 26,468 K

イメージ名: httpd.exe
PID: 1324
セッション名: Services
セッション#: 0
メモリ使用量: 15,960 K

イメージ名: googledrivesync.exe
PID: 4812
セッション名: Console
セッション#: 1
メモリ使用量: 4,044 K

イメージ名: googledrivesync.exe
PID: 4840
セッション名: Console
セッション#: 1
メモリ使用量: 580,608 K

イメージ名: taskmgr.exe
PID: 10572
セッション名: Console
セッション#: 1
メモリ使用量: 13,860 K

イメージ名: taskhost.exe
PID: 10216
セッション名: Console
セッション#: 1
メモリ使用量: 9,628 K

イメージ名: httpd.exe
PID: 9416
セッション名: Services
セッション#: 0
メモリ使用量: 239,784 K

イメージ名: SearchProtocolHost.exe
PID: 9348
セッション名: Services
セッション#: 0
メモリ使用量: 11,864 K

イメージ名: cmd.exe
PID: 5596
セッション名: Console
セッション#: 1
メモリ使用量: 3,368 K

イメージ名: conhost.exe
PID: 10696
セッション名: Console
セッション#: 1
メモリ使用量: 10,600 K

イメージ名: SearchFilterHost.exe
PID: 6860
セッション名: Services
セッション#: 0
メモリ使用量: 8,712 K

イメージ名: tasklist.exe
PID: 10384
セッション名: Console
セッション#: 1
メモリ使用量: 6,092 K

イメージ名: WmiPrvSE.exe
PID: 9316
セッション名: Services
セッション#: 0
メモリ使用量: 6,680 K

先日も申しました通り、自分はWindows自体詳しくないので、見慣れないプロセスばかりですね…。そんな状態なので、この解析は他の方にお願いしたほうが良いです。

なので、一旦先の回答でもお伝えしたWordPress側をチェックしてみられてはいかがでしょう？
お見受けする限り、タイムラインなどの解析はちょっと難しそうなので
手法を変えてチェックしてみてはいかがでしょうか？

1.テーマは自作でしょうか？
Yes →　デフォルトテーマに変更→投稿を試す
※この段階で改善されていればテーマ側のphpに何らかの非効率な処理がある

2.一つ一つプラグインを停止しながら投稿を試していく（一つ投稿すると一つプラグインを停止）
※劇的に早くなったタイミングがあれば、その直前に止めたプラグインが原因（Auto set categoryを一度最初に停止した状態でチェックしてから、もう一度有効化し、今度はAuto set categoryを最後まで残しながら一つ一つ停止していく、という二段階を踏んだほうが良いかなと思います。）

おっしゃる通りAuto set categoryというものはどうあっても投稿保存が遅延するようなことをやっているプラグインではあります。（save_postにactionを挟んで、全カテゴリーの数だけ記事データ内を走査しながらカテゴリーの文字列と一致するものがあるか判定する＋カテゴリーを設定する）

当然カテゴリー数が増えればループの回数も増え乗算的に保存まで時間が伸びる、記事の文字数が増えればその分走査の時間も伸びる…というものです。

実際どれだけのカテゴリー数があり、記事を何文字ほど書かれるのかは存じませんので一概には言えませんが、ただ、これだけでそこまで時間がかかるものなのかな…？という気がしなくもありません。

これ以外にも絶対に問題が無いとは言い切れ無いので、そのあたりも合わせてチェックしておくほうが順当だと考えます。

返信ありがとうございます

一つ一つ調べていったら、Auto set category以外ではautoptimizeというプラグインが

原因のようでした

他のプラグインでもいくつか遅くするものがありましたが

劇的に遅くなるものではないため、我慢して使おうと思います

しかし、依然として、

wordpressで記事を執筆中

「接続が切断されました 再接続するまで保存を中断します。

念のため、お使いのブラウザー上でこの投稿をバックアップしています。」

と頻繁にでます

これはどのようにすれば解決するものなのでしょうか？

やはりPCを最新のものにするのが良いのでしょうか？

検索で以下のものが出てきたのですが

以下を導入したら変わるものなのでしょうか？

APC ( Alternative PHP Cache )

FastCGI

上記はPHPを高速化するものらしいのですが意味があるのでしょうか？

忙しかった為、返信がおそくなりました。
情報があまりにも断片的な為、正確なことが言えませんが
先の回答ではちょっと言葉足らずだったところがありますね
・プラグインをすべて止めた状態でも「接続が〜」の症状が出ますか？
・プラグインをすべて止めても出る場合、デフォルトテーマでも同じ症状が出るのか？
の2点もお答えください。

そのメッセージが出続けているということは、これまでの返信内容でおっしゃってない「管理画面内に作用するプログラム」が他にもあるはずです。

＞他のプラグインでもいくつか遅くするものがありましたが
＞劇的に遅くなるものではないため、我慢して使おうと思います

こういったものが積もり積もって症状を引き起こしているのではないでしょうか？
そういった部分を検証するためにもこの回答の最初に言った2点がどうなのかという部分を明確にしていただく必要があります。

また、個人的な意見ですが、公開サイトをするなら
PCをどうこう、というよりちゃんとしたサーバーで運用されたほうがいいと考えます。
FastCGIは入っていないなら入れておいて損はないと思いますが、どれだけ差があるかは疑問です。
Cacheは多分今回の症状に対してはあまり意味が無いと思います。

返信ありがとうございます

＞・プラグインをすべて止めた状態でも「接続が〜」の症状が出ますか？

出ません

プラグインを複数使用しているため、遅くなっているようです
現状最低限使いたいプラグインだけ使用しているので
これ以上速くするのは現状では難しそうです

やはり速度を上げたいのであればハードを買い替えるのが無難なのでしょうか？

なるほど、では管理画面側に作用するプラグインを複数使用しているということですね？
どうしてもその構成で、というのならやっぱりちゃんとしたサーバーを借りて運用すべきかな…とも思います。
無料の試用期間があるサーバーもあるので、一度そちらで同じ環境を作成してみて
同じ症状が出なければ、やはり…というところかなと…。