6/8(土)に第1回 Build Insider OFFLINEに参加してきた。
飲食の供給が無料という非常に太っ腹なセミナーだった。
もちろんセミナー自体も無料なのに太っ腹なセミナーだった。
次回もあるならまた必ず参加したいものだ。
4つ参加してきた講演うち特によかった2つを、
以下箇条書きでそれぞれの講演のメモとか感想とかをつらつらと書きます。
■よりよい開発を目指すための、プロセス&ツール活用
※TFSはTFServerで、TFServiceはTeamFoundationServiceと記載しています。
飲食の供給が無料という非常に太っ腹なセミナーだった。
もちろんセミナー自体も無料なのに太っ腹なセミナーだった。
次回もあるならまた必ず参加したいものだ。
4つ参加してきた講演うち特によかった2つを、
以下箇条書きでそれぞれの講演のメモとか感想とかをつらつらと書きます。
■よりよい開発を目指すための、プロセス&ツール活用
※TFSはTFServerで、TFServiceはTeamFoundationServiceと記載しています。
- Kinectの本を何冊か出版されている中村薫さんのセミナー。
今日はKinectの話はでなかったが。
一度ご本人を拝ませて頂きと思っていたが、やっと拝見できました。
Blogはもとより、Kinectの本も非常に利用させて頂いております。 - セミナー内アンケート
- TFS知ってる → 9割
- TFS使ってる → 3割
- Scrum知らない → 2人
- TFServiceを知っている → 5割
- 結論
- 状況、環境によって、プロセスツールを使い分ける
- そのためにはプロセス、ツールの特徴を知る必要がある
- 使いこなせる武器を複数持つこと
- 道具の変化
- 今もTFS、github、Jenkinsを使っているとのこと
- TeamFoundatuionService
- バージョンコントロール
- 作業項目
- 自動ビルド環境
- テスト環境 → テストをサポートしているツールは少ないが、TFSなら可能
- 今年価格の発表がある、らしい
- 実は3週間に1回更新が入って、機能が増えている
- TeamFoundationServer2012
- pros
- 割愛
- cons
- 環境構築、運用が手間
- Windows環境以外のビルドは難しい
- リリースのイノベーション
- 例えばTeamFoundationServiceは3週間に1回リリースされている
- TFSだって、3か月に一回Updateされている
- どこだってやろうと思えばできるはずで、やらないといけない時代に来ている
- TFServiceではもう使えます
- 分散バージョン管理ができるようになった、らしい
- いずれTFSにも利用できる
- デモ
- 便利そう
- ビルド後にテストを実行とか
- チェックイン前にビルドして、成功したらチェックインとか
- ビルドに10分かかる!?
- ソーシャルゲームの規模感
- 1クリックごとにDBへの更新処理あり
- 5000リクエスト/sec
- デイリーで1億リクエスト
- 実はPHPで動いている!
- なぜC#
- PHP(CakePHP)が重い!
- PHPのリリースは楽なんだが、ビルドまでの道のりが長い
- あーだこーだでC#がいい
- AWSを利用した現在(PHP)の構成
- ES2でApache200台 → C#で何台に削減できるかだろうか?
- Memcashedはさようならの予定
- 基本構成
- WindowsServer2012
- AWSのWindowsServer
- IIS8+.NET Framework4.5
- RDS
- SQLServer?
- Redis
- インメモリ型KVS
- キャッシュ
- なぜリレーショナルデータベース
- NoSQLでいい?
- AzureTableとか無限スケールするし?
- 機能面は満たせるが・・・
- 水平分割が始まったら選ぶかもしれないが、少なくとも現状はRDBSで問題ない
- DB側の性能問題対策のための垂直分割
- 外部キーが付与できない制約などがあるため、C#でロジック組んで対応している
- HWが進化しているから、垂直分割のままでいけるんじゃないか
- MySQLのツール
- HeidiSQL
- 以外に便利
- JetProfiler
- SQLProfileの代わり、ないよりもいい程度だが、ないと苦しい
- C#からのDB取扱い事情
- EntityFrameworkなどの重量級O/Rマッパは不採用
- Micro-ORM
- Dapper
- DataRow => Objectへの変換だけを担うもの
- 性能比較
- HANDCODED 55(単位不明の処理時間)
- DAPPER 56(単位不明の処理時間)
- EF(COMPILED) 120(単位不明の処理時間)
- →EFは遅い。
HANDCODEDはプログラム記載量がネックになる。
というわけでDAPPERを選択。 - コネクションへの型付け
- 現状テーブルは300程度
- Redis
- オンメモリで動作するデータストア
- Key-Value以外にリスト・ハッシュ・ソート済みセットなどのデータ構造が使える
- RDBSと組み合わせないと厳しいが、RDBSを補うには最適
- 詳しくは C#のRedisライブラリ「BookSleeve」の利用法 参照
- パイプライン処理ってのもあって、これがなかなかC#と相性がいい
- シリアライズ
- protobuf-netを利用
- C++での性能比較では遅いって結果もあるが、C#との相性がいい
- 結局シリアライズ、デシリアライズのアルゴリズムに依存する
- BookSleeve
- 非同期
- 全てがbyte[]で返ってくるので、シリアライズする層を作っている
- 非同期的シチュエーション2
- Task.WhenAll
- 複数タスクをこの一行で待てる
- BookSleeveとの相性がいい
- 非同期でのはまりどころ
- TransactionScope内でawaitできない
- 別スレッドになるので、実行時例外となる
- 手動でBeginTransactionして回避・・・
- デッドロック
- .Eesult/Waitで取るとデッドロックする場合がある
- 全てasyncで通せばデッドロックしないけれど
- TransactionScope使いたいなら、その中で同期的に待つしかない
- フィルターが未対応なので、フィルター内で書く場合は待つしかない
- HttpContext.Currentが消滅する・・・
- これからのWeb開発ではContextCurrentが存在しない場合もあることが前提
- メモれず
- SQLとPallarel.Foreachについては 並列実行とSqlConnection を参照
- APIアクセス
- HttpClinet
- 他の講演でも出てきた
- 詳しくは HttpClient詳解、或いは非同期の落とし穴について を参照
- DefaultはThreadPoolは最初Core数分。
ThreadPool.SetMinThreadで設定可能。
Core数を超えると、あるアルゴリズムで増やすか待つか判断する。
ただ結局IO待ちが多いので、
必要と分かっているなら最初から増やしておいたほうがい。 - 数字は常に見えるところに
- 何がどの程度早いのか、遅いのか常に意識できるように
- 肌間隔を養う
- 環境の違いによって、ネットワークによってはRedisがDBより遅いとか出てしまう
- NewRelic
- パフォーマンス監視サービスツール
- インストールも超簡単!
- スローリクエスト時の完全なスタックトレースが見れる
- インストールすると若干遅くなるが、それ以上の利益ある
- 現在グラニではHiring中です!
コメント
コメントを投稿