PostgreSQLでアクセス数を30分間に4万回程度のアクセスを行うアプリケーションを作ろうと考えています。

OSはRedhat 5で1台です。(クラスタやロードバランスは行いません。)
PostgreSQLのバージョンは8.3です。
4万回アクセスしますがデータ量は数十レコード程度です。
数十レコードに対して、Insert,Delete,Update,Selectを繰り返します。
Indexなどは使ってません。

これの性能テストを行いたいのですが、確認するポイントと気をつける点を教えてください。

通常のメモリ使用量、CPU使用量は確認するつもりなのでそれ以外の情報をください。

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2010/02/13 18:10:47
  • 終了:2010/02/13 23:22:00

ベストアンサー

id:e55ind No.1

e55ind回答回数162ベストアンサー獲得回数42010/02/13 18:47:32

ポイント35pt

コネクション数のテスト

同時に何コネクション接続可能か?コネクション数に基づく性能評価

id:pinkymonk

ありがとうございます。

たしかにコネクション数は100本を使いまわすのですが、これを確認しないといけないですね。

コネクションに対してどのような性能評価をすればよいでしょうか。

2010/02/13 19:00:15

その他の回答(1件)

id:e55ind No.1

e55ind回答回数162ベストアンサー獲得回数42010/02/13 18:47:32ここでベストアンサー

ポイント35pt

コネクション数のテスト

同時に何コネクション接続可能か?コネクション数に基づく性能評価

id:pinkymonk

ありがとうございます。

たしかにコネクション数は100本を使いまわすのですが、これを確認しないといけないですね。

コネクションに対してどのような性能評価をすればよいでしょうか。

2010/02/13 19:00:15
id:e55ind No.2

e55ind回答回数162ベストアンサー獲得回数42010/02/13 22:55:10

ポイント35pt

>コネクションに対してどのような性能評価をすればよいでしょうか。

高付加をかけたときの応答時間とかです。

WEBの場合とかはコネクションプールを使ってさばくのですが、そうでない場合は

あまり意識したことがないのでわかりません

http://oldwww.php.gr.jp/seminar/20040821/phpcon2004-light-1.pdf

たとえば、WEBとかでは、無料のツールでは、JMeterとかをつかって負荷をかけてテストします。

この場合は、DBのコネクションじゃなくてHTTPですが、HTTPのコネクション数に

DBのコネクション数が比例することが多いので、これでDB関係の性能を評価します。

http://www.stackasterisk.jp/tech/engineer/jmeter01_01.jsp

PostgreSQLと質問文にかいてますが、私は一般的なDBに関して回答してます。


DBの同時アクセスとコネクション関係ははまることが多いので、負荷テストされたほうがよいと

考えて、回答1は回答しています。単純な例なら、メモリーリークやメモリー不足、処理事態が落ちるとかですが

すでに質問にかかれてますので、高付加を書けたときのレスポンスの評価ぐらいでしょうか?

id:pinkymonk

ありがとうございます。いろいろとお手数をおかけいたします。

よくわかりました。

JMeterを使っての負荷試験は予定しているので、コネクションに対してのテストも行いたいと思います。

また、今回は仕様上コネクションプールを使っていないので、

皆様のご意見を元に擬似的にQueueを作成し順次処理を行うようにしてコネクション数の過負荷にならないように制御を行いたいと思います。

2010/02/13 23:21:36
  • id:karuishi
    >数十レコードに対して、Insert,Delete,Update,Selectを繰り返します。
    >Indexなどは使ってません。
    インメモリDB使うか配列で処理する方法は、検討されて却下でしょうか?
  • id:pinkymonk
    karuishiさま
    ありがとうございます。

    こちらはいずれも却下となってます。
    あくまで仕様の路線としてはDBを使うという方向性で
    現在開発が進んでいますので、
    この形で性能の裏づけをつけたいと思っています。

  • id:kn1967
    >インメモリDB
    数十行ならデフォルトサイズの共有メモリでも十二分に収まるだろうし、
    焦点とすればHDDアクセスが発生するINSERTが連続して行われる時くらい。
    (これはWALの値を見直す事でタイミング調整も可能。)

    >コネクション数のテスト
    今回の条件ならPostgreSQLそのものよりもネックになる可能性ははらんでいるね。
    そこまで判った上で回答してるならいいけど、過去の回答を見る限り、偶然だろ。

    テストケースとして、数十行ってのは平均的な値を得るにはそもそも不適当なので、
    今回は、コメントだけ。
  • id:e55ind
    id:kn1967さん
    >今回の条件ならPostgreSQLそのものよりもネックになる可能性ははらんでいるね。
    >そこまで判った上で回答してるならいいけど、過去の回答を見る限り、偶然だろ。

    誹謗中傷はやめてください。
    WEBでDBのコネクション数の負荷テストをするのは常識です。
    偶然であろうとなかろうと、正しい解答をしてるわけですから、
    それにけちをつけて人格を否定する行為はやめていただきたい。
  • id:kn1967
    e55ind 2010-02-13 19:42:04
    >誹謗中傷はやめてください。
    >WEBでDBのコネクション数の負荷テストをするのは常識です。
    >偶然であろうとなかろうと、正しい解答をしてるわけですから、
    >それにけちをつけて人格を否定する行為はやめていただきたい。

    偶然は正しい解答とは言いません。
    それに振り回される人の事を考えてください。
    30分で4万回という数値も既にあがっていますので、
    いまさら、それだけを回答するという事に意味はありません。

    単に過去の履歴から推測して「偶然だろう」としているだけであって、
    人格否定や誹謗中傷などは行っていません。

    人格否定や誹謗中傷というのは、下記のような書き込みの事を言います。
    http://q.hatena.ne.jp/1265168572#a988666
  • id:kn1967
    PostgreSQLではなく、単にWEBサーバーの負荷テストの方向で、
    納得されたようですね。> id:pinkymonk さん

    裏で、
    http://q.hatena.ne.jp/1266061842
    http://q.hatena.ne.jp/1266067850
    といったような事もあったのですが、
    質問者ご当人が、いるか賞までだして、納得なさったということで、今件に関し、
    id:e55ind さんの行動が認められ、私のコメントが間違っていたという事と結し、
    関係各位に対し、ここに謝罪いたします。

    pinkymonk さんにおかれましては、お手数ではございますが、
    kn1967 が今後、貴殿に対してコメントや回答を行う事の無いよう、
    回答拒否設定に入れておいて頂けると、互いに楽になりますので、
    よろしくお願い申し上げます。
  • id:pinkymonk
    kn1967さま
    ありがとうございます。

    >裏で....
    >といったような事もあったのですが、
    私は、比較的長い間この人力検索にお世話になっておりますが
    いまだヘビーユーザーではなく、この場での所作にもなれておりませんので、
    裏で議論されていた事については、勝手ながら私が口を挟むべき事ではないと
    思いコメントは差し控えさせていただきます。

    この人力検索については、かつての技術系MLのような場所のように
    質問者にも回答者にも非常に厳しい作法が求められる場所でもないと思いますので、
    私はこれからも質問を投げさせて頂きたいと考えています。
    また、kn1967さまには、これからも機会があればご協力頂ければと考えています。


    私としましては、e55indさま、kn1967さま、karuishiさま皆様に
    等しくご回答、ヒントをいただいたとして感謝しております。
    ありがとうございます。


    最後に、WALのチューニングは検討しようと思います。


この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません