Tag Archives: WordPress

Permalink to single post

WordPress (の特に重い管理画面) がやや高速化できた

WordPressが重すぎて、うちの弱小インスタンスではとても厳しかった。特に編集画面が遅い。
投稿の表示の方はキャッシュすれば比較的どうにかなってた。(キャッシュに乗ってないとこちらもかなり厳しい)

が、以下の解説ページを見つけて、そこにある「001 Prime Strategy Translate Accelerator」をインストールしたらやや改善された。翻訳ファイル (MOファイル) のなにがしかを良き計らいでキャッシュしてくれるらしい。

あと、全体的なキャッシュに W3 total cache を使ってるんだけど、これのObject Cacheをきると良いって書いてあった (WordPressの管理画面が重い場合の対処法) のでそれもやっといた。そちらの効果のほどは未知数。。。

管理画面の表示の早さとかどうでもよくね?と聞こえてきそうだが、これ遅いだけで僕のやる気がそがれるんです。毎回操作のたびに十秒ぐらい待たされるし。これのおかげで途中で書くのをやめたエントリ多数。(人のせいにするなよ)

Permalink to single post

WordPressのベンチマーク

卒論とかやばい。にも関わらず鯖いじり。

現在atomでサーバー(自宅サーバー)やってみたりしてます。省電力だし、大してスペックもいらねぇだろうと思っていたからです。が、WordPressとかPukiWikiとかがやっぱり遅い。過去にWordPressの高速化を試みたりもしましたが、結局のところあまり成果は出ず。最終的にこれはAtomが原因なのかその他の要因があるのか区別するためにもベンチマークとってみました。

テスト環境

  • 環境A: 現行サーバー
    • Intel Atom N330 (1.6GHz Dual Core+HT)
    • メモリ 2GB(2GB DDR2一枚)
  • 環境B: デスクトップマシン
    • Intel Core 2 Duo E8500 (3.16GHz Dual Core)
    • メモリ 4GB(2GB DDR2二枚)

ソフトウェアは両方同じ。

  • Gentoo Linux
  • Apache/2.2.14
  • WordPress 2.9.1-ja

で、Apache Benchを使って計測。CPU能力はかるのが目的なので、ローカルホストからのアクセスのみ計測しました。

コマンドは

$ ab -n 100 -c 10 http://wordpressのトップページのURL/

です。

そしてその結果

  • 環境A (Atom)

Document Path:          /path/to/wordpress
Document Length:        5964 bytes

