フォーラムへの返信

15件の返信を表示中 - 16 - 30件目 (全59件中)
  • フォーラム: 使い方全般
    返信が含まれるトピック: インストール直後からデータベースクエリが遅い
    トピック投稿者 developer

    (@6flat)

    もう一度次のSQLを実行すると実行時間が0.1135sとなり、やはり遅い結果が出ました。

    SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'

    あとはデータベースの状態を見てみると、確かに負荷が高い状態なのかもしれないと感じました。
    全く詳しくないので赤文字になっているところだけ見てそう感じただけですが…。

    Slow_queries: 3,826
    
    Innodb_buffer_pool_pages_dirty: 1,215
    Innodb_beffer_pool_reads: 19M
    Innodb_log_waits: 1
    Innodb_row_lock_time_avg: 233
    Innodb_row_lock_time_max: 26k
    Innodb_row_lock_waits: 47k
    
    Handler_read_md: 61G
    Handler_read_md_next: 7,716G
    
    Qcache_lowmen_prunes: 417M
    
    Created_tmp_files: 338M
    
    Select_full_join: 3,069k
    Select_range_check: 20k
    
    Sort_merge_passes: 2,502k
    
    Opened_tables: 4,295k
    Table_locks_waited: 71k

    フォーラム: 使い方全般
    返信が含まれるトピック: インストール直後からデータベースクエリが遅い
    トピック投稿者 developer

    (@6flat)

    wp_load_alloptions()で実行されているであろう次のSQLをphpMyAdminから実行すると実行時間は0.0015sと全く問題ありませんでした。

    SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'

    …もしかするとQuery Monitorプラグインそのものが原因なのでしょうか。
    このプラグインの追加以外には何も手を加えていないので、何だかそんな気がしてきました。

    フォーラム: 使い方全般
    返信が含まれるトピック: インストール直後からデータベースクエリが遅い
    トピック投稿者 developer

    (@6flat)

    テーブルの位置を指しているわけではないんですね…。
    もしDBサーバーの同居人が高負荷をかけているのなら、DBサーバーを変えてもらうくらいしか出来る事は無さそうですね。

    追記
    現状のまとめ

    • wp_load_alloptions()を呼び出した時のクエリ実行時間が遅い(0.1s)
    • wp_load_alloptions()はデータベースのwp_optionsテーブルにあるautoload=’yes’となっているものを全て読み込んでいる
    • この読み込みに時間がかかっている
    • 通常、この読み込みにこれほど時間が掛かる事はない

    この点を中心に調べていこうと思います。

    更に追記
    performance – Slow Query for the wp_options table – WordPress Development Stack Exchange
    WordPress wp_options table autoload micro-optimization – Sysadmins of the North
    上記リンクを参考に以下のSQLを実行してみましたが、改善されませんでした。
    ( ` を ‘ に置き換えています)
    ALTER TABLE 'wp_options' ADD INDEX ('autoload')

    フォーラム: 使い方全般
    返信が含まれるトピック: インストール直後からデータベースクエリが遅い
    トピック投稿者 developer

    (@6flat)

    gblsmさん、ご回答ありがとうございます。
    wp_load_alloptions()が他2つの関数を呼び出しているんですね…。
    何かの不具合なのではないかと思っていましたが安心しました。

    あれからデータベースの内容を一度削除してからPHPを5.4に戻してみたり、それに合わせてデータベースの文字セットをutf8mb4_general_ciからutf8_general_ciに戻してみたりしましたがクエリは遅いままです。
    そして遅い原因となっているのもやはりwp_load_alloptions()です。
    ただ、今度はtransient_feed_ab995de7a5278071ed721c721c891aedではなく、その一つ下の_transient_timeout_feed_mod_ab995de7a5278071ed721c721c891aedという行でした。

    今はさくらに一応問い合わせてみたところなので、その返答を待ちながら検索して原因を調べています。

    フォーラム: 使い方全般
    返信が含まれるトピック: 検索文字列のクエリを現在のクエリに追加
    トピック投稿者 developer

    (@6flat)

    回答ありがとうございます。
    まだ確認はしていませんが、確かにその方法であれば実現出来そうですね。
    とても良いアイデアを下さった事に心から感謝致します。

    記事に属するカスタム分類のタームを表示させたいという事で良いのでしたらwp_get_object_termsという関数を利用する事で可能です。
    リンク先のCodexにはサンプルも掲載されているので参照してみて下さい。

    フォーラム: 使い方全般
    返信が含まれるトピック: 空要素にスラッシュが挿入されない様にしたい
    トピック投稿者 developer

    (@6flat)

    連続改行についてはご指摘の通り行間調整が目的なので、その部分を見直しながら空要素が使われた時の末尾のスラッシュについてはフィルタを用いて置換する事で対応しようと思います。
    また、remove_filterについて安易な使用は避けた方が良いという事もとても勉強になりました。
    ありがとうございました。

    フォーラム: 使い方全般
    返信が含まれるトピック: 空要素にスラッシュが挿入されない様にしたい
    トピック投稿者 developer

    (@6flat)

    ありがとうございます。
    プライオリティを30まで上げたところ、コメントの方は無事反映されました。

    また、<br>が消えた件についてはこちらの勘違いでした。
    正確には連続した<br>だけが消え、一つだけの箇所はきちんと置換されていました。
    (本来は連続して<br>を使うという事をせずにCSSで対応すべきなのですが、諸事情でどうしても連続で使用する場面があるという状況です)

    尚、次の様にしたところ連続した空要素が消える様な事は無くなったのですが、問題などあれば指摘して頂けると助かります。

    // オートフォーマット関連の無効化
    add_action( 'init', function() {
        remove_filter( 'the_title',    'wpautop' );
        remove_filter( 'the_content',  'wpautop' );
        remove_filter( 'the_excerpt',  'wpautop' );
        remove_filter( 'comment_text', 'wpautop' );
        remove_filter( 'the_title',    'wptexturize' );
        remove_filter( 'the_content',  'wptexturize' );
        remove_filter( 'the_excerpt',  'wptexturize' );
        remove_filter( 'comment_text', 'wptexturize' );
        remove_filter( 'the_editor_content', 'wp_richedit_pre' );
    });
    
    // オートフォーマット関連の無効化 TinyMCE
    add_filter( 'tiny_mce_before_init', function( $init ) {
        $init['wpautop'] = false;
        $init['apply_source_formatting'] = ture;
        return $init;
    });
    
    // convert_charsで変換されたタグを置換
    add_filter( 'the_title',    'my_html4_break', 11 );
    add_filter( 'the_content',  'my_html4_break', 11 );
    add_filter( 'comment_text', 'my_html4_break', 30 );
    function my_html4_break( $return_value ) {
    	return preg_replace( '!(<br)[^/]+/>!', '<br>', $return_value );
    }
    フォーラム: 使い方全般
    返信が含まれるトピック: 空要素にスラッシュが挿入されない様にしたい
    トピック投稿者 developer

    (@6flat)

    回答ありがとうございます。

    // convert_charsで変換されたタグを置換
    add_filter( 'the_title',    'my_html4_break', 11 );
    add_filter( 'the_content',  'my_html4_break', 11 );
    add_filter( 'the_excerpt',  'my_html4_break', 11 );
    add_filter( 'comment_text', 'my_html4_break', 11 );
    function my_html4_break( $return_value ) {
    	return preg_replace( '!(<br)[^/]+/>!', '<br>', $return_value );
    }

    上記の様に試してみたところ、br要素が全て消え、改行した箇所が全てp要素で囲まれる様になってしまいました。
    また、remove_filterによるオートフォーマットの無効化と合わせて使用したところ、br要素は消えなくなりましたが置換が効いていないようです。

    トピック投稿者 developer

    (@6flat)

    自動保存やリビジョンを無効にした環境では新規投稿時にget_the_categoryでカテゴリー情報を取ろうとしても取れないので、投稿を公開する前に一度下書き保存をするという場当たり的な対応でとりあえずカテゴリースラッグを入れる事は出来ました。

    ただ、公開後に投稿のパーマリンクの編集から投稿スラッグを空にするなどした時にはカテゴリースラッグが何故か入らず{post_type}-{post_ID}となってしまいました。
    しかし、そのまま更新すると更新後にカテゴリースラッグがちゃんと入っていて、そこだけ何だかよく分からないままです。

    意図した通りの結果ではありませんが、とりあえず解決とします。

    function auto_post_slug( $slug, $post_ID, $post_status, $post_type ) {
        function cat_slugs() {
            foreach ( get_the_category() as $get_slug ) {
                $output[] = $get_slug -> slug . '-';
            }
            unset( $get_slug );
            if ( is_array( $output ) ) {
                $cat_slugs = implode( '', $output );
            }
            return $cat_slugs;
        }
        if ( preg_match( '/(%[0-9a-f]{2})+/', $slug ) && $post_type == 'post' ) {
            $slug = cat_slugs() . utf8_uri_encode( $post_type ) . '-' . $post_ID;
        }
        return $slug;
    }
    add_filter('wp_unique_post_slug', 'auto_post_slug', 10, 4 );

    トピック投稿者 developer

    (@6flat)

    疑問に答えて下さりありがとうございます。
    もしかしたらと思ったのですが、出来ないのですね…。
    やはり地道な方法で取得していこうと思います。

    フォーラム: 使い方全般
    返信が含まれるトピック: 日替わりで投稿をランダムに表示
    トピック投稿者 developer

    (@6flat)

    ありがとうございます。

    UTC基準の日付と比較してるから起こるんじゃ…(mktimeはwpでは他のdate系関数同様UTC)

    タイムゾーンがUTCのmktimeと、タイムゾーンを東京に設定したdate_i18n(またはtime() + 32400)では日付変更のタイミングがそれぞれ異なるからずれが生じるという事なのですね…。
    これに関してはデフォルトのタイムゾーンを変更する事で解決できました。

    // get default time zone
    $default_timezone = date_default_timezone_get();
    
    // set new time zone
    date_default_timezone_set( 'Asia/Tokyo' );
    
    // get transient expiration
    $transient_expiration = mktime( 24, 0, 0 ) - time();
    
    // reset time zone
    date_default_timezone_set( $default_timezone );

    また、DateTimeクラスが良いとの事なので、頂いたURLを参考に次の様にしました。
    DateTimeクラスを使えば2038年問題も解決されるのですね。

    // time zone
    $timezone = new DateTimeZone( 'Asia/Tokyo' );
    
    // target time
    $target_time = date_create( 'tomorrow', $timezone )->format( 'U' );
    
    // current time
    $current_time = date_create( 'now', $timezone )->format( 'U' );
    
    // get transient expiration
    $transient_expiration = $target_time - $current_time;

    しかし、実行速度の速さと得られる結果が変わらない点から、とりあえずは現状のままでいこうと思います。

    $transient_expiration = 86400 - ( time() + 32400 ) % 86400;

    フォーラム: 使い方全般
    返信が含まれるトピック: 日替わりで投稿をランダムに表示
    トピック投稿者 developer

    (@6flat)

    すみません。
    気のせいかと思っていたのですが、次のうちやはり1.と2.は時間にずれが生じるようなので、一応報告だけしておきます。
    ずれが生じるのは0:00 – 9:00までの間で、その間はマイナスの値が増え続ける形になり、9時を境に正しい残り秒数になります。
    日付変更から丁度9時間の間だけずれが生じるので時差が関係しているのだと思いますが、具体的な原因はよく分かりません。

    // ローカル環境でのテスト
    
    /*
     * 1. サーバーのタイムゾーンに関わらずUTC+9を元に今日の残り時間を取得
     * 実行速度(1000回試行): 0.0034(秒)
     */
    $transient_expiration = mktime( 24, 0, 0 ) - time() - 32400;
    
    /*
     * 2. サーバーのタイムゾーンを元に今日の残り時間を取得
     * 実行速度(1000回試行): 0.10443(秒)
     */
    $transient_expiration = mktime( 24, 0, 0 ) - date_i18n( 'U' );
    
    /*
     * 3. 関数date_i18nで取得したUNIX時間の通計秒を元に計算
     * 実行速度(1000回試行): 0.10393(秒)
     */
    $transient_expiration = 86400 - date_i18n( 'U' ) % 86400;
    
    /*
     * 4. 3.の関数date_i18nを関数timeに変更して対応
     * 実行速度(1000回試行): 0.00022(秒)
     */
    $transient_expiration = 86400 - ( time() + 32400 ) % 86400;

    フォーラム: 使い方全般
    返信が含まれるトピック: 日替わりで投稿をランダムに表示
    トピック投稿者 developer

    (@6flat)

    お付き合い下さり感謝します。
    私もかなり混乱しましたが、先のコードを含めた次のいくつかのコードで取得出来ました。
    提示して頂いていたコードも、恐らく私の環境が悪かったのだと思いますが、今確認したところ正常に取得できていました。

    // ローカル環境でのテスト
    
    /*
     * 1. サーバーのタイムゾーンに関わらずUTC+9を元に今日の残り時間を取得
     * 実行速度(1000回試行): 0.0034(秒)
     */
    $transient_expiration = mktime( 24, 0, 0 ) - time() - 32400;
    
    /*
     * 2. サーバーのタイムゾーンを元に今日の残り時間を取得
     * 実行速度(1000回試行): 0.10443(秒)
     */
    $transient_expiration = mktime( 24, 0, 0 ) - date_i18n( 'U' );
    
    /*
     * 3. 関数date_i18nで取得したUNIX時間の通計秒を元に計算
     * 実行速度(1000回試行): 0.10393(秒)
     */
    $transient_expiration = 86400 - date_i18n( 'U' ) % 86400;
    
    /*
     * 4. 3.の関数date_i18nを関数timeに変更して対応
     * 実行速度(1000回試行): 0.00022(秒)
     */
    $transient_expiration = 86400 - ( time() + 32400 ) % 86400;

    一番分かりやすいのは2.なのですが、無難なのは4.なのかなと思います。

    フォーラム: 使い方全般
    返信が含まれるトピック: 日替わりで投稿をランダムに表示
    トピック投稿者 developer

    (@6flat)

    解決したと思ったのですが、日付が変わってから確認したところ「日付変更までの秒数」が正確に取得できていませんでした。

    $transient_expiration  = mktime( 23, 59, 59 ) - date_i18n( 'U' );
    var_dump( $transient_expiration );

    現時刻(1:10)で値が-4200となってしまいます。
    Instant WordPressによるローカル環境ではマイナスにはならない(それでも計算は合わない)ので、多分サーバーの設定によるものだと思うのですが…。

    追記

    $transient_expiration  = 86400 - date_i18n( 'U' ) % 86400;
    var_dump( $transient_expiration );

    これで正確な残り時間を取れました。

15件の返信を表示中 - 16 - 30件目 (全59件中)