技術

[WordPress] 記事を読む所要時間を表示させるプラグイン

昔に入れようと思っていてすっかり忘れていましたが、ふと使用されているサイトを見つけ思い出しまいた。こういう細かいツールは良いですね、楽しいです。

ITキヲスク | 記事を読む所要時間を表示させるWordPress用プラグイン「estimated」作ってみました。

先日、「たった一行追加するだけでサイトの滞在時間を13.8%伸ばす方法・・・」というタイトルで百式さん(←idea*ideaさんの間違いです。申し訳ありません。。。)が紹介されていた、記事の冒頭に”記事を全て読み終えるまでにかかる、おおよその所要時間”を表示させるというワザですが、自分、勉強も兼ねてWordPressプラグインとして作ってみました!

 

書かれているように滞在時間が伸びるというのがあるのかないのかわかりませんが。Google Analyticsによるとこの際の平均滞在時間は2分弱の模様です。

image

しばらく使ってみてこれから増えるといいですが。

[Amazon RDS] ものは試しと使ってみた。課金(コスト)さえ気にしなければ簡単で素晴らしい。

さくらインターネット スタンダードのボトルネックは共有DBだ、というコラムを見たりもして実際にはどうなのかなぁと思いながらそういえばAmazonでMySQLのクラウドサービスが始まっていたなぁと言う事をふと思い出したので勉強をしてみました。

実際には、Amazon RDS(MySQLのサービス名)では値段的に高いので実運用は出来ないので試しです。料金については、起動時間+送信データ等の従量課金で起動が $0.11/hour なので単純に一ヶ月で8000円程度で係る計算になろうかと思います。データ転送量はさほどではないとは思いますが。

料金はこちらのツールで計算することができます。http://calculator.s3.amazonaws.com/calc5.html?lng=ja_JP 1ヶ月まるまる使ってだいたい $82と出てきました。データ転送量はさほど課金されないのでなにか別の用途でも使わないと起動しているのがもったいないです(^^;

さてAmazon RDSの利用方法は以下のサイトで詳細に載っています。現在でも内容は変わりありませんでした。

上記では、コマンドラインからDBを作成したりしていますが実際にはWebコンソールを利用して行うことにより標準外のリージョンが選択できたり、保守時間帯を設定できたりしますのでそのほうが良いかと思います。

どうでもいい話ですが申込時に電話番号を入力すると折り返しでコールされます。その際に画面上に出ている数字をプッシュするのですがした途端にWeb画面上で「OK」と言う内容が表示されあまりの反応速度に驚くばかりです。

さて、環境としてはSakuraインターネット上のWordpressから利用することになりますので

  • MySQLのダンプを行う ( mysqldump コマンド)
  • Amazon RDS側にダンプしたファイルをImportする ( mysql コマンド )
  • wp-config.phpの該当の箇所を変更しておきます。

上記の作業で特に問題なく接続ができました。なんだか不思議な感じですが無事に動いています。先日のDBがキャッシュ等の機能により実際のリクエスト量は半減していると思うので従量課金の対象となるトランザクションは若干削減できていると思います。

 

