EC-CUBE 開発コミュニティ

機能要望 > 管理機能 > 郵便番号辞書登録の高速化

管理機能

投稿者	スレッド
nanasess	投稿日時: 2014/3/10 10:20 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2314	Re: 郵便番号辞書登録の高速化引用： snittaさんは書きました：プリペアドステートメントと俺俺バルクインサートを組み合わせたパッチを用意いたしました。 nanasess様のパッチとred様のヒントをベースにしています。 https://gist.github.com/zenith6/9412002 50件で頭打ちなのは、なかなか悩ましい結果ですね。。プリペアドステートメントを使用せず、直接 INSERT 文を生成した方が速いという説もありますし。。(さすがにブレースホルダを使わないのは怖いですが) ちょっと時間ができたら、こちらでも MySQL で試してみたいと思います。

snitta	投稿日時: 2014/3/7 23:42 対応状況: −−−
一人前登録日: 2013/10/3 居住地: 島根県投稿: 100	Re: 郵便番号辞書登録の高速化プリペアドステートメントと俺俺バルクインサートを組み合わせたパッチを用意いたしました。 nanasess様のパッチとred様のヒントをベースにしています。 https://gist.github.com/zenith6/9412002 効果(最上段が素の状態): `+---------+----------+-----------+---------+ \| ﾌﾟﾘﾍﾟｱﾄﾞ\| ﾊﾞﾙｸ件数 \| 処理時間 \| 比率 \| +---------+----------+-----------+---------+ \| しない \| 1 \| 477.440秒 \| 100.00% \| \| する \| 1 \| 253.770秒 \| 53.15% \| \| する \| 50 \| 182.922秒 \| 38.31% \| \| する \| 100 \| 194.614秒 \| 40.76% \| \| する \| 500 \| 201.340秒 \| 42.17% \| \| する \| 1000 \| 226.270秒 \| 47.39% \| +---------+----------+-----------+---------+` バルクインサートがわずか50件で頭打ちになった原因は貧弱なアプリケーションサーバーがボトルネックになっている為ですこの辺りの条件は環境依存が強いと思います。よろしければこちらもお試し頂けますと幸いです。 ---------------- Seiji Nitta zenith6@gmail.com https://github.com/zenith6/

snitta	投稿日時: 2014/3/7 22:15 対応状況: −−−
一人前登録日: 2013/10/3 居住地: 島根県投稿: 100	Re: 郵便番号辞書登録の高速化 red様とnanasess様両者を方法を取り入れてみると良さそうですね。 ---------------- Seiji Nitta zenith6@gmail.com https://github.com/zenith6/

red	投稿日時: 2014/3/7 21:49 対応状況: −−−
神登録日: 2010/2/15 居住地: 東京都投稿: 1570	Re: 郵便番号辞書登録の高速化んー、トランザクション使って100行ずつコミットするようにするとかだけでも全然スピードが違う気がします。 ---------------- EC-CUBEのカスタマイズ、トラブル解決承りますお気軽にお問い合わせ下さい https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

snitta	投稿日時: 2014/3/7 21:16 対応状況: −−−
一人前登録日: 2013/10/3 居住地: 島根県投稿: 100	Re: 郵便番号辞書登録の高速化引用：郵便番号辞書登録に関しては、あまりカスタマイズするような箇所でもありませんし、DBFactory に処理を移して、ネイティブ関数を使うようにしても良いかもしれませんね。私も良いと思います。引用：ちなみに、参考にした以下のサイトでは、プリペアドステートメントを使用せずに、直接 INSERT 文を生成して実行してますが、こちらの方が速いものなのでしょうか。一般的に速くなりますね。 SQLの解析時間よりネットワークがボトルネックになるケースが一般的ですし。外部からの入力じゃないからプリペアドステートメントを強要しなくてもいいかなぁ…。 ---------------- Seiji Nitta zenith6@gmail.com https://github.com/zenith6/

nanasess	投稿日時: 2014/3/7 20:17 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2314	Re: 郵便番号辞書登録の高速化引用： redさんは書きました：自分は高速化するときは http://d.hatena.ne.jp/sh2/20090528 を参考に1000行ずつ一気にインサートする形に変えてます個別にチューニングする場合は、こういう方法もありですね。 PostgreSQL でも COPY 文でロードすれば一瞬ですし。 JDBCだと、こういうところが抽象化されてて便利なんですけど、 PHP は個別にゴリゴリ書くしかないですよね。。

red	投稿日時: 2014/3/7 19:38 対応状況: −−−
神登録日: 2010/2/15 居住地: 東京都投稿: 1570	Re: 郵便番号辞書登録の高速化自分は高速化するときは http://d.hatena.ne.jp/sh2/20090528 を参考に1000行ずつ一気にインサートする形に変えてます ---------------- EC-CUBEのカスタマイズ、トラブル解決承りますお気軽にお問い合わせ下さい https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

nanasess	投稿日時: 2014/3/7 19:25 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2314	Re: 郵便番号辞書登録の高速化引用：うーん酷いｗ MDB2はどんなクエリーにも必ずプリペアドステートメントを使うので単純に2倍負荷が掛かるようですね。更にMDB2の mysql ドライバーはプリペアドステートメントとの相性が最悪で、引数の数だけクエリーが増えます MySQLに限っては mysqli ドライバーに変えるだけでも改善されるかも？なるほど。。やっぱり圧倒的な差がでますね。。郵便番号辞書登録に関しては、あまりカスタマイズするような箇所でもありませんし、DBFactory に処理を移して、ネイティブ関数を使うようにしても良いかもしれませんね。ちなみに、参考にした以下のサイトでは、プリペアドステートメントを使用せずに、直接 INSERT 文を生成して実行してますが、こちらの方が速いものなのでしょうか。 http://webrescue.net/archives/4107

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 ドライバーに変えるだけでも改善されるかも？ ---------------- Seiji Nitta zenith6@gmail.com https://github.com/zenith6/

nanasess	投稿日時: 2014/3/7 16:28 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2314	Re: 郵便番号辞書登録の高速化 snitta さま、早速のご検証ありがとうございます! MySQL でも大幅に改善されるとのことで、安心しました。引用：気付いたところで一点だけ、 CSVの展開にexplode()を使うよう変更されていますが、 CSVの仕様遵守の方がパフォーマンスよりも大切だと思いますので元のfgetcsv()を利用されてはいかがでしょうか？そうなんですよね。せっかくファイルポインタを取得しているので fgetcsv() を使用した方がすっきり書けるんですよね。まだきちんと検証できているわけではありませんが、そこそこ大きなファイルを扱いますので、 csv の展開もきちんとベンチマークしたいですね。余談ですが、 mysql_* 系のネイティブ関数を使用した場合は、どれくらいのパフォーマンスになるか興味があります。

(1) 2 »