PofEAA 5th

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 別ノードで、あまり差異が無いのでは?
* (ある参加者が昔測定した結果)同一プロセス:別プロセス:別ノード = 1:?(ききそびれ・・・):数千、数万倍オーダー
* CORBAにおける、別プロセス:別ノードの比較 → 別プロセス:別ノード=1:10程度
* 考察: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@三宿へ。

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>