MySQL5.5のベンチマークテスト その２

こんにちは、matsuiです。

前回に引き続き、MySQL5.5のベンチマークについて、mysqlslapを使って得られた結果から5.5の特徴を見ていきたいと思います。
進め方は前回と同様、MySQL5.1とMySQL5.5のベンチマークのスコアを対比させる形です。

条件5
$ mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary -e innodb --number-int-cols=3 --number-char-cols=5 --concurrency=1000 --auto-generate-sql-write-number=300 --auto-generate-sql-execute-number=300 --auto-generate-sql-load-type=mixed --create-schema=test -h localhost -u root -p

MySQL5.1
Average number of seconds to run all queries: 646.631 seconds
Minimum number of seconds to run all queries: 646.631 seconds
Maximum number of seconds to run all queries: 646.631 seconds
Number of clients running queries: 1000
Average number of queries per client: 300

MySQL5.5
Average number of seconds to run all queries: 601.654 seconds
Minimum number of seconds to run all queries: 601.654 seconds
Maximum number of seconds to run all queries: 601.654 seconds
Number of clients running queries: 1000
Average number of queries per client: 300

前回の条件4の結果からクライアントの数よりもクエリ数の方が実行時間に大きな影響を与えると推測し、クライアント数はそのままにクエリ数を条件4の30から10倍し、300で実行してみました。
5.1は8倍、5.5は100倍かかったということで、どちらも急激に実行時間が長くなっています。
性能劣化の比率だけで言うのであれば、5.5の方が性能劣化が激しいですが、そもそも条件4の結果自体が5.1と5.5で13倍近く違いますので、この結果だけでは5.5になって性能が劣化したとは言えません。


条件6
$ mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary -e innodb --number-int-cols=10 --number-char-cols=10 --concurrency=1000 --auto-generate-sql-write-number=10 --auto-generate-sql-execute-number=30 --auto-generate-sql-load-type=mixed --create-schema=test -h localhost -u root -p

MySQL5.1
Average number of seconds to run all queries: 20.053 seconds
Minimum number of seconds to run all queries: 20.053 seconds
Maximum number of seconds to run all queries: 20.053 seconds
Number of clients running queries: 1000
Average number of queries per client: 30

MySQL5.5
Average number of seconds to run all queries: 12.499 seconds
Minimum number of seconds to run all queries: 12.499 seconds
Maximum number of seconds to run all queries: 12.499 seconds
Number of clients running queries: 1000
Average number of queries per client: 30

条件6では少々検証方向性を変更し、クライアント数とクエリ数は条件4と同じのまま、カラム数と事前に存在するデータの量を変更しています。
カラム数はintとcharを合わせて5倍近くになっていますが、事前に用意されるデータは1/10です(もともと大した量ではないので、実行前の予測としては結果にを与えるほどの減少量ではないと予測しました)。
結果を見ると、条件4よりも処理時間が短くなりました。
カラム自体は増えているはずですので、事前に存在するデータの量が、実行時間に大きな影響を与えたのでしょうか。
ちなみに--auto-generate-sql-load-typeをmixedに指定していますので(mixedはpkによるselectとinsert)、実行時間の変化はSELECT文の発行によるものなのかもしれません。


条件7
$ mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary -e innodb --number-int-cols=10 --number-char-cols=10 --concurrency=500 --auto-generate-sql-write-number=10 --auto-generate-sql-execute-number=30 --auto-generate-sql-load-type=mixed --create-schema=test -h localhost -u root -p

MySQL5.1
Average number of seconds to run all queries: 5.148 seconds
Minimum number of seconds to run all queries: 5.148 seconds
Maximum number of seconds to run all queries: 5.148 seconds
Number of clients running queries: 500
Average number of queries per client: 30

MySQL5.5
Average number of seconds to run all queries: 3.661 seconds
Minimum number of seconds to run all queries: 3.661 seconds
Maximum number of seconds to run all queries: 3.661 seconds
Number of clients running queries: 500
Average number of queries per client: 30

条件6からクライアントを半減させました。
条件3からみた場合クライアント数は同じで、クエリ数は条件3の1/3です。
条件4からみた場合は、クライアント数が半分で、クエリ数は同一です。
カラム数と事前のデータについてもは条件6と同様です。
5.5についてはクライアント数が1000程度の場合、処理時間はクライアント数に比例しています。
やはり5.1と5.5では、大幅な処理時間の劣化が始まるポイントが改善され、より安定して高いパフォーマンスが出るように調整されているように思えます。


最終結果
2回に分けてMySQLの5.1と5.5を比較してきましたが、なんとなく特徴が見えてきたのではないでしょうか(検証しきれなかった問題もありますが…)。
今回の検証で特におもしろい結果となったのは、条件4のようなケース(多数のクライアントで少量のSQL実行)において、5.1よりも並列処理性能が大幅に増したという点です。
ソーシャルゲームのように多数のクライアントが比較的少数のSQLを実行するというケースにおいて、特に重要な改善と言えます。
また、サーバの管理コストの面からみると、サーバプログラムの性能向上はそのままサーバの管理コスト減につながります。