Concurrency Level:      10
Time taken for tests:   33.000 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      631600 bytes
HTML transferred:       596400 bytes
Requests per second:    3.03 [#/sec] (mean)
Time per request:       3300.000 [ms] (mean)
Time per request:       330.000 [ms] (mean, across all concurrent requests)

Transfer rate:          18.69 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:  1410 3227 561.2   3290    4610
Waiting:     1410 3224 561.4   3290    4610
Total:       1410 3227 561.2   3290    4610

Percentage of the requests served within a certain time (ms)
50%   3290
66%   3480
75%   3570
80%   3640
90%   3800
95%   4030
98%   4460
99%   4610
100%   4610 (longest request)

  • 環境B

Document Path:          /path/to/wordpress/
Document Length:        5610 bytes

Concurrency Level:      10
Time taken for tests:   8.536 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      585100 bytes
HTML transferred:       561000 bytes
Requests per second:    11.71 [#/sec] (mean)
Time per request:       853.649 [ms] (mean)
Time per request:       85.365 [ms] (mean, across all concurrent requests)

Transfer rate:          66.93 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   407  841 131.7    842    1237
Waiting:      407  841 131.7    842    1237
Total:        407  841 131.7    842    1237

Percentage of the requests served within a certain time (ms)
50%    842
66%    890
75%    916
80%    940
90%   1009
95%   1044
98%   1165
99%   1237
100%   1237 (longest request)

Core 2 duo E8500のが4倍近く早いですね。

結論

以前、wp-cacheを導入してみた時も4倍近く早くなりました。つまり、Core 2 Duo E8500の場合であればボトルネックは別のところ(ディスクアクセスとか?)に発生していると推定することもできます。

その推定が正しければ、このWordPressの速度のボトルネックはやっぱりAtomになってしまうようです。

WordPressだのWikiだの、Webプログラム使いまくる人にはやっぱりAtomはやや厳しいところがあるようです。

・・・まぁ当たり前っちゃ当たり前か。

ということで、WordPressを高速化するためにも新しいサーバーを買うことにするわけなのです。

Permalink to single post

gallery2 and MediaWiki

gallery2再配置

gallery2(本家サイト)という、とても出来が良いWebアルバムシステムがある。それをsunaga-labに設置してあったんだけど、すこぶる調子が悪い。

大量の写真を操作した後、削除しようとするとロックのエラーがでる。

Error (ERROR_LOCK_REQUIRED)

*in modules/core/classes/GalleryFileSystemEntity.class at line 260 (GalleryCoreApi::error)
*in modules/core/classes/GalleryItem.class at line 327 (GalleryFileSystemEntity::delete)
*in modules/core/classes/GalleryDataItem.class at line 236 (GalleryItem::delete)
* in modules/core/classes/helpers/GalleryEntityHelper_medium.class at line 113 (GalleryDataItem::delete)
* in modules/core/classes/GalleryCoreApi.class at line 2271 (GalleryEntityHelper_medium::deleteEntityById)
* in modules/core/classes/GalleryItem.class at line 307 (GalleryCoreApi::deleteEntityById)
* in modules/core/classes/GalleryAlbumItem.class at line 260 (GalleryItem::delete)
* in modules/core/classes/helpers/GalleryEntityHelper_medium.class at line 113 (GalleryAlbumItem::delete)
* in modules/core/classes/GalleryCoreApi.class at line 2271 (GalleryEntityHelper_medium::deleteEntityById)
* in modules/core/ItemDelete.inc at line 79 (GalleryCoreApi::deleteEntityById)
* in main.php at line 231 (ItemDeleteController::handleRequest)
* in main.php at line 94
* in main.php at line 83

こんな具合。

ということで「gallery2 ERROR_LOCK_REQUIRED」でググってみると公式のフォーラムにヒット(ヒットしたページへ)。そこには

If you need a quick fix, try switching to ‘Database’ on ‘Site Admin’ -> ‘Lock System’

と書いてあった。ということで、ロック(管理画面→全般→ページ内にある’ロックシステム’の項目)をデータベースにしてみたら、すんなり動いた。パフォーマンスが落ちるとも書いてあったが、あんまし気にならないし調子がいいのでとりあえずこれでいいか。

gallery2 with MediaWiki

Gallery2の出来がいいので、sunaga-labの画像管理を全部Gallery2にしてしまいたい。それを実現するっぽいMediaWikiのextensionはいくつかあるのだが、微妙に僕にとっては使い辛い。

なので新しく作成中。あらかた完成。

ちゃんと完成したら、英語のドキュメントつけて本家に送りつけるか。

あとWordPressとの統合もちゃんとやりたいけど、こっちはニーズを満たした拡張が既にあるかもしれない。。。

ToDo: LDAP

いろいろあるアカウントを統合したいのでOpenLDAPでディレクトリサービスを構築したい。

  • www.sunaga-lab.net(MediaWiki)
  • sunagae.net(WordPress)
  • webアルバム(Gallery2)
  • レポジトリ管理(Subversion)
  • Apacheアクセス制御
  • UNIXユーザー×4台
  • Windows Serverユーザー×2台(これは統合無理か?)

この辺のアカウントとかアクセス情報を統合したい。あとパスワードとかアカウント登録とかのWebインターフェイスも欲しい。

以前、アカウントの統合にOpenIDを使ってみた(多分sunagae.netにもその残骸が・・・)のだけど、激しく使えない。なにより認証が面倒だし、IDも長ったらしいし、細かいところが不自由。

ということで、OpenLDAPを使ってしまって、内部的にだけアカウントを統合しようという作戦。

だが、OpenLDAP自体が難しそうな上(はるか昔に挫折した記憶が)、激しく時間が足りない。というか院試の勉強せねば。

Permalink to single post

WordPress高速化を試みる

graphunoptindexzermeloSunagaeでは現在WordPressを使用しています。最近はその速度の遅さが気になっています。その遅さの原因を探って、改善を試みました。

» 続きを読む…