スキップしてメイン コンテンツに移動

第1回 Build Insider OFFLINE　に参加してきました

6/8（土）に第1回 Build Insider OFFLINEに参加してきた。

飲食の供給が無料という非常に太っ腹なセミナーだった。
もちろんセミナー自体も無料なのに太っ腹なセミナーだった。
次回もあるならまた必ず参加したいものだ。

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分かかる！？

■.NET最先端技術によるハイパフォーマンスウェブアプリケーション
  • ソーシャルゲームの規模感
    • 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が存在しない場合もあることが前提
  • メモれず
  • APIアクセス
    • HttpClinet
    • DefaultはThreadPoolは最初Core数分。
      ThreadPool.SetMinThreadで設定可能。
      Core数を超えると、あるアルゴリズムで増やすか待つか判断する。
      ただ結局IO待ちが多いので、
      必要と分かっているなら最初から増やしておいたほうがい。
  • 数字は常に見えるところに
    • 何がどの程度早いのか、遅いのか常に意識できるように
      • 肌間隔を養う
      • 環境の違いによって、ネットワークによってはRedisがDBより遅いとか出てしまう
  • NewRelic
    • パフォーマンス監視サービスツール
    • インストールも超簡単！
    • スローリクエスト時の完全なスタックトレースが見れる
    • インストールすると若干遅くなるが、それ以上の利益ある
  • 現在グラニではHiring中です！
以上です。
ラベル:

コメント

コメントを投稿

このブログの人気の投稿

間違ったフォーマットのプログラムじゃないんだけど

以下エラーに対し、 ファイルまたはアセンブリ 'SSPI'、またはその依存関係の 1 つが読み込めませんでした。間違ったフォーマットのプログラムを読み込もうとしました。 以下環境で対応した話です。 VisualStudio2012（C# ASP.NET MVC4.0） IIS7.5 とあるところのdllを使用中 ASP.NETをIISに発行しようとしたら、上記エラーが発生。 他のプロジェクトでは問題なく発行できているのに、 何かと思ってみたら、google先生に尋ねてみると、 DLLファイルの対象プラットフォーム（32bit／64bit）が異なる とのことでした。 このサイトでは対処方法として、 運用環境のプラットフォームに合わせ、適切なランタイムファイルを配布してください。 と記載されていますが、今回の私のようにとあるところのdllを使用している場合などは、 そうもいかない場合もあるでしょう。 そこでdllを変更できない場合には、 IISのアプリケーションプールの設定で、 32bitアプリケーションを有効化してあげることで対応できます。 以下手順です。 コントロールパネル　→　管理ツール　→　インターネット インフォメーション サービス (IIS) マネージャー　を起動します。 変更したいアプリケーションを右クリックして、詳細設定を選択します。 32ビットアプリケーションの有効化をTrueに変更します。 もう一度発行します。 ここまでです。 簡単だけど知らないとなかなかはまるかなって気がしますね。 独特のくせなのかもしれません。 そして、次なるエラー発生中です・・・。
コメントを投稿
続きを読む

SQLServer2008でのトランザクションログの切り捨て方

SQL Server 2008でとあるDBのトランザクションログが一杯に。 BACKUP LOG DatabaseName WITH TRUNCATE_ONLY を使ってトランケートしようとしたら、 'TRUNCATE_ONLY' はBACKUP オプションとして認識されません。 との冷たい返事。2008で廃止されていたのを忘れていた。 SQL Server 2008 で廃止されたデータベース エンジンの機能@MSDN そこでヌルデバイスを使用してバックアップを取得する方法で、切り捨てを試みる。 BACKUP LOG DatabaseName TO DISK = ‘nul’ GO するとまた冷たい返事。 現在、データベースのバックアップが存在しないので、BACKUP LOG を実行できません。 2008では過去にフルバックアップを取得しておかないと、ランザクションのバックアップが取得できないことを忘れてた。てなわけで、まずはデータベースのフルバックアップを取得して、 BACKUP DATABASE DatabaseName TO DISK = ‘nul’ GO もう一度トランザクションのバックアップをして、やっと切り捨てれた。最初から単純にしておけばよかった・・・。
2 件のコメント
続きを読む

並列化できない非同期の話

あるバッチ処理で顧客にメール送信する場面ありますよね。そんなとき、メール送信はメールサーバに投げ込むだけなんだから、投げ込むの非同期すりゃ早くなるんじゃないって思いませんでした？ 思いますよね？ そんなことを考えて、C# で SmtpClinet を使ったお話です。ちなみに結論的に非同期で早くなりません。 SmtpClient.SendAsync C# でメール送信するなら、SmtpCilent クラスってのがありますと。こいつが同期でメール送信する Send だけではなく、非同期でメール送信する SendAsync ってのを持っているわけですよ。 MSDN を参照すると、 指定した電子メール メッセージを、配信用 SMTP サーバーに送信します。 このメソッドは、呼び出し元のスレッドをブロックしません。また、呼び出し元は、操作の完了時に呼び出されるメソッドにオブジェクトを渡すことができます。 とのこと。非常に Good ですね！ 少しの背景と過大な期待 背景として、すでに動いているバッチが遅いって話になって、性能改善に取り組んでいました。現存しているバッチは Send で動作しています。 てことは、 SendAsync にするだけいいんじゃないの？それだけ非同期になるから早くなっちゃうんじゃないの？こんな期待感でいっぱいでした。 ところが 修正して実行すると想定以上の時間で完了しました。でもメールが飛んできません。。。よくよく見ると例外が。。。そしてよくよく MSDN を見ると、 SendAsync を呼び出した後、Send または SendAsync を使用して別の電子メール メッセージを送信する前に、電子メールの伝送が完了するまで待機する必要があります。 とのこと。 これって結局メール送信は非同期で並列になることことを許容していないってことだったんですね。 非同期と並列処理は別ですが、とは言え並列処理を許容していないとは。。。 結局 今回は Parallel.Foreach を使って、メール送信箇所は並列処理するように書き直しました。これもお手軽ですね。
コメントを投稿
続きを読む