気が向くまで使用してみようかと思います。最終的に戻さないといけないのとDBが他の用途でも使用しているので戻しは行わないでおこうかなぁとも思っています。この記事とかは再度アップすればいいので(^^; ちょっと適当な運用ですが。

 

update1:
少し見ていたところものすごく遅くなる感じが無いですね。やはり23時頃のアクセス時に非常に重たくなる原因はDB側にあるのかもしれません。きちんとソースの中にDBのコネクション時間などをロギングして見比べればいいのですがそこまでは手を付けてないのでなんちゃって比較にしかならないのですが・・・

 

update2:

というわけで昨日の続きですが一日使ってみました。きっちり起動時間分が請求されるみたいです。うちのWordpressのトラフィック程度ではI/Oリクエストもたいしたことはありませんでした。データ転送は多いのですがこちらは課金対象ではないみたいですね。

このまま放置して利用していると泣けるのでもとに戻しましょう!

クリップボード01
クリップボード01 Photo by tokiyan

 

パフォーマンスは昨晩も今晩も落ちることがなく一定の感じでしたのでやはりさくらインターネットのスタンダードプランではDBの遅さがネックで時間帯により重かったり軽かったりするというのはあっている気がしています(なんども書きますがきちんと測定していないのですが・・orz)

ある意味代替の目安がわかりよかった感じです。次は国内か、国外の他のレンタルサーバでも試してみたいのですが月額でコンスタンスに2000円とかちょっと無理なので安いところから試してみたい。

[WordPress] CSS/JSを圧縮して少しでも早くする

正直このレスポンスだと見る気が起きない。。このブログが遅くてちょっとイライラする。画面が表示しない、かと思えばすっと表示されたりすることもありよくわからない。他のサーバにとも思うけど。。(現在さくらインターネットスタンダードプランです)

さくらインターネットのコンパネから「リソース状況」→「CPU利用時間」を見てみました。

image

だいたいこんな感じです。Index.phpで1分以上かかっているとか(いつもではないです)、、、よくわからんorz  もっと調べてみないとよくわからないですね。何か重たい物があるせいなのか・・

image

Web側のアクセスツールを見てみると、503と500で2%程度あるのがわかります。「500 Internal Server Error 」もトップページで表示されたりもするのでPHPなどに問題があるわけではない気がしています。

というわけでhttp://www.webpagetest.orgでチェックをしてみました。

  • リンクが切れていたり、アクセスに時間がかかる物をチェック
  • 外部サイトの利用で遅いものをチェック

 

Cronの利用頻度を下げる

ちょっとCronも利用しているため現行の15分単位に実行されるものを2時間おきに変更しました。

プラグインを外す

色々見てみるとプラグインで重い感じの物があるので外してみました。基本的には外す気がなかったのですが一部のプラグインでテスト結果で非常に遅いものを除きました。今回はSyntaxにカラーをつけてくれる複数のプラグインで遅かったのでひとつのみにしました。

「Head Cleaner」 プラグインを導入する

CSSとかJSとかの読み込みに時間がかかっているように見受けられたので最適化をおこなってみました。先程のチェックツールで確認するとJSとCSSが圧縮されているのがわかります。時間もだいたい半分程度に鳴っているのでかなりいい感じです。(圧縮とかすると逆にCPUを使いそうな気もするが)

・色々弄る前(但し時間帯も混んでいる付近)
image

・いじった後 (これは変わりすぎなので・・)
image

ちなみに先日のDB Cache のログ上では

Generated in 0.871 seconds.
Made 29 queries to database and 10 cached queries.
Memory used – 23.7MB

な感じですね。

先日の、「[Wordpress] DB Cache Reloaded プラグインを入れて高速化 at Roguer http://roguer.info/2011/01/09/3598/ 」で早くなったかなぁと思ったら変わっていなかったので今回は期待して明日を楽しみにしたいと思います。。。

[WordPress] DB Cache Reloaded プラグインを入れて高速化

まず環境ですが、サーバはさくらインターネットスタンダードプランです。Wordpressを使用していますがDBへのアクセスが遅いようなきがしているのでプラグインを入れてみたいと思います。有名な、「WP Super Cache」などはなんか微妙だなぁとおもって昔から使用していません。

DB Cache Reloaded

通常にプラグインの検索から導入ができます。

DBCacheReloaded

オプションページから「有効」にチェックを入れれば無事に利用ができます。実際にアクセスするとたしかに早くなっているような気がします。ページを「ソース」表示してみると以下のような値が記載されています。

<!– WP-Awasete-Yomitai END –><!–stats_footer_test–><!– Generated in 3.189 seconds. Made 21 queries to database and 13 cached queries. Memory used – 22.77MB –><!– Cached by DB Cache Reloaded –>

{timer} – キャッシュ生成にかかった時間, {queries} – DBに対するクエリ数, {cached} – キャッシュされたクエリ数, {memory} 窶錀 メモリー

–1回目–
Generated in 3.189 seconds.
Made 21 queries to database and 13 cached queries.
Memory used – 22.77MB

–2回目–

Generated in 2.157 seconds.
Made 21 queries to database and 13 cached queries.
Memory used – 22.77MB

–3回目–

Generated in 0.983 seconds.
Made 23 queries to database and 11 cached queries.
Memory used – 22.77MB

もっと真面目に、という気もしますがトップページ http://roguer.info を3回表示させてみた結果です。さくらインターネットのようにDBが別の共有環境にあり遅いという場合には有効に効いてくれるかなという期待を込めて導入してみました。なんかおかしくなっているよとか見つけ方はお手数ですが教えていただけると助かります。

参考文献

ゆっくりと… ≫ WordPressキャッシュ系プラグインの比較とサイトに適した選び方

WordPress の運営を始めて1年後にしてようやく(満を持して!)、キャッシュ・プラグインを使い始めています。とは言っても、最初は 「アレが速い」 とか 「コレが良い」 などといった記事に目移りして、何をどう使えばよく分かりませんでしたが、ここらで私が理解出来ていることをまとめてみたいと思います。

[MySQL] オーバヘッドが発生している際の最適化

最近、どうもブログの反応遅い。まぁさくらインターネットのスタンダードプランなので致し方ないところだとは思っています。Webの反応が悪いのはサーバのパフォーマンス制限もありますがDBのパフォーマンスがネックになることが多いので利用しているMySQLの状況を見てみました。

image

「オーバヘッド」の項目が増加しているのが分かります。ネットを調べているとWordpress関連でこの手のトラブルが多いみたいですね。MySQLのオーバヘッドが何者であるのか調べてみたけどよくわかりませんでした。Insert/Deleteなどが発生した際のゴミ?のような事が書いてあるサイトもありましたがフラグメンテーション状態のようなものなのでしょうか?

該当行をチェックして「テーブルを最適化」するを選択することで解消できます。解消後はサイズは0となっていることを確認できました。これで何が効果があるかはわかりませんが。

これらを毎回確認して試すのは面倒ですのでWordpressのDBの場合には、「WP-DBManager」プラグインを導入します。これで自動的に最適化ができるオプションがありますので選択をしておきましょう。

まぁ正直大して変わりませんがトラブルの芽は少なくしておくのが良いですね。

上部へスクロール