[pgsql-jp: 29321] Re: パフォーマンス向上策

naoki kishida kishida @ fk.urban.ne.jp
2003年 3月 9日 (日) 09:19:57 JST


きしだです
めずらしく早起き。

[pgsql-jp: 29314]から
> ユーザ数が4〜5千を超えたあたりから、「決済履歴の表示が遅い!」とク
> レームあり。

ユーザー数4・5千程度であれば、いままでの話からテーブル構成を想像するとPostgreSQL
が遅くなるということはないと思います。
インデックスを適切に張れば改善したのではないでしょうか。
もしくは、コネクションプーリングを使ってなかったというのが考えられます。

[pgsql-jp: 29314]から
> ハードウェアはほぼ同スペックで、PostgreSQLのバージョンも変わりません。
> フロントエンドのスクリプトエンジンも同じくPHP4です。…にも関わらず、そ
> のシステムは圧倒的に速いのです。
> で、テーブル構造を見ると…全てのデータがひとつのテーブルに入ってました
> (驚愕)。リレーショナルもなにも、あったもんじゃありません。非常にショ
> ッキングでした(T_T)

1対1のテーブルであればひとつのテーブルにまとめても、それはリレーショナル
なモデルですよ。

[pgsql-jp: 29314]から
> #PHPのソースは見られなかったので、JDBCを使ってるかどうかは不明です。

PHPからJDBCは、基本的には使えません。
使ったとしても速くなりません。

[pgsql-jp: 29318]から
> HTMLテンプレートを用意して、実行時に置換してHTM出力…という具合です。
> やってることはCGIと同じなので、Perlでもなんでもいいのですが、PHPは言語
> 的にお気楽で、開発期間がかなり短くすむので気に入っています。
> #納期の短い仕事が多いので(^^;;;

ぼくは開発期間を短くするためにJavaを使ってます。
「Webサイト」ではなく「Webシステム」「Webアプリケーション」であればPHPで
はなくJavaを使うようにしてます。
結局データベースから取得したデータをテンプレートに流し込むだけなので、あ
まり深いJavaの知識は必要ないですし。
JavaならWebで必要になるようなものは、かなりのものが、標準かそれに近いか
たちで用意されてます。
というわけで、かなり楽ができるので。あとは言語としての安定度。

----
岸田 哉生(きしだ なおき)
	email:kishida @ fk.urban.ne.jp
	http://www.fk.urban.ne.jp/home/kishida/




pgsql-jp メーリングリストの案内