PofEAA第五回読書会に参加してきた。
発表に関連した議論の内容を中心に、箇条書きでメモ。
セッションステート
レコードデータとサーバセッション
セッションステートをRDBに書き出したレコードはレコードデータではない。
publicかつpersistentなデータがレコードデータであると理解した。
文中の「データベースとサーバセッションの中間の位置」とは何か？
中間の位置ではなく、中間の特性（？）ということみたい。
「位置」なる訳は、かなりグレー。
セッションの特性に応じて、セッションアフィニティ(=スティッキー)にすべきか？セッションマイグレーション（セッションレプリケーション）すべきか？が変わってくると思われる。
具体的には・・・ セッションに格納するデータ量の大小、セッションの維持時間
セッションに格納するデータ量が多い場合→ アフィニティ?
セッションの維持時間短い場合→ アフィニティ?
（セッションアフィニティに関連して）ロードバランシングについて・・・
書籍では「クライアントIPアドレスによってロードバランシングする」なる記載があるが、SSLのキーでロードバランシングできるものもある。暗号化の影響を受けず、かつ、決め細やかなロード バランシングが実現できる。
書籍では、「クライアントIPアドレスによるロードバラシンシングが機能しにくい」例として、Proxyサーバを介したアクセスとなるAOLが上げられている。が、日本の場合、Docomoが問題となりやすい。
DOCOMO携帯からのアクセスの場合、リクエストのたびにIPアドレスが変化するので、IPアドレスでロードバランシングすることは問題。サブネット単位で行う必要が有るようだ。
Session Stateとパフォーマンス
ステートの格納先をServerとするか？DBとするか？の選択基準としては、パフォーマンスよりリソースの観点が重要なのでは？
ちなみに、「パフォーマンス」のファウラー流定義は、邦訳 P6あたりにある。
PHPにはセッション情報をインメモリに持つ手段が無い。
スクリプト起動のモデルがCGI的である故
デフォルトで、セッション情報はファイルに格納する
RDBMSのテーブル(永続化ストレージ or インメモリ）に格納することもできる。
Rails
セッションID?セッションステート?の保存先としてメモリ、DB、ファイルが選択可能
フレームワークレベルでのクラスタリングの考慮は特に無い。
用語「MySQLセッションステート」
PHPな人はステート情報でもなんでもMySQLに格納するに格納する様をさした言葉みたい。データの特性に応じてインメモリテーブル、ディスク上のテーブルなどを使い分ける。
上記に関連して・・・、 はてなのMySQL使用方法
検索用DBサーバ、INSERT用DBサーバが別
DBフォレスト前段にキャッシュサーバが大量に・・・
最近は、サーバアフィニティで設計するケースが多いかも。
サーバはめったに壊れないし。
AJAXならば、サーバ側で状態を保持しなくてもOK(らしい。WR：よく理解できず・・・)
ただし、システム全体をAJAXだけで構築することは一般的でないため、結局、サーバ側でもログイン情報を持つことになる。
典型的な事例：ファイルのダウンロード（サーブレットなどを用いて実装するのが一般的）
分散ストラテジー
パフォーマンス比較
別プロセス vs 別ノードで、あまり差異が無いのでは？
（ある参加者が昔測定した結果）同一プロセス：別プロセス：別ノード ＝ １：？（ききそびれ・・・）：数千、数万倍オーダー
CORBAにおける、別プロセス：別ノードの比較 → 別プロセス：別ノード＝１：１０程度
考察：OSがループバック通信の最適化がしている可能性がある。
UNIXドメインを使うともっと速い（Solaris2.4 では、共有メモリで実装している。速いことが期待できる）
また、Windowsの場合、同一ノード内別プロセス通信 → Local RPC で通信 ⇒速い！
EJB1.4とWebサービス
コーディングレスでWebサービス化可能
発刊時点ではEJB1.4は存在しない。
CORBAにも類似の仕組み(IIOP over HTTP)が存在するが、Webサービスというわけではない。over HTTPなだけ。
XML Webサービスのパフォーマンス
RPCに比べると2,3桁違う
Apache XML-RPCと比較してもWebサービスは1,2桁遅い
やっぱりRMIは圧倒的に速い
理由のひとつ：ソケットのキープアライブをする。 これだけでも5倍ぐらい差が出るはず。
DTO:ローカルとリモートの2つあることに注意！
ファウラーは、リモートDTOのみをDTOと読んでいるかも。（狭義の/J2EEパターンの文脈におけるDTO？）
オンライン型バッチ処理
書籍所有者は2名だけ。orz. ま、しょうがないか。
30分弱で10スライド進んだ。
あと33スライド(笑)
APPサーバ～DBサーバ間NWラウンドトリップ回数削減のtips
SQLステートメントのセミコロンつなぎ
JDBC batchUpdate
(ひがさんのコメントの内容を忘れた・・・）
一旦リストアしてリラン pattern
いったんリストアしてリランなんて、60’sのテクニックだぜ！
単にリランしても無駄なケースが多いのでは？
バッチ失敗の原因はデータ不備。よって、投入データorマスタデータの修正後にリランするのが常套手段と思われる。
とすると、夜間張り付いている人が必要だよね？
バッチリランのため、外部からログイン可能/状態チェック可能な経路/手段を設けておいたケースあり
ミニバッチ pattern
読み取り一貫性問題： みんなあまりピンと来てないみたいなので、次回もうすこしブレークダウンして・・・
ミニバッチの並列実行： 並列実行を想定して物理設計しないと（Oracleパーティション&ディスク構成とか？）。無闇に並列化してもNG
そもそも、オンライン型バッチの必要性って？
システムの全サービスをインサービス状態のままでバッチを実行するのではなく、バッチ実行が影響する特定のサービスをアウトオブサービス状態とするのが一般的では？
システム要件的に許されるならば、それが（コスト的に）一番かも。
「エンタープライズシステムはバッチでしょう！」ということなので、次回も地味に頑張ります。
その他
この人数になってしまうと、さすがにハンドル名と顔を一致させるのはムリ。
名札の導入に期待！
懇親会は1hほどで退散 ⇒ 友人のLive@三宿へ。
July 31st, 2005 | Category: Event, Programming | Leave a comment