全てのケースにおいて、5.5のパフォーマンス向上は素晴らしいものがあり、特に(処理限界は実行環境のスペックに左右されますが)「並列処理性能向上」と「パフォーマンス劣化開始地点の引き上げ」はMySQLに関わる方全てに非常にうれしい点といえるのではないでしょうか。
MySQK5.1から設定周りで変更点も少なくないですが、弊社で運用している限りMySQL5.5を使ったために発生したトラブルはありません。
5.1から5.5へ移行できる環境であるならば、ぜひ5.5への切り替えを検討されてはいかがでしょうか。

新卒エンジニアも勉強会に行ってみると良いですよ、という話

こんにちは、Yuzuruです。

自分は今年の４月から新卒で働き始めたばかりなのでちょっとちがったテーマで書いてみようと思います。

さて、記念すべき(?)一回目のテーマは勉強会です。

弊社たゆたうでは勉強会への参加が推奨されているのですが、新人となると知り合いもいないし、自信もない… なかなか不安が多くて足踏みしてしまう世界なのではないかと思います。

自分もまだまだ新米なので恐縮ですが、とりあえず最初に当たって砕けろで参加したときに「行って良かったなぁ」と感じたことを挙げてみるので何かの参考になれば幸いです。

・自分がライン上にいるというのが分かる
  完璧にはわからないまでもなにか知っていることがあるともうちょっとで理解できそう！と自分がその道にいることを認識できます。 

 ・研修の成果が実感できる
   もちろん全てが繋がっているわけではないのですが、不安と期待の入り交じった中で行った研修も同上の理由で納得度UPかもしれません。

・未来への視野が拡がる
   技術寄りの関心を持った人が周りに増えると自然とイメージも沸いてくる…気がします。

・単語の読み方、発音がわかる
   ネットや書籍だと意外とわからない！

・今までどういうスタンスでやってきたか、社会の先輩に聞ける機会
   就職活動における説明会などはいわゆる建前も多いわけで…。勉強会にもよりますがフランクに会話してくれる方が多いと思います。

・次の為のバネになる
   内容がわからなかったりすると次はわかるようになろう！という気持ちが芽生えます。

・色々楽しくなる
   上に挙げたようなことを実感できるとスキルアップの意味が大きくなり仕事の楽しみが増え、勉強会自体や技術情報を集めたりする楽しさも増えます。

ちなみに自分が初めて参加したのはJAWSUGの勉強会でした。

ネットで簡単エントリできる勉強会も多いので、色々参加してみると新しい発見があるかもしれませんね。

※行って良かった楽しかった！で終わらないようにアウトプットするのも大事とよく聞きます。なかなかできてないので反省…。

Xdebugのプロファイル

こんにちは、hodori です。

PHPで開発を行うエンジニアがよくお世話になるのがXdebugのプロファイル機能です。

実行される順番や各関数ごとの実行時間・実行回数などの役に立つ情報をとれるので

デバッグやボトルネックを調査する際に大変便利なものです。

普通に使う分にはXdebugを投入して php.ini の中に

xdebug.profiler_enable = 1

を記述するだけなので簡単に使えます。

ただ、この状態だとすべてのアクセスでプロファイルが作られるので

クラウド上に開発環境を置いて共用で使う場合などは

調査したいファイルのプロファイル以外にも多数のプロファイルができてしまい

必要なプロファイルを探すのが少々面倒だったりします。

それを回避するための方法を二つほど紹介しようと思います。

一つ目はプロファイルを生成するホスト名を指定する方法があります。

共用の環境に複数のVirtualHostを作って運用している場合に

任意のHostへのアクセスだけプロファイルを残す設定です。

　　xdebug.remote_host = "local.hoststar"

管理用のページとアプリを同じサーバーの別VirtualHostとして

運用している場合などにアプリのプロファイルだけを残す事が出来ます。

もう一つの方法は少々手間が増えることになりますが、

プロファイルを生成したい場合のみ、その旨をパラメータで指定する方法です。

設定は php.ini に下記の2行を記述して

xdebug.profiler_enable = 0

xdebug.profiler_enable_trigger = 1

プロファイルを生成したい場合にGETかPOSTで「XDEBUG_PROFILE」を送ると

その場合のみプロファイルが生成されます。

携帯端末などでテストしている場合などは入力が少し面倒だったりしますが……。

Firefoxのアドオンの「Xdebug Helper」のプロファイル生成のON/OFF機能なども

この設定を使っていたりします。Firefoxを使えない状況でも少しの面倒で

使い分けができるので覚えておくと便利かなと思い紹介させていただきました。

PHPテンプレートエンジンTwig その１

こんにちは、Nakajinです。

弊社では、主にPHPを使って開発をしていますが、テンプレートエンジンとしてTwigを導入してみました。

今回はTwigの記述方法について簡単に説明したいと思います。

まず初めに、簡単なサンプルを以下に記述します。

[ソース]

{% set test = 'あいうえお' %}

{{ test }}

[表示]

あいうえお

Twigでは基本的に「{{ }}」「{% %}」の２つの区切り文字を使って記述していきます。

{% set test = 'あいうえお' %}

1行目では、test という変数に「あいうえお」という文字列を格納しています。

条件式やループ、変数の代入などに「{% %}」を使用します。

2行目では、test変数の値を出力しています。

変数の出力に「{{ }}」を使用します。

Twigは、テンプレートの継承機能などもあり、独自のカスタムタグの追加など拡張性も高いので、ぜひ使って見てください。