どうか教えて下さい！
| 機能要望 > 管理機能 > 郵便番号辞書登録の高速化 |
管理機能
 |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
| 投稿者 | スレッド |
|---|---|
| nanasess |
投稿日時: 2014/3/7 13:34
対応状況: −−−
|
神   登録日: 2006/9/9 居住地: 投稿: 2313 |
郵便番号辞書登録の高速化 レンタルサーバーなどで郵便番号辞書登録がタイムアウトしてしまう場合が多いので、高速化するパッチを作ってみました。よろしければお試しください。
http://svn.ec-cube.net/open_trac/ticket/2512 2.8 GHz Intel Core 2 Duo, メモリ8GB, HDD, PHP 5.3.28, PostgreSQL 9.2.7 の環境 改修なし - 119.28 秒 パッチ適用後 - 58.30秒 pg_prepare & pg_execute 使用 - 20.54秒 といった感じで、ネイティブ関数には遠く及びませんが、2倍程度の高速化が可能です。 MySQL などでも試して、良い感じであれば本体にコミットしたいと思います。 # さくっと作ったので多少の問題は発生するかもしれません。 実装にあたって、下記サイトのコードを参考にさせていただきました。 http://webrescue.net/archives/4107 |
| snitta |
投稿日時: 2014/3/7 15:50
対応状況: −−−
|
一人前   登録日: 2013/10/3 居住地: 島根県 投稿: 100 |
Re: 郵便番号辞書登録の高速化 大変いいパッチですね！
MySQLでも大幅に高速化されました。 ベンチマーク環境: Windows 8.1 PHP 5.5.9 MySQL 5.6.14 Athron Phenom II X3 2.80GHz メモリ 12.0GB SSD EC-CUBE: https://svn.ec-cube.net/open/branches/version-2_13-dev/?r=23350 パッチ適用前: 477.43961691856秒 パッチ適用後: 241.02066898346秒 気付いたところで一点だけ、 CSVの展開にexplode()を使うよう変更されていますが、 CSVの仕様遵守の方がパフォーマンスよりも大切だと思いますので 元のfgetcsv()を利用されてはいかがでしょうか？
|
| nanasess |
投稿日時: 2014/3/7 16:28
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 郵便番号辞書登録の高速化 snitta さま、
早速のご検証ありがとうございます! MySQL でも大幅に改善されるとのことで、安心しました。 引用：
そうなんですよね。せっかくファイルポインタを取得しているので fgetcsv() を使用した方がすっきり書けるんですよね。 まだきちんと検証できているわけではありませんが、 そこそこ大きなファイルを扱いますので、 csv の展開もきちんとベンチマークしたいですね。 余談ですが、 mysql_* 系のネイティブ関数を使用した場合は、どれくらいのパフォーマンスになるか興味があります。 |
| snitta |
投稿日時: 2014/3/7 19:07
対応状況: −−−
|
一人前 登録日: 2013/10/3 居住地: 島根県 投稿: 100 |
Re: 郵便番号辞書登録の高速化 引用：
余談ですが、 mysql_* 系のネイティブ関数を使用した場合は、どれくらいのパフォーマンスになるか興味があります。 nanasess様のパッチとなるべく同じ内容になるようにして計測してみました。 オリジナル: 477.43秒 nanasess様パッチ適用時: 241.02秒 mysql拡張直接使用時: 54.76秒 mysql拡張版のパッチ: https://gist.github.com/zenith6/9408542 うーん酷いｗ MDB2はどんなクエリーにも必ずプリペアドステートメントを使うので単純に2倍負荷が掛かるようですね。 更にMDB2の mysql ドライバーはプリペアドステートメントとの相性が最悪で、引数の数だけクエリーが増えます  MySQLに限っては mysqli ドライバーに変えるだけでも改善されるかも？
|
| nanasess |
投稿日時: 2014/3/7 19:25
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 郵便番号辞書登録の高速化 引用：
なるほど。。やっぱり圧倒的な差がでますね。。 郵便番号辞書登録に関しては、あまりカスタマイズするような箇所でもありませんし、DBFactory に処理を移して、ネイティブ関数を使うようにしても良いかもしれませんね。 ちなみに、参考にした以下のサイトでは、 プリペアドステートメントを使用せずに、直接 INSERT 文を生成して実行してますが、こちらの方が速いものなのでしょうか。 http://webrescue.net/archives/4107 |
| red |
投稿日時: 2014/3/7 19:38
対応状況: −−−
|
神  登録日: 2010/2/15 居住地: 東京都 投稿: 1570 |
Re: 郵便番号辞書登録の高速化 自分は高速化するときは
http://d.hatena.ne.jp/sh2/20090528 を参考に1000行ずつ一気にインサートする形に変えてます
|
| nanasess |
投稿日時: 2014/3/7 20:17
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 郵便番号辞書登録の高速化 引用：
個別にチューニングする場合は、こういう方法もありですね。 PostgreSQL でも COPY 文でロードすれば一瞬ですし。 JDBCだと、こういうところが抽象化されてて便利なんですけど、 PHP は個別にゴリゴリ書くしかないですよね。。 |
| snitta |
投稿日時: 2014/3/7 21:16
対応状況: −−−
|
一人前 登録日: 2013/10/3 居住地: 島根県 投稿: 100 |
Re: 郵便番号辞書登録の高速化 引用：
郵便番号辞書登録に関しては、あまりカスタマイズするような箇所でもありませんし、DBFactory に処理を移して、ネイティブ関数を使うようにしても良いかもしれませんね。 私も良いと思います。 引用： ちなみに、参考にした以下のサイトでは、 プリペアドステートメントを使用せずに、直接 INSERT 文を生成して実行してますが、こちらの方が速いものなのでしょうか。 一般的に速くなりますね。 SQLの解析時間よりネットワークがボトルネックになるケースが一般的ですし。 外部からの入力じゃないからプリペアドステートメントを強要しなくてもいいかなぁ…。
|
| red |
投稿日時: 2014/3/7 21:49
対応状況: −−−
|
神 登録日: 2010/2/15 居住地: 東京都 投稿: 1570 |
Re: 郵便番号辞書登録の高速化 んー、トランザクション使って100行ずつコミットするようにするとかだけでも全然スピードが違う気がします。
|
| snitta |
投稿日時: 2014/3/7 22:15
対応状況: −−−
|
一人前 登録日: 2013/10/3 居住地: 島根県 投稿: 100 |
Re: 郵便番号辞書登録の高速化 red様とnanasess様両者を方法を取り入れてみると良さそうですね。
|
| (1) 2 » | |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |
