WordPress高速化～オブジェクトキャッシュ編～
友人の会社のサイトが遅いというので、高速化を頼まれて以下を実施したところ劇的に改善した！のでメモっておく。 ※表示に10秒以上かかっていたのが3秒台にまで改善
topコマンドでリソース監視してみたところ、負荷かけたらCPUのwaitがかなり高かったのでCPUがボトルネックになってると判断したのでPHPのオブジェクトキャッシュを導入した。 ※たった2-3リクエストでwaitの値が増えちゃう…。WordPressってすごく重いですね。
PHPは5.3なので、apcというものになるらしい。 ※調べたところそれ以降のバージョンでは標準でopcacheってのがあるらしいのでINIの設定を追加するだけで使える。
参考にしたサイト www.webcreator-net.com
また、Apacheのチューニングもした。
やったのはtop -d1コマンド叩いてterminalのswapのusedの値見ながら、swapしないぎりぎりの設定を探った。
やっぱり、サイトがさくさく動くと気持ちいいですね。
WordPressの外観のカスタマイズが開けない
という、相談を友人から受けたので調査した。
その結果、Pluginの組み合わせが悪い時にこの現象が起きているようだ。 ソース読んでないので症状からの判断だが、
Page Builder by SiteOrigin && (Dynamic Widgets || WP Widget Cache)
の条件の時に起きるみたい。
※日本語でわかりやすく書くのがめんどくさいからJavaっぽい文法で表現してみた
あと、キャッシュPluginのせいで管理バーがサイトに表示されちゃってたので、
functions.phpに
add_filter( 'show_admin_bar', '__return_false' );
の1行を追加して対応。
WordPress3.1からサイトにも管理バー表示できるようにしたらしいけど、キャッシュ系Pluginと相性悪いみたい。
ってな感じの調査をしてたら疲れたので今日はここまでなり。
さあ、本職のためにJavaの勉強するぞ！！っと。
CoreDumpの取り方（自分用メモ）
友人のサイトの一部のページがPHPがクラッシュ？しているか何かで落ちてしまって見れなかったので調査中 その時、coredump取る手順を調べたのでメモしておく
ulimit -aで、現在の設定を確認 coreの行が0だったら吐かれてない
ulimit -c unlimitedで一時的に吐かれるように設定する
httpd.confにログの出力先を設定して、gracefulする
CoreDumpDirectory /tmp
すると、ログを設定したパスに出力されるようになる、はず ※というのも私の環境だと全然違うパスに出力されていた…。謎。
んで、
#gdb /usr/local/apache2/bin/httpd -c /tmp/core.30864
で、gdbでのデバッグ
whereで落ちた場所を特定（at何とかって出てくるはず）するが、 私の環境だと、無限ループっぽい…。（at何とかがでてこない）
参考にしたページ sarface2012.hatenablog.com
Linux環境設定/コアダンプを出力するようにする - Linuxと過ごす
別のアプローチで調べる必要がありそう。 さて、どうしようかなぁ。
※注意※ dump取り終わったら、ulimit -c 0で、設定オフにしないと、dump吐き続けます。かなり容量食うので、ディスク圧迫します。取り終わったら、オフにしましょう。 私の環境では数日で、8Gくらい溜まってました。
わかりやすいJavaEE データベースの基礎（１５章）ハマったとこ（その２）の続きのその３
結局のところ・・。
Glassfishのコンソールから、①jdbc resourcesを追加、②jdbc connection Pools追加、③DBからスキーマ削除、④プロジェクトに持続性ユニット追加、の順番でうまくいった！！
調べた感じ、JPAにテーブル作成させるためにユーザに何か権限与える必要があるのかな？とかいろいろ考えて調べたけど、そういう類の特別な設定は見当たらなかった。 どうやら、上記の順序が大事そう（確信は全くないので、これを見てる人がいたら順番入れ替えるとかして自分なりに検証して欲しい）だが、何がどうしてそうなっているのかはわからない。
ただ、次回同じ箇所で詰まった時はこの要素がわかっていればまた解決できそうな自信がついたので、この件の調査はここまでにする。
参考書の続きを進めようっと。
さー、明日（残り僅かな今日も）がんばるぞ。
わかりやすいJavaEE データベースの基礎（１５章）ハマったとこ（その２）の続きのその２
今度こそ、動いた！
動かすために必要だったこと
1と2で今回参考にしたHP yoshio3.com
3については、本には自動生成されると書いてあったので自分では作らなかったのですが、画面に表示されているStackTrace見るとSELECT文の発行時テーブルが存在しない、とエラーを出していました。
なので、テーブルを追加してみると動いた。
これは、アプリケーションにCREATE TABLEの権限がないのか、写経を私が間違えたか、そもそも本のコードが間違えててテーブル作成するための記載が抜けてる、あたりが原因かなーと推測中。
動いたけど、まだ気になるのでJPAの仕様も調べてみよう。
