無聊を託つ

プロパティのバインドに失敗するときのエラーメッセージをカスタム

noreply@blogger.com (たけはら) — Sun, 12 Feb 2012 10:53:00 +0000

stackoverflow.com。今でもたまに書き込んでます。

c# - Regular Expression stop crashing - Stack Overflow

随分前にも似たようなガッカリ感を味わったんだけど、今回もまた似たような気分を味わってます。とはいえ、質問の真意を履き違えての結果の可能性は否めない。

この質問、必須項目にしたDateTime型のプロパティへのバインドに失敗するから、正規表現でチェックしたんだけど、”0000/00/00 00:00:00”って入力するとエラーになるんだよね。なんで？って言う感じでしょーか。

質問者のモデルを見るとPostedは必須項目。DateTimeには有効な日時しか入れられないっていう条件をあわせて考えると、不正な文字列の時にエラーメッセージを表示できれば要件は満たす。かな。正規表現がどうのこうのっていう問題解決の仕方ではなく、プロパティにセット出来なかった時のエラーメッセージがカスタム出来ればいいかもね、と思ったんですねー。

private static string GetValueInvalidResource(ControllerContext controllerContext) {
	return GetUserResourceString(controllerContext, "PropertyValueInvalid") ?? MvcResources.DefaultModelBinder_ValueInvalid;
}

private static string GetValueRequiredResource(ControllerContext controllerContext) {
	return GetUserResourceString(controllerContext, "PropertyValueRequired") ?? MvcResources.DefaultModelBinder_ValueRequired;
}

↑このようにMVCのDefaultModelBinderではそんな時のエラーメッセージをプロパティ”個別”にカスタムはできません。どんなプロパティにも共通のメッセージ。

で考えた結果、投稿したコードが↓これ。

public class CustomModelBinder : DefaultModelBinder
{
  protected override void SetProperty(ControllerContext controllerContext, ModelBindingContext bindingContext, System.ComponentModel.PropertyDescriptor propertyDescriptor, object value)
  {
    base.SetProperty(controllerContext, bindingContext, propertyDescriptor, value);

    var propertyMetadata = bindingContext.PropertyMetadata[propertyDescriptor.Name];
    var invalidMessage = propertyMetadata.AdditionalValues.ContainsKey("PropertyValueInvalid")
                 ? (string)propertyMetadata.AdditionalValues["PropertyValueInvalid"]
                 : string.Empty;
    if (string.IsNullOrEmpty(invalidMessage))
    {
      return;
    }

    // code from DefaultModelBinder
    string fullPropertyKey = CreateSubPropertyName(bindingContext.ModelName, propertyDescriptor.Name);
    if (!bindingContext.ValueProvider.ContainsPrefix(fullPropertyKey))
    {
      return;
    }
    ModelState modelState = bindingContext.ModelState[fullPropertyKey];
    foreach (ModelError error in modelState.Errors.Where(err => String.IsNullOrEmpty(err.ErrorMessage) && err.Exception != null).ToList())
    {
      for (Exception exception = error.Exception; exception != null; exception = exception.InnerException)
      {
        if (exception is FormatException)
        {
          string displayName = propertyMetadata.GetDisplayName();
          string errorMessageTemplate = invalidMessage;
          string errorMessage = String.Format(CultureInfo.CurrentCulture, errorMessageTemplate,
                            modelState.Value.AttemptedValue, displayName);
          modelState.Errors.Remove(error);
          modelState.Errors.Add(errorMessage);
          break;
        }
      }
    }
  }
}

これを利用するためにモデル定義を以下のように変えてしまいましょう。

[Required]
[AdditionalMetadata(
 "PropertyValueInvalid",
 "Wrong Syntax Entered, Needed:day/Month/Year Hour:Minutes:Seconds")]
public DateTime? Posted { get; set; }

AdditionalMetadataにカスタムメッセージを指定して、プロパティのバインドがエラーになったらそのメッセージを表示する。素敵だと思うんだけどなー。

で、コメントが「this code is like giving a baby a gun」。ぎゃふん。

効率のいいリクエスト処理

noreply@blogger.com (たけはら) — Sat, 28 Jan 2012 15:55:00 +0000

Webサイトの運用、大変ですよね。お疲れ様デスよ。まったく。

普通にネットワーク構成するとハードウェアロードバランサの下にWebサーバー並べて負荷分散する感じになるでしょう。処理が追いつかなかったらWebサーバー追加だぜ！とか、富豪富豪。ふぇっふぇっふぇ。でも、そんな富豪ばかりじゃない。

Application Request Routing | IIS 拡張機能 | TechNet

略してARR。NLBみたいにネットワークの負荷分散じゃなくてHTTPでのリクエスト負荷分散。ソフトウェアLB。

ARRが単なるリバースプロキシだと思ったら大間違いでした。この子かなり優秀。

そもそも、SSLオフロードさせようと思って、パフォーマンステストをしてたんですけど、思いの外Request / Secが高くなる。変だなーと思って、HTTPSじゃなくてHTTPでも試してみたら、それでもRequest / Secが高い。なんで！？と思いパフォーマンスモニターでいろいろ見てたら、どーもノードサーバーの処理が重い時にはARRがリクエストのルーティングをちょっと保留してるくさい。レスポンスタイムを見て、重くなってきたのかどーかを判断してるのかなー。それ以外に指標がないと思うので、そーじゃないかという予想。

VS のロードテスト(今はまだUltimate使えるからね)でチェックしてみました。１０～２５０ユーザーまで徐々に増やしていく設定でWebアプリケーションの動きをシミュレートさせる。下のグラフはパフォーマンスモニタ。

黄色がCPU、青がWeb Service：Current Connections、緑がW3SVC_W3WP：Request / Sec、赤がASP.NET v2.0：Request Queued。

まずは、ARRを通さずに直接リクエストした状態です。CPUは概ねフルに使いつつ、コネクション数が段階的に増え、リクエストキューに処理待ちリクエストが溜まっていく様子です。直感的にそーなるなー、っていう動きがそのまま再現できてますね。

どんどん負荷を上げる(ユーザー数を増やす)と、キューにたまる数が増えて、グラフ上Request / Secを上回ります。これはつまり同時処理性能を超えたリクエストがWebアプリケーションサーバーに来てるっていう状態ですね。さばけないからキューイング。ASP.NETのキューイング。

最終的にすべて終了すると↓こうなって、何もかも0に戻る。

ロードテスト結果。

Request / Secが281でページ/秒の平均が26.0です。

今度は全く同じ事をARR経由させて実行します。

この段階ですでに挙動が違うんですよね。下のグラフはWebアプリケーションサーバーの状態なんですけど、コネクション数の増え方が違う。段階的なんだけど、伸びかたが明らかに違う。この時のARRの同じグラフを見てみるとどーなってるか。

なるほどね。こっちにはユーザー数と同じ増え幅でコネクション数が増えてます。

ARRからノードサーバー(Webアプリケーションサーバー)へはTCP接続を使いまわしてる？コネクションプーリング。

ユーザー数をどんどん増やしていくと、リクエストキューにたまるのが直接接続時の挙動でしたが、ARRを経由した場合、キュー(赤)がたまるのに合わせてコネクション数(青)が増えてる。関連があるような挙動ですね。

で、観測を続けると、キューの数が減少に転じてます。不思議ですね。ユーザー数は同じでリクエスト数も同じように発生してるのに、Webアプリケーションサーバーではキューがたまりません。

その時のロードテストの状態。

Request / Secは298で落ちてない。若干上がってるくらい。

最終的にテスト実行完了時点でCPUやRequest/Sec、キューの数は0に落ちるのに、コネクション数(青)はまだ0にならない。しばらく高止まり。これはつまりARRがコネクションをすぐに切ってないということですね。

Request / Secが347でページ/秒の平均が32.4.0。ページの応答時間平均にいたっては6.45から4.20ですよ！約1.5倍。これはどういうことなのかというと、Webアプリケーションサーバーの同時処理性能が下がるようなリクエストをルーティングせず、しばらくARRでキューイングしておくことで、Webアプリケーションサーバーがベストパフォーマンスを出せるように調整してるから、じゃないでしょうか。実際にWebアプリケーションサーバーのキューの数はARRを経由させたほうが少ない状態を維持し、コネクション数も少ない。何度か試した結果コネクション数が半分の時もあるのに、ページの応答時間平均は常に概ね1.5倍早い。

無理に同時実行させないことで早くレスポンスを返す。結果的にRequest/Secも上がる。SSLオフロードでWebアプリケーションサーバーのCPU利用を実処理に専念させようとしただけなのに、この結果。恐るべしARR！

ちなみにARRとWebアプリケーションサーバーが同居した場合にはまるで性能向上しませんでした。してもいいかと思ったんだけど、そういう訳でもないんですね。IISとASP.NETの双方でのCPU利用(ネットワークも思いのほかCPU利用するのかもね)を最適化するならARRは別サーバーで用意しましょう。

ARR賢い。単なるリバースプロキシじゃない。ノードサーバーはIISに限定するものじゃないので、性能判断の指標はレスポンスタイムしか無いと思うけど、その辺の情報は見つけることが出来ませんでした。

今回はARR1台、ノードサーバー(Webアプリケーションサーバー)1台なので、こういう結果でしたが、ノードサーバーの台数が増えた場合にはどのように効率化されるのかは、環境次第だと思うので、自身の環境で試してみたらどーでしょー。

もし、仮に同じような性能向上をするならWebアプリケーションサーバーが4台以上ある場合、1台をARRにしたほうがレスポンス性能がいいということになるかもよー。

目指せ、続ハイパフォーマンスWebサイト！

HttpBench on GitHub

noreply@blogger.com (たけはら) — Mon, 02 Jan 2012 10:29:00 +0000

年明け早々です！お正月生まれのツール。

HttpBench – GitHub

ApacheBenchにはいつもお世話になってます。でも、同じようにHTTPSも計測したいです。absめ！

localhostに対してab –n 100 –c 10 http://localhost/

localhostに対してhb –n 100 –c 10 http://localhost

それっぽいー。けど、手抜きすぎー。

せっかくなのでIIS ExpressでHTTPSへのリクエストを確認。

左がHTTPで右がHTTPS(IIS Expressの勝手証明書)。ab(abs)だとうまくできないですよね。

abだと、すごくたくさんオプション指定できるし、計測も細かい。流石です。が、hbはまだ全然。とりあえず実行回数/コンカレント数/BASIC認証、HTTP GETだけ。

あ。バイナリ配布ってどうしよ．．．。いつかすると思う。今はそんな段階でもないからいいよね。

コンカレントをMaxDegreeOfParallelismじゃなくて、Threadを作って処理してます。普通にTaskでもよかったのかなー。

↑-c 200指定。

目指せハイパフォーマンスWebサイト！

MongoDBでお気楽MapReduce

noreply@blogger.com (たけはら) — Sat, 31 Dec 2011 10:47:00 +0000

MongoDBにはMapReduceの仕組みが用意されてて楽しそうですよね。

MapReduce - Docs-Japanese - 10gen Confluence

ちゃんと日本語。

で、コンソールで入力しながらの開発は面倒なので、こんな時はMongo VUE。安くならないかなー。

Yet another MongoDB Map Reduce tutorial | MongoVUE

使い方、これじゃよく分からない。

How to perform MapReduce operations in MongoVUE | MongoVUE

こっちですね！この手順どおりに実行すれば、ちゃんとMapReduce！Sharding環境ならそれぞれのShardで分散処理してくれます。

せっかくなので、以前作ったMongoTraceListnerのサンプルを利用して、各URLの処理時間の平均をMapReduceで計算してみます。

public class PerformanceTraceModule : IHttpModule
{
  private string ItemKey = "_mongoDbTraceStart";

  public PerformanceTraceModule()
  {
  }

  public void Init(HttpApplication context)
  {
      context.BeginRequest += new EventHandler(context_BeginRequest);
      context.EndRequest += new EventHandler(context_EndRequest);
  }

  void context_BeginRequest(object sender, EventArgs e)
  {
      var httpContext = (sender as HttpApplication).Context;
      var startTime = httpContext.Items[ItemKey] = DateTime.Now;
  }

  void context_EndRequest(object sender, EventArgs e)
  {
      var httpContext = (sender as HttpApplication).Context;
      var startTime = (DateTime)httpContext.Items[ItemKey];

      Trace.WriteLine(new
      {
          Method = httpContext.Request.HttpMethod,
          Status = httpContext.Response.StatusCode,
          RawUrl = httpContext.Request.Url.ToString(),
          Milliseconds = (DateTime.Now - startTime).Milliseconds
      });
  }

  public void Dispose()
  {
  }
}

このHttpModuleを仕掛けて処理時間をMongoDBに入れます。

実行！何度も何度もリロードやら、About、Loginへのアクセスを繰り返す。

データも溜まって来ました。

ここで、MapReduceを実行。

Map

Reduce

Finalize

In & Out

結果

ただ、ここでmap/reduce/finalizeのコードに間違いがあっても、わかりにくい。どこのなにがエラーなのかサッパリ。そんな時はコンソールを見てみましょう。サービス化してたらログファイル。

finalizeで適当にエラーコードを入れて実行するとコンソールにエラーメッセージが出てます。開発中はMongoDB Shellでやるか、ローカル実行してコンソール確認しながらすすめるのがいいかもー。

Mongo VUEやShellで見るだけじゃなくて、ASP.NET MVCのアプリケーションから見れるようにするために、以下のようにしてみました。

private MongoDatabase GetDatabase()
{
  var serverName = ConfigurationManager.AppSettings["MongoDb:Server"];
  var databaseName = ConfigurationManager.AppSettings["MongoDb:Database"];

  if (string.IsNullOrEmpty(serverName))
      serverName = "mongodb://localhost";

  if (string.IsNullOrEmpty(databaseName))
      databaseName = "TraceListner";

  var server = MongoServer.Create(serverName);
  return server.GetDatabase(databaseName);
}

private BsonJavaScript GetMapReduceCode(string name)
{
  return new BsonJavaScript(System.IO.File.ReadAllText(Server.MapPath("~/MapReduce/" + name)));
}

public ActionResult MapReduce()
{
  var map = GetMapReduceCode("map.js");
  var reduce = GetMapReduceCode("reduce.js");
  var finalize = GetMapReduceCode("finalize.js");

  var collection = GetDatabase().GetCollection("MyTrace");
  var options = new MapReduceOptionsBuilder();
  options.SetFinalize(finalize);
  options.SetSortOrder("_id");
  options.SetOutput(MapReduceOutput.Inline);

  var result = from r in collection.MapReduce(map, reduce, options).GetResults()
               select new
               {
                  RawUrl = (string)r["_id"],
                  Count = r["value"].AsBsonDocument["Count"].ToInt32(),
                  Elapsed = r["value"].AsBsonDocument["Elapsed"].ToInt32(),
                  Average = r["value"].AsBsonDocument["Average"].ToDouble()
               };
  return Json(result.ToArray().OrderByDescending(mr=>mr.Average), JsonRequestBehavior.AllowGet);
}

HomeControllerに追加。

やったー。出たー。あとは、見た目よろしくしていけばOKでしょう。今回は気にしないけど。

こんな感じでMongoDBにデータ入れとけばMapReduceで集計をMongoDBサーバーに任せられていいですね！

っていう、結論じゃなくて、結局はV8でスクリプト動かしてるから、大量のデータの場合そんなに早くなかったりしてショック。対象データをすべてフェッチしてC#で処理したほうが早かったりも．．．。

速度的には思ったほどじゃないけど、これはこれで面白いので、PowerPivotとあわせて業務系の人が扱えるようになると、嬉しいですよねー。

URLRewrite＋CloudFrontでパフォーマンスを取り戻す

noreply@blogger.com (たけはら) — Fri, 30 Dec 2011 16:25:00 +0000

年末ですね。年末だからこそ大量のアクセスが発生することもありますね。コンシューマー向けのものだと、平時に比べれば多かったりしますよね。爆発的なアクセスになることもありましょう。おめーさん、容赦無いね！

特にHTTPS。コレはもうホントしんどいですよね。SSLアクセラレータとかSSLオフロードっていうか、そういう前段でさばくように構成して、実処理はHTTPのみにしとかないとHTTPSの処理に尋常じゃないCPU使用率を持っていかれたりしちゃいましょう。そーなると、本来の処理にCPUが割り当てられない。SSLハンドシェーク。悪魔のようです。でも、そんな構成すぐに取れない！そんな時の選択肢としてCDN。え？なんで？だってアクセスの総量が減ればその分処理量も減じゃない！コードチューニングより効果が高いこともあります。パフォーマンス20％アップのコードチューニングより200％アップ(することもある)のCDN。

お手軽なのはAmazon CloudFront。

カスタムオリジンで既存サーバーをそのまま利用することで、オリジンサーバーにコンテンツを事前にアップロードしなくてもいい
URLRewrite2.0から導入されてるOutboundRulesでのHTML書き換えで、CDNを指すようにしてしまうことで、レンダリングコードに(ほとんど)手を加えずにCDNが使えるようになる
CNAMEでカスタムドメインでもそれなりに(HTTPSのカスタムドメインはダメだけど)
コンテンツへのHTTPSアクセス負荷をCloudFrontに肩代わりさせれる(コレ！！)
使ったぶんだけ課金は、いまさらですけどやっぱり素敵ポイント

もちろんIISね。Apacheもなんか書き換えありましたよね。mod_ext_filter？IIS以外はよく知らないです。

ココはひとつ、mvcPhotos(覚えてますか？)に実験台として登場してもらいましょう。

http://mvcphotos.takepara.com

まだ見れる状態になったままでした。そろそろ閉鎖しないと．．．。

http://mvcphotos.codeplex.com/

CloudFrontの登録とか、そういうのはいろんな人が書いてるので、その辺は省略。

こんな感じですね。コレといって何のへんてつもない設定。カスタムオリジンとProtocol PolicyをHttp Only、CNAMEでカスタムドメイン(HTTPSの時は割り当てられたドメインをそのまま使う)。

あとは、Web.configにoutboundRulesを追加(ExpressWebでURLRewrite使えると書かれてるけど、バージョンが見当たらなかったから不安だったけど、ちゃんと2.0以降が入ってる模様)。

    <rewrite>
      <outboundRules>
        <rule name="CloudFrontContents" preCondition="html" enabled="true">
          <match filterByTags="A,Img" pattern="^/Photos/Image/(.*)"/>
          <action type="Rewrite" value="//cdn.mvcphotos.takepara.com/Photos/Image/{R:1}"/>
        </rule>
        <preConditions>
          <preCondition name="html">
            <add input="{RESPONSE_CONTENT_TYPE}" pattern="text/html"/>
            <add input="{REQUEST_URI}" pattern="/mobile" negate="true"/>
          </preCondition>
        </preConditions>
      </outboundRules>
    </rewrite>

これだけ。これで、/mobile以外の時に/Photos/Imageへのアクセス(a hrefとimg src)すべてCDNへ変更します(詳しくはCreating Outbound Rules for URL Rewrite Module : URL Rewrite Module 2 : URL Rewrite Module : The Official Microsoft IIS Site )。/mobileを除外してるのには理由があります。mvcPhotosはHTTPSでのアクセスが無いので意味ないんですが、実際は有りましょう。その際、ケータイからのアクセスだとCloudFrontで使ってるワイルドカード証明書が残念なコトになります。まだまだ正常に処理できないですよね。

なので、もともと素材の少ないケータイアクセスの場合(/mobile配下へのアクセス)は、CDNを利用しないようにして、コレまで通りのアクセスにしときます。PCやスマフォでのHTTPアクセスなら処理が負担にならない、って言う場合はconditionsを以下のように追加してHTTPSの時だけCDN参照するようにするのがいいでしょう。

        <rule name="CloudFrontContents" preCondition="html" enabled="true">
          <match filterByTags="A,Img" pattern="^/Photos/Image/(.*)"/>
          <action type="Rewrite" value="//cdn.mvcphotos.takepara.com/Photos/Image/{R:1}"/>
          <conditions>
            <add input="{HTTPS}" pattern="^on$"/>
          </conditions>
        </rule>

ただ今回、mvcPhotosのちょっと残念だったところと、Cloud Frontの制限が丁度マッチして、ちょびっとだけViewとスクリプトの変更がありました。

画像を返す部分をPhotosControllerにやらせてるんですが、そのパラメータをRoutingじゃなくてQueryStringで渡してたんです。が、Cloud FrontはQueryString無視します。なので、そこだけ変更してQueryStringでのサイズと変換方法の指定をRoutingパラメータにしました。

/Photos/Image/1?size=100&type=fit

↑こうだったものを↓こう。

/Photos/Image/1/100/fit

そのためにRoute登録。

    routes.MapRoute(
        "PhotoImage",
        "Photos/Image/{id}/{size}/{type}",
        new {controller = "Photos", action = "Image"});

コードいじってるじゃん！さーせん。でも、普通はいじる必要ないはず。あっても、ViewやScriptだけで済むはずです。サービスとして公開するならURLの設計もちゃんとするはずなので。今回の微調整もRouting以外はViewだけ。View内にknockoutで使うHtml Template埋め込んでるし、パス関連は全てそのテンプレートに展開してるから、OutboundRulesの対象になる。

これで、mvcPhotosにアクセスしてみましょう。

クリックして拡大すると見えると思いますが、/Photos/Image配下はCDNへ。その他の要求(JavaScript/CSS/Ajax)は自サーバーに行ってますね。もちろんホントはJavaScriptやCSSも持っていくのがいいでしょう。

↑こちらは/mobile配下。今度は同じ/Photos/Image配下のものもCDNに行かず、自サーバー参照のままです。

なんてお手軽。

実際HTTPSを利用してるサイトでBLOBコンテンツのダウンロードが大量に発生している場合、この方法でサーバーへのコネクションを１／１０とかに抑えられることになって、ウハウハ。もちろんお金はかかりますけど。それでもサーバー増強やSSLアクセラレーションする機器の購入に比べれば、安いし経費で落とせます！HTTPSでのカスタムドメインが使えないのは気に入らない、って言うことがあるなら他の方法をとってくださいってことになります(ARRでSSLオフロードとかね、お金貰えればなんでもいいでしょう)。

とりあえず、今回のような方法でCDNを利用する時に、こういうふうにページ(View部)作るといいかもと、思ったことを書きだしておきます。

素材を意味ごとに決まったフォルダに分けておく
→ パターンを増やすとその分の処理にCPU使っちゃう
スクリプトでスクリプトをロードしないほうがいいかも
→ スクリプト内のパスを書き換えるのが面倒
スクリプト内に極力パスを書かない
→ HTMLの属性を使う。DOMにデータを持たせとく。か、クライアントサイドのHTML Templateで。
同じくCSSの中でimportしないほうがいいかも
→ 相対パスなら許容可能
HTML内のsrc/hrefはルートからの絶対パスで書いておく
→ 相対パスだとパターンがぶれるし、思わぬ参照先に。どうしても相対ならCSSにする
HTML内でスタイル指定しない
→ パスの書き換え問題。同じ理由でタグ要素にstyle属性も困る。

トリッキーなことしないで、メンテナンス性を考慮したページの作り方をしてれば、CDNへの振り向けはすんなり行きやすいという感じですね。

目指せ Ultra-Fast ASP.NET！

新しい.NET PaaS

noreply@blogger.com (たけはら) — Tue, 27 Dec 2011 11:03:00 +0000

Iron Foundryっていうのがあるらしいですね。Tier 3っていうIaaSの会社が、Cloud Foundry(vmware発のオープンソースPaaSフレームワーク)を利用して、.NET PaaSを自社クラウド上のサービスとして提供。

Tier 3 Contributes .NET Framework Support for Cloud Foundry™ Platform as a Service to the Open Source Community « Tier 3 Company Blog

InfoQ: Tier 3がCloud Foundryで.NET Frameworkをサポート

この記事を見るまで、Cloud Foundryを全然しらなかったっす。面白いですね。IaaSのレイヤに依存しないPaaSフレームワーク。

なるほどー。面白そうついでにどんなものなのか、ちょびっとだけ触ってみました。触っただけなので中身はないです。具体的に知りたい(Cloud Foundryそのもの)場合は、ソースを見るといいかもね！

IronFoundry's Profile – GitHub

いろいろ試してたんですけどね、勝手が分からないっていうのもあるかもしれないけど、とにかく情報がNai！どーなんよ！

まずはIronFoundryのサイトからCloud Foundry ExplorerとVS2010用のVisual Studio Extensionをダウンロードしてインストール。

Sign upしてもSign inページもなくて「どーこー」。まぁね、サイトにサインインする場所なんか無いわけです。すべてツール経由。

手順はコミュニティサイトに書かれてるのでその通りにどーぞ。

Using the Cloud Foundry Explorer for Windows : Iron Foundry

ちなみに単体起動したCloud Foundry ExplorerとVS起動したものとで、プロファイルが共有されてないっぽい。ので、試すときはVSからの起動だけにしてしまいましょう。入力が2度手間。

んで、何より初期選択肢にIronFoundryのURLが登録されてない！(api.gofoundry.net)ので、そこから自分で登録。凄いね！さすが出たばっかり。その辺はご愛嬌。

試しに起動したサイトは↓こちら。

たけはらの国

分かりやすくServerVariables全部書き出しときました。

どういう設定になってるかというと↓こんなです。

クリックして拡大してね。

右下がインスタンス。メモリ512MBのインスタンス４つ起動しました。なんでかというと、アカウントに2048MBシバリがあるから。それ以上のメモリを必要とするインスタンスは起動できなかったです。LOCAL_ADDRの値がInstanceのHostアドレスと同じものが繰り返し表示されることが確認できるのできちんと４つのインスタンスに振り分けられてるのがわかります。

メモリは↑この中から選択して起動できました。インスタンスの合計が2048MBを超えなければいいので、インスタンス毎にメモリ容量が違っても起動できます。なるほどね。これって、どういうことですかね。AppDomainのメモリ上限指定なんでしょうか。超えるとリサイクルされるアレ。それともWeb.configに指定してるのかな？と思って、ちゃんとWeb.configがどういうふうになってしまうのか(変更されるはず)を見るためのページも用意。

どこまで隠したほうがいいのかよく分からないから、一応それっぽいところはモザイク。各自で確認してみてね！

DBがSQLServer認証だから、ConnectionStringにuidとpwdが埋まったものが自動追加されてて、AppSettingsにイロイロ追加されます。AppSettingsの値を見て挙動を制御するといいようですが。なるほど。でも項目の意味がわかりません！

えと、パッと見、Web.configにはメモリ制限らしきものは無いですね。VM自体に割り当てるメモリ量なのかなー。それにしては起動がめちゃめちゃ早いのが気になる。その辺Cloud Foundryに詳しい人なら知ってるのかな。まぁ、いいや。

VCAP_SERVICES/VMC_SERVICESそれぞれの値の中にplan:freeっていうのが見えます。無料お試しアカウント！

最初のスクリーンショットの真ん中したが各種サービスの登録で、選択できるのはMSSQLとMongoDB。

でも、MongoDBはエラーになって作れませんでした。んじゃ、MSSQLは？と思ってどんどこ作って行ったら10個までは何も言われずに作成できちゃいましたよ。どこまで作れるんだろ。怖くなって10個でやめちゃった。実際には、ServicesのアイテムをドラッグしてApplication Servicesにドロップして初めて利用可能になるみたい。なので、そういうふうにしたら、Web.configに"Default"って言う名前で接続文字列が追加されました。ココはまだちょっと不具合があるみたい。なんかちゃんと生成した文字列が追加されてる気がしない。DBの容量がいくらに制限されてるのかの情報も見つけられない．．．。すげーぜ！

ソースを確認してみると、ちゃんとサービスのクレデンシャルからInitial Catalogを指定するようになってたり、すでに"Default"って言う名前のものがあったら、そこに追加する(SqlConnectionStringBuilderを使ってる)ようになってるんだけど、そういう動きをしてくれない。

しょうがないので、接続文字列は自分で追加しておきました。追加される接続文字列を参考にDefaultConnectionっていう名前でね。なんか、VSからのデプロイ時に確定させたらPaaSのメリットが～、とは思うけど、いつかきっとちゃんと動くようになるはずだから、今はこれでもいいかな。ちなみにVSの発行機能とは別の機能(Cloud Foundryの機能)でデプロイされるから、Web.configの構成変更が全然動いてくれない。これもまた残念。ソースがあるんだからカスタムしちゃえばいいかもしれないけどね。試したいだけだからスルー。

で、結局Initial Catalogが分からないので、SQL実行ページを用意して、SQLServerに問い合わせ(Universal ProviderがInitial Catalog必須。デフォルトデータベースに指定があってもダメなんす)。

なるほどね。そんな文字列なのか。ん？これってVCAP_SERVICESのcredentialsのnameの値。なるほど。ソースは正しくかかれてるんだね。ちゃんと生成してくれればいいのに。

後は、MachinKeyをちゃんとWeb.configに書きたして、晴れてログインまで動くようになりました。Sessionは．．．。まぁ、いいや。

Web.configの表示とSQL実行のコード

[Authorize(Users = "許可したいアカウント")]
public class SecretController : Controller
{
  public ActionResult Config()
  {
    var config = XDocument.Load(Server.MapPath("~/web.config"));

    return View(config);
  }

  public ActionResult Database()
  {
    var connectionString = ConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString;
    ViewBag.ConnectionString = connectionString;

    return View();
  }

  [HttpPost]
  public ActionResult Database(string sql)
  {
    if (string.IsNullOrWhiteSpace(sql))
      return View();

    var response = new StringBuilder();
    var connectionString = ConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString;
    ViewBag.ConnectionString = connectionString;

    using (var connection = new SqlConnection(connectionString))
    using (var command = new SqlCommand(sql, connection))
    {
      connection.Open();

      var reader = command.ExecuteReader();
      var table = new DataTable("result");
      table.Load(reader);

      var writer = new StringWriter(response);
      table.WriteXml(writer);
    }
    ViewBag.Database = response.ToString();
    return View();
  }
}

雑．．．。どんまい。

ConfigのView

@model System.Xml.Linq.XDocument

@{
    ViewBag.Title = "Config";
}

<h2>Config</h2>
<pre>
@Model.ToString()
</pre>

DatabaseのView

@{
    ViewBag.Title = "Database";
}

<h2>Database</h2>
ConnectionString: @ViewBag.ConnectionString
<h3>SQL</h3>
@using (Html.BeginForm())
{
    @Html.TextArea("sql",new{cols=80,rows=10})
    <button type="submit">実行</button>
}
<h3>Result</h3>
<pre>
@ViewBag.Database
</pre>

Iron Foundry自体ソースが公開されてるから、Tier 3じゃなくても自分で環境作って(SQLServer最新にしてMongoDBも最新にして、とか待たなくても自分で用意すれば解決するし)、実行環境にすることもできるので、コレはコレで面白い選択肢。知っといて損はなさそーですね。今後にも期待できそうだし！

追記

追跡調査の結果、メモリ制限はリサイクルのプライベートメモリ制限でした！

MongoDBを本格利用するために

noreply@blogger.com (たけはら) — Fri, 16 Dec 2011 16:33:00 +0000

MongoDB使ってますか？RavenDBのほうがいいですか？それともCassandraですか？いやいや、NoSQLなんて使わない派ですか？RDBよりも使い勝手のいいところがイロイロあると思うので、積極的につかてみてはどうでしょう。

先日MongoDBのSessionStateStoreに手を加えて、高速化してみたわけですが、そもそもMongoDBをどこに構築しておきましょう。自社内サーバー？DC内サーバー？いろいろ悩ましいところだと思いますが、ココは思い切ってAWS EC2に構築するのはどうでしょう。最近AzureでもOpennessでMongoDBが取り上げられてましたね。それもいいですけど、今回はEC2です。

おまたせしました。楽しいMongoDBの時間デス（1/5）:企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

MongoDBも2になってからはジャーナルが標準だし、ReplicaSetとShardingもあるし、アクセス認証もかけれるしで、良い感じですよね！

がしかし！つい最近までは致命的な問題があったんです。認証使えるはずなのに、Sharding環境で認証をかけてるとC# Official Drivderが例外おきて接続できなくて、実質認証を使えないという問題。DC内ならいいけど、クラウドに持って行こうと思うと、これが非常に都合が悪い。パフォーマンスを考慮すると大変都合が悪かったです。

そもそもは、なんでMongoDBを運用環境に利用しようとしたか、ですけど、そんな話はどーでもいいですね。ちなみになんで運用環境に持って行こうと考えたかというと、SQLServerのミラーリングのコストが馬鹿にならなくなってきたから。あとログを1箇所に集約したかったっていう理由も大きい。イベントログめんどくね？フォワーディングするにしても、操作しにくいし。DBのマシン性能が低いっていう問題があったんだけど、そこに投資しないと解決出来ないってわけでも気がしたんですよね。違うアプローチで解決出来そうだとゴーストがささやいた。もちろん投資すれば一発解決。大人の解決方法です。でも、なんかNoSQLで解決できる気がしたんすよ。そういうことあるでしょ？

TraceListner into MongoDB
MongoDBにASP.NETのSessionを格納する
 MongoDBにASP.NETのSessionを格納する - 完結編

ASP.NETのセッションデータと、トレースログをSQLServer以外に保持したい。そのために必要なパーツは用意して、パフォーマンスとか可用性とか拡張性とか検証して行けそうだと感じたら、どこに構築しましょうか、ってことになりますよね。DC内に構築するのがネットワーク的にも近いし、効率いいのはそうなんですけど、んじゃサーバーどこから調達するのさー、ってなるし、よく分からないものに投資してくれろ、とは言いづらいしそもそも投資するならまずDBだろ、みたいな事になって行ったり来たり。むふー。とりあえずは、仮想マシン用意してその中にMongoDBの構築を行うっていうところでスモールスタートするわけですが、それも時限式。余裕ない。こうなったら、本格的にクラウドで構築するしかねー！MongoHQっていう選択肢も無いわけじゃないけど、いっその事、AWS EC2にがっつり構築するのがいいんじゃないかと、一人プロジェクトスタート。クラウド使ってるっていうとなんかカッコイイ気がするじゃない。

イロイロ試した結果、ReplicaSetとShardingでmongodインスタンスを6個(rsを3台ずつ2シャード)、mongosインスタンス4個、コンフィグインスタンス3個。MongoDBだけでまずは13個。それとDNSが2台。コンフィグ2台とDNS2台は相乗りにして全13台。DNSはAWS内部での名前解決に使う目的と、既存ドメインのサブドメインで外向きの名前解決用。既存のDNSの管理者権限なんて欲しくないし、弄りたくもないので、既存DNSにはゾーン委譲だけしてもらうようにして、AWS用のサブドメインを用意しました。その方が自分で好きなように制御出来るもんね！なぜmongosが4個なのかって？スモールスタートなら2個でいいじゃん！と思うところですが理由は別。

予算の関係もあって、すべてマイクロインスタンスで構築。なので、DC内からのアクセスでVPCは除外。VPNが簡単でよかったんだけど、そもそもDCにVPNルータを設置する余裕すらない。スペースと電源ね。大丈夫だとは思うけど、EC2がマイクロじゃないと予算が辛い。だってこの時点ではまだ自腹。そんなに稼いでませんから！

で、まぁ、今のMongoDBのバージョン(2.0.1)じゃShardingで認証が出来ないってところにたどり着いてガックリしてたわけです。

[#SERVER-3929] Arbitrary replica set authentication "need to login" errors. - MongoDB

しょうがないよね。できないものは出来ないと諦めて、IP制限で接続制限かけることにしました。アクセス経路はDCからAWSなので暗号化はしておきたい。でもVPCは厳しい。そうなるとIPSecかSSL tunnelか。ELBにSSL tunnel出来る機能があるので、それがいいなと思ってたんだけど、ELBはIP制限かけられない。インスタンスに届いた時のIPはELBのIPだし、SSL tunnelだとHTTPなわけでもないからX-Forworded-Forなんか無いし。そうなるとIPSecでマシン間接続の暗号化かってことになって、IPSecの設定の勉強から。認証できれば一気に解決なのにー、と思いつつできないものはしょうがない。

なので結局選択肢はなくIPSec。初めてIP セキュリティポリシー使いました。ウィザードの使い方をちゃんと理解すれば大丈夫だった。あとネゴシエーションのためにUDP500,4500開けるのを忘れずに。この話長いから省略。

ちなみにMongoDBにアクセスするすべてのマシンにIPSecを登録するのは大変なので、Delegateを利用してポートフォワード。コレはコレで懐かしい感じですね。NIFTYの時以来。

DeleGate Home Page (www.delegate.org)

やっと、経路がセキュアになって、IP制限をかけれるようにもなったので、EC2で構築したMongoDBへのパフォーマンステスト。ただ残念ながら、IPSecしないのに比べて随分遅い。4:3くらいの比率で遅い。暗号化のコストが発生するからmongosがヒーヒー言ってる．．．。

先ほどmongos4台用意したといったのには意味があって、外向き(IPSecで外部から接続する場合)と内向き(AWS内のMonogDB以外のインスタンスからの接続用、暗号化しなくていいもんね)でそれぞれ構築しないとパフォーマンスしんどいからです。なので、外向きはIPSec対応mongos、内向きは素のmongos。それぞれ2台ずつ用意して計4台。

IPSecを使ったら遅いのはCPUがパワー不足なのも原因だからインスタンス大きいの使うしかないのかなー、と思いつつもそれでもSQLServerに入れるよりは早いし、まぁ、いいかと。いつの日か先のMongoDBの不具合が改修された暁には再度設定しなおそうと思い、まずはこれで開始。

いろいろ大変だね。OpenSSL使って証明書を作ったり、Delegateでゲートウェイ用意したり、IPSecの接続環境作ったり、そもそもMongoDBの環境作ることも含め、やること山盛り。それらのHowTo書こうと思うと大変面倒なので全てまとめて省略！勉強になったよ。MongoDBでReplicaSet+Shardingでの認証のやり方(ReplicaSetで個別にPRIMARYにユーザー登録して、mongos起動後configサーバーにもユーザー登録、最後にauthとkeyFile指定してサービス化。ちなみにそこまではコンソール起動でちょこちょこ調整しながら作業しました)がわかりにくかった。これまでのバージョンでうまくいってない部分だったみたいだからやむなし。インフラ屋って大変ね。

OpenSSL: The Open Source toolkit for SSL/TLS

今年ももう十分やりきっただろ。と、思った矢先にMongoDB2.0.2リリースのお知らせ。

Downloads – MongoDB

数日前にRC2が出たときには今年はもうないな、と思ってたのに。ウズウズ。ワクワク。ちなみにRCで先の不具合が解消されてたのは確認済みだったので、リリースをひたすら待つだけだったんですけど、まさかこのタイミングで出てくるとはねー。

こうなるとELBを利用してSSL tunnel(ELBではSecureTCPっていう名前)を利用する環境を用意してしまおうじゃないかとなりましょう。ReplicaSet+Shardingで認証かけれれば、後は経路の問題だけだし、何よりELBで暗号化復号化してくれればmongosが通信に専念すればいい状態になるし、更にはELBがラウンドロビンでmongosを選んでくれるから、パフォーマンスは大幅向上。1.25倍(2倍近くさばける時もある)くらい早くなりました。ELBだとアクセスが増えると受け口を自動でスケールしてくれるので、負荷がもっと高くなると、5分くらいで自動でよしなにしてくれるらしい。5分だっけ？そこはいいか。そうするとIPSec用mongosは用なし。さらにEIPでグローバルも不要。DNSにELBのCNAMEを登録すればいいだけになって更にお買い得。

運用の目処もたち、Reserved Instanceで見積もったり(超間違えたけど)して、最終的にやっと会社が払ってくれるようになって一安心。DBもWebもある程度はAWSに持っていっちゃう予定だけど、最終形態はDCとクラウドのハイブリッドが良い感じに思えますが、一般的にはどうなんだろ。

今はまだテスト環境のセッションストアと、トレースログの取得だけにしか使ってないけど、徐々に全てのトラフィックをDC内のMongoDBからAWSのMongoDBに変更していく予定です。どーなるかなー。楽しみだなー。

せっかくなのでPPT用の素材を使って今回の構成図を書いてみたよ。

MongoDB 2.0.1でIPSecの時

MongoDB 2.0.2でELBの時

あは。センスないー。素材があってもコレじゃ．．．。なんとなくでも伝わるといいな。mongosからReplicaSetをShardingとして参照するように設定してるのをうまく表現できませんでした．．．。

ところで、CloudWatchって数値高めに出てない？実際ログインして直接パフォーマンス見てみると、CloudWatchで表示されるほど高くないんだけどなー。なんだろ。そんなもの？

MongoDBにASP.NETのSessionを格納する - 完結編

noreply@blogger.com (たけはら) — Sun, 20 Nov 2011 09:44:00 +0000

前回のあらすじ

不思議な光る石のペンダントをつけた少女が空から降りてきた。天使が舞い降りたと思い走って近づく少年。その少女は伝説となった天空の城の王の末裔。少年もまた亡き父の言葉を信じ、天空の城の存在を信じていた。悪意を持った別の王の末裔が少女をさらい、城を悪用しようとすることから、少年は少女と城を守るため、海賊とともに空に旅立った。

ドキドキするストーリーですね！

．．．。

続きです。最終的に接続エラーが出て、処理が継続できない状態に陥るっていうところでした。問題解決する前に、現時点でのパフォーマンスを確認してみます。

前回同様Apache Benchで実行しますが、10000回だとエラーになってしまって計測に失敗してしまうので、桁を下げて1000回(-n 1000 –c 8)としてましょう。

計測方法はabを3回実行してRequest per secondの平均を取ります。

InProc

1回目：538.39
2回目：588.10
3回目：660.41

平均：595.63

StateServer

1回目：525.43
2回目：567.28
3回目：599.09

平均：563.93

SQLServer

1回目：282.39
2回目：370.53
3回目：352.21

平均：335.04

MongoDB

1回目：129.71
2回目：146.35
3回目：145.03

平均：140.36

うん。早くない。ちなみに無印UniversalProviderだと 30.15 とドンマイな感じ。

Universal Provider

ちなみに、5回で平均を取りたかったけど、MongoDB版が5回目で接続エラーになって取れなかったので3回にしました。これは良くない！まずはちゃんと10000回普通に動かせるようにしないと。

と、いうわけで、MongoDB C# Official Driverのドキュメントに目を通してみると、内部でConnection Poolingを利用していると書かれています。が、挙動からはPoolがちゃんと利用されてないんじゃないかと、疑ってみました。だって、接続エラーって．．．。使いまわしてるならそんなことにならないはず、という根拠のない診断。うさんくさいドクターハウス。

CSharp Driver Tutorial – MongoDB

MongoDB C# Driver API Documentation - Table of Content

詳細はドキュメントから判断出来なかったので、ソースを追いかけてみました。オープンソースだといろいろ調べれていいですねー。

mongodb/mongo-csharp-driver – GitHub

チラチラ見た結果からいうと、MongoServerクラスに保持しているMongoServerInstanceがConnectionPoolを管理していて、MongoServer.Disconnectを呼ぶとすべてのPoolをクローズして回る仕組みのようです。なんでだろ。理由はいいとして、そういう作りなんだということは、finallyで必ずDisconnectを呼び出すのはよろしくないかなー。そんな事しなくても、Poolに保持しているものは10秒ごとにMaxConnectionLifeTime/MaxConnectionIdleTimeを確認して破棄されるようになってるみたいなので、ほっといてもいいんじゃね？みたいな。

と、いうわけで、ソース中のすべてのDisconnectを削除します。

その状態で、abで確認します。

3回実行した結果は525.43 / 599.09 / 572.34。平均：565.62。ワォ！一気に上がりました。せっかくなので10000回出来るかどうかもチェック。

行けるようになりましたー。ちゃんと接続を使い回してくれてるようです。パフォーマンスも接続を使いまわすことで一気に改善しました。んじゃ、なんで、そういう作りにしてなかったのか？っていうのが気になります。

理由はありました。どういうことかというと、Poolが保持しているMongoConnectionは生成された時点でReplicaSetのPrimaryを判定して保持しています。つまり、Failoverした直後、Poolが破棄されない限り接続エラーがおきて、正しくデータの書き込みができなくなるということでしょう。

abを実行し、その最中にstepDownでFailoverしてみます。

Safemode detected an error 'not master'. (Response was { "err" : "not master", "code" : 10056, "n" : 0, "lastOp" : NumberLong("5676991341247070789"), "connectionId" : 13356, "ok" : 1.0 }).

masterじゃないダニ！と言われ、書き込みできないエラーが発生しました。SafeModeじゃなくても同じようにエラーになることは確認済み。

と、得意げにドヤ顔したところで、それはつまりDisconnectしなくなったからでしょ？と、おっしゃるとおりな理由でのエラーなんですけどね。つまり、Failoverした後もちゃんと接続が継続できるようにするために毎回Disconnectしてたわけですね。

あちゃー、これはどうしたものか。なんて、あたかも今、解決策を思いつくような振りになってますけど、事前に調査してわかってることを書いてるだけなんで．．．。てへ！

つまり今回のエラーの原因はPoolから取り出したMongoConnectionがPrimary(Master)を指してないから例外が起きるわけです。そして、MongoServer.Disconnectを呼ぶことでPoolのすべてのコネクションが破棄されるというのはソース見て確認済み。つまりMongoDBに対する処理で例外が発生したらMongoServer.Disconnectを呼び出し、処理をリトライすることで、Failover後に決定したNodeに接続するようにしてあげればよい、という方法が取れましょう。MaxConnectionLifeTimeを短くしてみては？っていうのもあるでしょうが短すぎると接続エラーになりそうだし。

で、用意したのが以下のようなリトライ実行するヘルパー。

public class MongoDbInvokeSetting
{
  public string ServerName { get; set; }
  public string DatabaseName { get; set; }
  public int RetryCount { get; set; }
  public int RetrySeconds { get; set; }
}

public class MongoDbHelper
{
  /// <summary>
  /// リトライを繰り返すInvoker
  /// </summary>
  /// <param name="setting"></param>
  /// <param name="functor"></param>
  public static void RetryInvoker(MongoDbInvokeSetting setting, Action<MongoServer> functor)
  {
    var retry = setting.RetryCount;
    Exception exception = null;
    while (retry > 0)
    {
      var server = MongoServer.Create(setting.ServerName);
      try
      {
        functor(server);
        break;
      }
      catch (MongoException ex)
      {
        exception = ex;
        // ↓こいつでPool内の全コネクションクリアが走るはず。
        server.Disconnect();
      }
      retry--;

      // とりあえずn秒待ってみる。
      Thread.Sleep(setting.RetrySeconds * 1000);
    }

    // ここでイベントログに書き出すか、Exceptionを出力する必要がある。
    // 後続の処理に進んだら困るならException。
    // ログなら進んでもいいかもねー。
  }
}

ダサくない！ダサくないよ！これでいいんだもん！

このコードを書いてる途中、さすがに心配になったんですけど(これでいいのかっていうね)、そんなおり以下のページを見つけました。

File: REPLICA_SETS — MongoRuby-1.4.1

似たようなリトライさせてますね。だもんで、いいってことで。

これを使って実行する書き方は↓こう。

MongoDbHelper.RetryInvoker(GetSetting(), server =>
{
  // serverを使ってCollection検索したり、
  // データ追加したり...
});

GetSettingは設定を入れたものを返しましょう。サーバー名とかリトライ回数とか。

これつかって丸っとしたもので、実行しつつFailoverさせてみます(abでエラーが出ないことを確認しました)。

大成功！エラーも起きずFailover成功しました。データも欠落なくいけてます。

で、この状態でのパフォーマスンスを測定してみます。

3回実行したのが485.62 / 496.92 / 552.61 平均：511.72。

遅くなったじゃん！っていう感じしますけど、あったまって無かったみたい。実質Disconnect削除のパフォーマンスと同じ数値でした。

でも～、これだと～、なんていうかパンチが弱い。十分いいとは思うんだけど～。どこか早くできそうなところないかなー、とMongoSessionStateStoreのソースを見ているとありましたねー。

private string Serialize(SessionStateItemCollection items)
{
  using (MemoryStream ms = new MemoryStream())
  using (BinaryWriter writer = new BinaryWriter(ms))
  {
    ...
    return Convert.ToBase64String(ms.ToArray());
  }
}

private SessionStateStoreData Deserialize(HttpContext context,
string serializedItems, int timeout)
{
  using (MemoryStream ms =
    new MemoryStream(Convert.FromBase64String(serializedItems)))
  {
    ...
  }
}

ほら、ここ。Base64に変換してstringにしてるじゃないですか。コレいらなくない？BsonBinaryArray使えばbyte[]をそのまま入れることが出来るんじゃないのー？と、気になったので試した結果が↓こちら。

3回実行したのが 542.95 / 538.68 / 534.19、 平均：538.61。微妙．．．。まぁ、いいか。

ちなみにこのままだと、Expireしたセッション削除が残り続けるので、SetAndReleaseItemExclusiveの中で2000回に一回くらいクリーンアップするように仕込んでみました。その状態で10000回実行。

10000回中5回クリーンアップしてるけど、まぁまぁ。外部タスクにしてしまえば影響はでないものなので、ここはいいでしょう。

ち・な・み・に、SQLServerだと平均335.04ですからね。いいじゃないですか。ねぇ。Shardingしてみても同じマシンだとあまり変化でなかったです。と、いうのもCPUを最も使ってるのがIISExpressのプロセスだったので、アプリケーションが遅いってことですから。あとは、マシン分けて計測しかないですが、少なくとも同一環境内ではMongoDBでのSessionStateStoreがStateServerに負けないくらいの速度を実現しました(何度か試したらStateServerはもっと早かったけどー、そこは情報操作！)。

MongoDBにASP.NETのSessionを格納する

noreply@blogger.com (たけはら) — Sat, 19 Nov 2011 14:24:00 +0000

ASP.NETのSessionといえば

InProc(アプリけーションプロセス内のインメモリステート管理)
シリアライズコストも発生せず、同一プロセス内で言わばstatic Dictionary<string,object>の実装で最速。ただし、アプリけーションのリサイクルと同時にセッションが破棄されるのと複数プロセス間で共有できないです。
StateServer(専用プロセスによるインメモリステート管理)
InProcの弱点である、アプリけーションのリサイクルによる破棄とプロセス間共有を実現出来るようにしたもの。プロセスをまたぐのでシリアライズコスト発生するけど、インメモリなのでInProcにつぐ速度を実現。ただし、シングルプロセスでの実装になるので、耐障害性という意味では弱い。ステートをホストしているマシンの障害や再起動などでセッションが破棄されてしまいます。
SQLServer(ストーレジに保持するステート管理)
StateServerの弱点であり、耐障害性をクリアしたストレージ保存型でのセッション管理。シリアライズコスト＋DBサーバーのパフォーマンス次第で遅くもなるし早くもなる。
Custom(SessionStateStoreProviderBaseを派生したカスタム実装)
キャッシュクラスタ(Velocity)を利用したり、EntityFrameworkを利用した実装(UniversalProvider)を使ったりSessionStateStoreに対してイロイロです。DBをSQLServer以外にする場合にも利用されてます。

選択肢多くていいですね。標準のものもそれぞれ優秀で素晴らしいです。SessionIDの生成や、クライアントとのやり取りは別の仕組みで実装されてるので、SessionStateStoreProviderのカスタムとは分離されてて安心です。

MongoDB ASP.NET Session State Store Provider | AdaTheDev

最近、すっかりMongoDBに心奪われてる身としては、SessionをMongoDBに入れてしまいたいという衝動にかられてます。あれやこれやの問題もあり、SQLServerだけにたよるソリューションだとよろしくないなというのもありまして。

MongoDB、大変優秀ですね。ReplicaSet(レプリケーション)による可用性の確保(自動フェールオーバー有り)と、Sharding(データのパーティショニング)によるパフォーマンスの確保、素晴らしいです。

いろいろ試して部分的に利用を始めてる段階で、まだまだ自信をもって使いまくるって言う状況ではないですが、ちょっとずつです。ちょっとずつ使っていってSQLServer＋MongoDBで行けるところまで行ってみようと企んでます。

まずはTraceListnerのMongoDB化。前回のエントリでそれっぽい感じのものを提示しましたが、これでサーバー群のトレース情報を低コストなストレージに保持出来るようになりますね。トレース情報くらいなら万が一情報欠落しても致命的になることも無いでしょう。しかし！セッションはそういうわけにはいきませんね。システムとして提供している表の機能に影響がでちゃいますからね。

そうなると、ReplicaSetの機能を利用することは必須となりましょう。そうするとFailoverの時の挙動を確認したりする必要も出てきますよね。そういうテストを繰り返してこそですよね。楽しい時間ですね。

先ずはReplicaSetでMongoDBを２つ起動。ArbitarっていうSQLServerでいうところのウィットネスサーバーを１台追加してないと投票結果が偶数とかになって次のPrimary決定時に困っちゃうことがあるので、３ノード起動します(詳しくはオフィシャルサイトでどーぞ)。

rem arbitar
start "arbitar" c:\mongo\bin\mongod.exe --port 27020 --replSet mongo --dbpath c:\mongo\dba

rem replicaset
start "mongo1" c:\mongo\bin\mongod.exe --rest --noauth --port 27031 --replSet mongo --oplogSize 20 --dbpath c:\mongo\dbr1
start "mongo2" c:\mongo\bin\mongod.exe --rest --noauth --port 27032 --replSet mongo --oplogSize 20 --dbpath c:\mongo\dbr2

これで起動してるので(c:\mongoに一式ある前提です)、まずは初期化。

27031のノードにMongoDB Shellで接続。

mongo localhost:27031

初期化コマンド順番に実行すればOKです。

rs.initiate()
rs.add("hostname:27031")
rs.add("hostname:27032")
rs.addArb("hostname:27020")

まずはこの状態で公開されてるソースを利用してSessionを使ってMongoDBにデータを入れてみましょう。

MVC4DPでアプリケーションを作り、Home/IndexアクションでSessionに値をいれて、Home/Indexビューで表示するだけのものです。

public ActionResult Index()
{
  ViewBag.Message = "Modify this template to kick-start your ASP.NET MVC application.";
  Session["message"] = ViewBag.Message;

  return View();
}

<h2>from session:@Session["message"]</h2>

MongoSessionStateStore/MongoSessionStateStore.cs at master from AdaTheDev/MongoDB-ASP.NET-Session-State-Store - GitHub

↑ここからソースを取得して、プロジェクトに追加。後はNuGetでMongoDB Official Driverを入れておきましょう。

コメントに従い、接続文字列を指定するとレプリカセットにならないので、今回起動したMongoDBを指すように接続文字列を変更。

connectionString="mongodb://localhost:27031,localhost:27032/"

ちゃんと出来てますね。

MongoVUEで27031(primary)データを確認。

入ってるねー。

続いて27032(Secondary)のデータを確認。

もちろん入ってますね。

ここで、ReplicaSetを入れ替えましょう！

MongoDB ShellでPrimaryにつないで rs.stepDown() で強制フェールオーバーを実行。

ちゃんと切り替わりました。

この状態で再度先ほどの起動したブラウザでF5でリロード。ちゃんと動くなら、これでFailoverしたほうを参照して、表示されるはず！

タターン！うまくいきました。内部ではSafeModeっていう書き込み確認モードで動作するようになってるので、手堅いです。

27032(SecondaryからPrimaryに変更したノード)でSessionsコレクション(テーブルですね)を確認して見つつブラウザのF5リロードを繰り返すと、ちゃんとLockIdがカウントアップしていくので、読み込みも書き込みもFailover後にちゃんとできてるのが確認できます。

だがしかし！ここで大問題が！！

パフォーマンスを測定しようとApache Benchでリクエストを投げまくってみると、最後まで完了せずにエラーで途中終了してしまいます。

Unable to connect to the primary member of the replica set: システムのバッファー領域が不足しているか、またはキューがいっぱいなため、ソケット操作を実行できませんでした。

なかなかの男気あふれる強気のエラーメッセージ。
どーしたんだMongoSessionStateStore！
これが精一杯なのかOfficial Driver！

長くなったのでつづく．．．。

URLRewriteのoutboundRulesでセッションIDを含んだHTML内のURLを普通のURLに戻す、リベンジ

noreply@blogger.com (たけはら) — Sat, 29 Oct 2011 01:15:00 +0000

タイトル長っ！

無聊を託つ: Controllerを名前から生成するしHTMLを書き換えたりもしてみる

ちょっと前にエントリしました。が、間違えてました。思いっきり。これを信じてくれた人すいません。リベンジです！今度はこないだのよりだいぶマシ。

目的は、OutputCacheを利用する際にCookieless URL(セッションIDとかを含んだURL)をHTMLに保持してると、他の人とセッション共有しちゃうから、それを防ぐ！です。セキュリティ的に守らなきゃ、という理由だけでページ全体をno-cacheにするのはあまりにも富豪。

さらに、gzipで動的コンテンツを圧縮することで、CPUは多めに使うことがあるけど、OutputCacheで相殺。もちろんレスポンス性能が劇的に向上するので、ユーザーにとってはいいことづくし。

<rewrite>
  <outboundRules>
    <rule name="Sessionless" preCondition="html" enabled="true">
      <match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script, CustomTags" 
				customTags="All" 
				pattern="(.*)/\([SFA]\([^/]+\)\)/(.*)"/>
      <action type="Rewrite" value="{R:1}/{R:2}"/>
      <conditions>
        <add input="{REQUEST_URI}" matchType="Pattern" pattern="\)/mobile" ignoreCase="true" negate="true" />
      </conditions>
    </rule>
    <customTags>
      <tags name="All" />
    </customTags>
    <preConditions>
      <preCondition name="html">
        <add input="{RESPONSE_CONTENT_TYPE}" pattern="text/html" />
        <add input="{REQUEST_URI}" pattern="/mobile" negate="true" />
      </preCondition>
    </preConditions>
  </outboundRules>
</rewrite>

これが、たぶん正解のRewrite用のconfig。ちゃんと確認してみます。

せっかくなので、MVC4DPを利用してみましょう(意味なくはない)。プロジェクト作って実行すると表示される画面は↓こうですね。

この時のURLは http://localhost:61972/ です。

このままではやりにくいので、sessionStateでcookieless="UseUri"にします。

見た目が変わるわけじゃないです。URLを見てくださいね。今度は http://localhost:61972/(S(l2ulbdgxdrbdoyrozczknp1p))/ となっていますね。この状態でソースを確認します。

バッチリセッションIDがURLに含まれてますね。先ほどのconfigをsystem.webServer内に追記するとどうなるか。

セッションIDが消えました！概ね．．．。部分的に残ってる部分があるんですけど、それは多分仕様。と、いうのもAタグのhref属性の前にdata-dialog-title属性が入ってますよね。これがあるとURLRewriteが対象だと判断してくれないみたいです。試しに、_LogOnPartial.cshtmlを変更してみます。

@if (Request.IsAuthenticated) {
    <p>
        Hello, @Html.ActionLink(User.Identity.Name, "ChangePassword", "Account", null, new { @class = "username" })!
        @Html.ActionLink("Log Off", "LogOff", "Account")
    </p>
} else {
    <ul>
        <li>@Html.ActionLink("Register", "Register", "Account", routeValues: null, htmlAttributes: new { id = "registerLink", data_dialog_title = "Registration" })</li>
        <li>@Html.ActionLink("Log on", "LogOn", "Account", routeValues: null, htmlAttributes: new { id = "logonLink", data_dialog_title = "Identification" })</li>
    </ul>
}

↑こっちがオリジナル。で、↓こっちが修正版。違いはhtmlAttributesのdata_dialog_titleの有無。

@if (Request.IsAuthenticated) {
    <p>
        Hello, @Html.ActionLink(User.Identity.Name, "ChangePassword", "Account", null, new { @class = "username" })!
        @Html.ActionLink("Log Off", "LogOff", "Account")
    </p>
} else {
    <ul>
        <li>@Html.ActionLink("Register", "Register", "Account", routeValues: null, htmlAttributes: new { id = "registerLink" })</li>
        <li>@Html.ActionLink("Log on", "LogOn", "Account", routeValues: null, htmlAttributes: new { id = "logonLink" })</li>
    </ul>
}

そうするとレンダリングされるHTMLは↓こうなります。

RegisterとLog onのURLからもSessionIDが消えて正しくなりました。htmlAttributesで追加した属性はTagBuilderで展開されるときにアルファベット順に出力(SortedDictionary)されるんですね。なので、hrefより先にdata属性が展開される、と。この辺、どうするんでしょうね。正しくはURLRewriteのOutboud Providerが対応することなんだと思うけど．．．。

とりあえず、今のところスルー。さーせん。

ちなみに前回はこれを仮想ディレクトリ配下にデプロイせずに「出来たできた～」と浮かれてて、実はちゃんと消えないっていうダメっぷり。あと、SessionIDだけじゃなくCookielessの場合は認証チケット(F)も匿名ID(A)もURLに含まれるのにSだけ見てて、これまたちゃんと消えないっていうダメダメっぷり。

今回はちゃんと確認。

ローカルIISのmvc4dpにデプロイ。URLは view-source:http://localhost/mvc4dp/(S(cow2znspocwggst1mah50myt))/ です。これもちゃんとHTML中のURLからはちゃんとSessionIDが消えました！

でー。この状態で今度はアウトプットキャッシュをOnにします。そのためにHomeControllerに以下の追記。

    [OutputCache(Duration = 60)]
    public class HomeController : Controller
    {
        public ActionResult Index()
        {

これをVS実行環境で見てみる。

ちゃんと出力キャッシュが効いてる証に、max-ageとExpiresが出てますね。

ローカル環境でもキャッシュの有無で少しだけ、結果が違いますね。

少しだけね。で、このキャッシュされてるHTMLにはもちろんSessionIDは含まれてません。

ココからさらに動的圧縮をOnにするために以下の記述を追加。

    <urlCompression
      doStaticCompression="true"
      doDynamicCompression="true"
      dynamicCompressionBeforeCache="false" />

と、いいたいところですが、残念ながらこれはこのままでは機能しないんです。

URL Rewrite Outbound Rules w/ Compression : The Official Microsoft IIS Site

↑ココに書かれてる通り、レジストリに項目追加が必要です。切ないですね。でも、まぁ、いいでしょう。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite]
"LogRewrittenUrlEnabled"=dword:00000000

これをレジストリに追加。

で、いざ！と思いきや．．．。

ざんねーん。IIS Expressではどうもこのレジストリの値を見てくれないみたいです。対策も特に見つけられなかったです。なのでローカルのIISにデプロイしたほうで試します。

たたーん！出力キャッシュも効いてるし、gzipも効いてます。さらにHTML中のSession IDを持ってるURLもなくなってます！Content-Lengthが5.77KBから2.61KB。

標準(追加モジュールですけどMS謹製)でもココまで出来ました。

これ以上は独自のResponse Filterを書いてHTML中のURLを操作する方法になるでしょう(もちろんURL RewriteのProviderを実装という手もあるけど、それ書くくらいならFilterのほうが低コストじゃないですかねー)。

大規模サイトもコレで安心ですね。

ちなみに、ですけど、すべてのサイトでコレを設定すれば早くなるわけじゃないので用法・用量を守って正しくお使いください。

TraceListner into MongoDB

noreply@blogger.com (たけはら) — Sat, 15 Oct 2011 01:49:00 +0000

たまには週間たけはらブログ。

ASP.NETでTraceListner使ってますか？今まで結構仕込んでおいたんだけど、ファイルやイベントログだと扱いにくいなー、なんて思ってませんか。思ってました。融通効かないなー、と。大規模サイトなんかでSQLServerに入れちゃうと、大変なことにナチャウヨ。

そこでMongoDB。みんな大好きMongoDB。ドキュメントの日本語化も着実に進んでるので、英語なんてー、と気にすることもあんまりないでしょう。そーでもないですか？いろいろ可愛いやつですよ！ログデータの保持なんて、もう、得意中の得意です。保持する構造さえちゃんとしておけば、RDBじゃ処理しにくいものもお気楽に扱えます。用途と使い方次第デスけどね。

Home - Docs-Japanese - 10gen Confluence

MongoDBって何よ？っていうのは、いろいろ検索してね。

MongoDB と NoSQL を試す
 MongoDB と NoSQL を試す (第 2 部)
MongoDB と NoSQL を試す (第 3 部)

開発環境で超簡単な使い方はコンソールでmongodを起動しておいて、mongoで中身を確認。

だんだんmongodをサービス起動しておきたくなりますが、最初は単なるプロセス起動。もちろん、内容確認をコンソールのmongoで行うのも、ハッカーみたいな雰囲気あっていいかもしれないけど、そんなの面倒なので実際はGUIのツールを使いましょう。

MongoVUE | Gui tools for MongoDB

他にもイロイロあるので、気に入ったのを選んで試してみましょう。

Admin UIs – MongoDB

このMongoDBにTraceListnerからmessageを保存するようにしちゃいましょー！

開発するならHTTPでのREST操作(MongoDBに最初からあります)よりも、Driverを使った開発のほうが楽チンぽんです。前までは、いろいろ使い勝手の問題もあったりとかしたけど、いまとなっては標準公開されてるもので十分です。

CSharp Language Center – MongoDB
CSharp Driver Tutorial - MongoDB

英語かよ！どんまい。

マニュアル - Docs-Japanese - 10gen Confluence

なんにせよNuGetで取得できるのが便利なところです。

Official MongoDB C# driver - 1.2 : NuGet gallery

TraceListnerって自分で用意したことなかったんだけど、TraceListnerクラス派生でいいってことなので、お手軽ですね。必須なoverrideも2個だけ。

public override void Write(string message)
{
  // ...
}

public override void WriteLine(string message)
{
  // ...
}

やれそうですね。

えいやっ！

using System.Configuration;
using System.Diagnostics;
using MongoDB.Bson;
using MongoDB.Driver;

namespace MongoListner
{
  public class MongoDbTraceListner : TraceListener
  {
    private readonly MongoServer _server;
    private readonly MongoDatabase _database;
    private readonly string _collectionName;

    public MongoDbTraceListner() : this("TraceData") { }
    public MongoDbTraceListner(string initializeData)
    {
      _collectionName = initializeData;
      var serverName = ConfigurationManager.AppSettings["MongoDb:Server"];
      var databaseName = ConfigurationManager.AppSettings["MongoDb:Database"];

      if (string.IsNullOrEmpty(serverName))
          serverName = "mongodb://localhost";

      if (string.IsNullOrEmpty(databaseName))
          databaseName = "TraceListner";

      _server = MongoServer.Create(serverName);
      _database = _server.GetDatabase(databaseName);
    }

    private void Insert(BsonDocument document)
    {
      var collection = _database.GetCollection(_collectionName);
      collection.Insert(document);
    }

    private void InternalWrite(string message)
    {
      var document = new BsonDocument {{"Message", message}};
      Insert(document);
    }

    private void InternalWriteObject(object o)
    {
      var document = new BsonDocument();
      
      var type = o.GetType();
      foreach(var prop in type.GetProperties())
      {
          document.Add(prop.Name, prop.GetValue(o,new object[]{}).ToString());
      }
      Insert(document);
    }

    public override void Write(string message)
    {
      InternalWrite(message);
    }

    public override void WriteLine(string message)
    {
      InternalWrite(message);
    }

    public override void WriteLine(object o)
    {
      var type = o.GetType();
      if (type.Name.StartsWith("<>") && type.Name.Contains("AnonymousType"))
      {
          InternalWriteObject(o);
          return;
      }
      InternalWrite(o.ToString());
    }
  }
}

できたー。

後は、web.configに書いて使えるようにするだけですね！

  <appSettings>
    <add key="webpages:Version" value="1.0.0.0"/>
    <add key="ClientValidationEnabled" value="true"/>
    <add key="UnobtrusiveJavaScriptEnabled" value="true"/>
    
    <add key="MongoDb:Server" value="mongodb://localhost"/>
    <add key="MongoDb:Database" value="TraceListner"/>
  </appSettings>

<system.diagnostics>
  <trace autoflush="false" indentsize="4">
    <listeners>
      <add name="mongoListener" 
           type="MongoListner.MongoDbTraceListner, MongoListner"
           initializeData="MyTrace" />
      <remove name="Default" />
    </listeners>
  </trace>
</system.diagnostics>

  <system.web>
    <trace enabled="true"/>

あとはSystem.Diagnostics.Trace.Write/WriteLineです！すでにたくさん仕込んでいる場合にはコレでOK。

ASP.NET MVC3標準プロジェクトを作成して、MongoDbTraceListnerクラスを作成し、HomeControllerのIndexアクションにTraceを書いてみましょう。

わーお！素敵！！

MongoDBが違うマシンだったり(本番はそうしましょう)、Database名を変更したいときはappSettingsの値を変えてね。コレクション(テーブル相当)の名前を変えたかったらtrace/listnersのinitializeDataで指定してね。

ちなみに、これだけだとつまんないので、ここから少し拡張してパフォーマンス計測してみましょう。まずはIHttpModuleを実装して、リクエストの処理時間を計測するようにしてみます。

mvc-mini-profiler - A simple but effective mini-profiler for ASP.NET and WCF - Google Project Hosting

↑パフォーマンス計測ならこんな素敵なもの(NuGit.orgで実物見れますよ～)もありますが．．．。これから新規ならこっちのほうが．．．。いや、言うまい。

どりゃ！

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Web;

namespace MongoListner
{
  public class PerformanceTraceModule : IHttpModule
  {
    private string ItemKey = "_mongoDbTraceStart";
    private readonly string _serverName = "";

    public PerformanceTraceModule()
    {
      _serverName = Environment.MachineName;
    }

    public void Init(HttpApplication context)
    {
      context.BeginRequest += new EventHandler(context_BeginRequest);
      context.EndRequest += new EventHandler(context_EndRequest);
    }

    void context_BeginRequest(object sender, EventArgs e)
    {
      var httpContext = (sender as HttpApplication).Context;
      var startTime = httpContext.Items[ItemKey] = DateTime.Now;
    }

    void context_EndRequest(object sender, EventArgs e)
    {
      var httpContext = (sender as HttpApplication).Context;
      var startTime = (DateTime)httpContext.Items[ItemKey];

      Trace.WriteLine(new
      {
        Server = _serverName,
        RequestAt = startTime,
        Method = httpContext.Request.HttpMethod,
        Status = httpContext.Response.StatusCode,
        RawUrl = httpContext.Request.Url.ToString(),
        Milliseconds = (DateTime.Now - startTime).Milliseconds
      });
    }

    public void Dispose()
    {
    }
  }
}

これを利用するためにsystem.webServer/modulesに登録します。

  <system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>
    <modules runAllManagedModulesForAllRequests="true">
      <add name="mongoListner" 
           type="MongoListner.PerformanceTraceModule, MongoListner" 
           preCondition="integratedMode"/>
    </modules>
  </system.webServer>

実行してみます。

BeginRequestからEndRequestの間を計測するものですが490msって．．．。遅すぎ！

と、思ったらF5リロードの2回目は5ms。そーだろそーだろ。ん？よく見たらStatusとMillisecondsがstringになってるー。TraceListnerのInternalWriteObjectでToStringしてたね。失敬。そこは修正しましょう。書きながら作る、作りながら書く！

private void InternalWriteObject(object o)
{
  var document = new BsonDocument();
  
  var type = o.GetType();
  foreach(var prop in type.GetProperties())
  {
    var value = BsonValue.Create(prop.GetValue(o,new object[]{}));
    document.Add(prop.Name, value);
  }
  Insert(document);
}

これでちゃんと型どおり。BsonValueにはいろいろあるのでドキュメント参照してみてください。

このHttpModuleがあればすべてのリクエストの処理時間が計測できますね！アクセスログのTimeTakenとダダカブリ。どんまい。

IIS 6.0 ログファイルの Time Taken フィールドは何を表し、何を意味していますか。 : IIS 6.0 についてよく寄せられる質問

ASP.NET MVCならActionFilter属性を使ってControllerでの処理時間とViewの処理時間をそれぞれ別で計測できてなお嬉しいはず。

そいやっ！

using System;
using System.Diagnostics;
using System.Web.Mvc;

namespace MongoListner
{
  public class PerformanceTraceAttribute : ActionFilterAttribute
  {
    private string ItemKey = "_mongoDbFilterTraceStart";
    private readonly string _serverName = "";

    public PerformanceTraceAttribute()
    {
      _serverName = Environment.MachineName;
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
      filterContext.HttpContext.Items[ItemKey] = DateTime.Now;

      base.OnActionExecuting(filterContext);
    }

    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
      var startTime = (DateTime)filterContext.HttpContext.Items[ItemKey];

      Trace.WriteLine(new
      {
          Server = _serverName,
          ProcessAt = DateTime.Now,
          RawUrl = filterContext.HttpContext.Request.Url.ToString(),
          Method = filterContext.HttpContext.Request.HttpMethod,
          Controller = filterContext.RouteData.GetRequiredString("controller"),
          Action = filterContext.RouteData.GetRequiredString("action"),
          Milliseconds = (DateTime.Now - startTime).Milliseconds
      });

      base.OnActionExecuted(filterContext);
    }

    public override void OnResultExecuting(ResultExecutingContext filterContext)
    {
      filterContext.HttpContext.Items[ItemKey] = DateTime.Now;

      base.OnResultExecuting(filterContext);
    }

    public override void OnResultExecuted(ResultExecutedContext filterContext)
    {
      var startTime = (DateTime)filterContext.HttpContext.Items[ItemKey];
      var viewName = (string) null;
      if (filterContext.Result is ViewResult)
      {
        viewName = (filterContext.Result as ViewResult).ViewName;
      }
      Trace.WriteLine(new
      {
        Server = _serverName,
        ProcessAt = DateTime.Now,
        RawUrl = filterContext.HttpContext.Request.Url.ToString(),
        Result = viewName ?? filterContext.Result.GetType().Name,
        Controller = filterContext.RouteData.GetRequiredString("controller"),
        Action = filterContext.RouteData.GetRequiredString("action"),
        Milliseconds = (DateTime.Now - startTime).Milliseconds
      });

      base.OnResultExecuted(filterContext);
    }
  }
}

これを有効にするためにGlobal Filterに追加しておきましょう。

あとは実行するだけ！

ズームして見てね。

Controllerでの実行時間が223ms、ActionResultの実行時間が180ms、HttpModuleでの計測時間が497ms。差が94msありますね。そんなもんでしょう。ちなみにコレが初回実行時の計測で、2回目は↓。

Controllerでの実行時間が0ms、ActionResultの実行時間が0ms、HttpModuleでの計測時間が10ms。差が10ms。これまた、そんなもんでしょう。

こんな感じです！楽しいですね！

途中、MongoDBに入れるDocumentのカラムを変更したりしてるけど、MongoDB側へは何も手を加える必要がないんです。ドキュメント単位(テーブルなら行単位)にカラム構成が変更されてもお構いなしです。ちなみにサーバーさえいればDatabaseもCollectionも初回アクセス時に勝手に作られるので準備は不要。この手軽さと、レスポンス性能の高さがMongoDBの魅力です。

今回のプロジェクト一式は↓こちら。ローカルにMongoDBさえ入っていればそのまま動くはず。

※ファイルを小さくするために、packages/mongocsharpdriver.1.2を消してます。

AllowHtmlの深淵

noreply@blogger.com (たけはら) — Mon, 10 Oct 2011 15:43:00 +0000

月刊たけはらブログ。と、なってしまいましたね。

Understanding Request Validation in ASP.NET MVC 3

唐突ですが、↑随分前のこのエントリ、ずっと気になってたんです。ValidateInputAttributeってあるじゃないですか、Ver1の時から。これを指定したControllerやActionは不正なリクエスト文字列が含まれるとHttpRequestValidationExceptionをthrowするやつです。

これ、もともとASPXのPageディレクティブのValidateRequestとしても使われてますね。Pageディレクティブですよ。ココ重要。

MVC3になってからAllowHtmlAttributeって言うモデルプロパティに指定できるやつが追加されたじゃないですか。これ、とても不思議に思ってたんです。でも、まぁいっか、思ったように動くし、と、見て見ぬふりしてたんですけど、どーも、気持ち悪くてですね。

どういうことかというと、PageディレクティブだとHttpRequest.ValidateInput()に直接連携するというのはすんなり受け入れられるけど、それってリクエストコンテキスト単位のチェック(Form,QueryString,Cookieが送信されてきたリクエスト自体)で、個々の要素っていうか値単位のチェックなわけじゃない、っていう仕組みじゃないですか。なのでAllowHtmlってソレまでの仕組みとは全然違うものを実装してるということになりましょう。そうなると、どういう仕組で実装されてるのかキニナル。気になる。

で、先のブログのエントリなんですけど、正直かなり難しそうだなー、と思ってずっと敬遠してました。

さっそく原点、ASP.NET MVC1のControllerActionInvoker見てみます。

[SuppressMessage("Microsoft.Performance", "CA1804:RemoveUnusedLocals", MessageId = "rawUrl",
  Justification = "We only care about the property getter's side effects, not the returned value.")]
private static void ValidateRequest(HttpRequestBase request) {
  // DevDiv 214040: Enable Request Validation by default for all controller requests
  // 
  // Note that we grab the Request's RawUrl to force it to be validated. Calling ValidateInput()
  // doesn't actually validate anything. It just sets flags indicating that on the next usage of
  // certain inputs that they should be validated. We special case RawUrl because the URL has already
  // been consumed by routing and thus might contain dangerous data. By forcing the RawUrl to be
  // re-read we're making sure that it gets validated by ASP.NET.

  request.ValidateInput();
  string rawUrl = request.RawUrl;
}

HttpRequestBaseのValidateInputを呼んで、RawUrlにアクセスするだけのシンプルな実装ですね。コメントから苦労が垣間見れます。

ASP.NET MVC3の同じ部分を見てみます。

internal static void ValidateRequest(ControllerContext controllerContext) {
  if (controllerContext.IsChildAction) {
      return;
  }

  // DevDiv 214040: Enable Request Validation by default for all controller requests
  // 
  // Earlier versions of this method dereferenced Request.RawUrl to force validation of
  // that field. This was necessary for Routing before ASP.NET v4, which read the incoming
  // path from RawUrl. Request validation has been moved earlier in the pipeline by default and
  // routing no longer consumes this property, so we don't have to either.

  ValidationUtility.EnableDynamicValidation(HttpContext.Current);
  controllerContext.HttpContext.Request.ValidateInput();
}

微妙に違いますね。Microsoft.Web.Infrastructure.DynamicValidationHelperのValidationUtility.EnableDynamicValidationですね。誰や！？この旅、ここから長いです。長い割に身が無いです。できることはわかってるんだから。

先のブログエントリを、ちらっと見てるという前提で話を進めますが、MVC3だとHttpRequestのForm,QueryStringへのアクセスでもHttpRequestValidationException発生しますね。<httpRuntime requestValidationMode="2.0"/>はweb.configに入れてません。入れてないとASP.NET4ではデフォルトで全てのコレクションに対する検証がOnになるからです。

ASP.NET 4 Breaking Changes - ASP.NET Request Validation

ASP.NET 2/3.0/3.5と同じ挙動にしたいときだけ。<httpRuntime requestValidationMode="2.0"/>を指定しましょう。必要ないと思いますけど。んで、なんでここに手を入れてるのかというと、検証処理自体細かく制御できるように拡張ポイントを追加したからですね。requestValidationModeともう一つrequestValidationTypeというのも指定できるようになってますが、こっちで検証クラス(検証とずっと言ってるけど通常の入力検証じゃなくてリクエスト検証のことなので誤解しないでね！)を指定してカスタム出来るようになってます。

標準テンプレートのまま１つソリューションを作成します。HomeControllerのIndexで以下のようにQueryStringにアクセスするとします。

public ActionResult Index()
{
  var p1 = Request.QueryString["p1"];

  ViewBag.Message = "Welcome to ASP.NET MVC!";

  return View();
}

なんの変哲もないコードですね。これを実行してブラウザのアドレス欄に”?p1=<a>a</a>”なんていうのを足してアクセスしなおすと、例のエラーでます。そりゃそうです。The XSSです。

今度はそこに↓こんなずるいクラスを追加してrequestValidationTypeに指定。

using System.Web;
using System.Web.Util;

namespace ReqValidate.MVC3
{
  public class PassRequestValidator : RequestValidator
  {
    protected override bool IsValidRequestString(
        HttpContext context,
        string value,
        RequestValidationSource requestValidationSource,
        string collectionKey,
        out int validationFailureIndex)
    {
      validationFailureIndex = -1;
      return true;
    }
  }
}

ひどい。

このまま先のURLにもう一度アクセス。

同じようにダメそうなQueryStringを指定してるのに、今度はエラーになりませんでした。より厳しい条件を指定したいときなんかはカスタムすればいいですね。同じ仕組でRawUrlのチェックで許可したい文字を増やす事や、拒否したい文字を減らすこともできるでしょう。残念ながら標準でできるようになってるので、そんなことする意味は無いですけどね。

ASP.NET 4 and Visual Studio 2010 Web Development Overview - Expanding the Range of Allowable URLs

ただ、この辺突き詰めていけば、AllowHtmlにたどり着くのかというと、そうでもない、っていうね。なんでしょーね。この話、必要なかったですね。

話を戻すと、requestValidationModeが2.0の時と、4.0(デフォルト)の時での挙動の違いとして、チェックが有効になるタイミングの違いがあるようです。2.0だとBegineRequestではまだ有効になってなくて、4.0では有効になってます。

Global.asaxでブレークを仕掛けるとわかります。なるほど。Request.ValidateInput()でチェックフラグがオンになるので、以降のForm/QueryStringへのアクセスでチェックがかかるという仕組みです。

requestValidationMode=”2.0”の時。

Microsoft.Web.Infrastructure.DynamicValidationHelper.ValidationUtility.IsValidationEnabled(HttpContext.Current)で確認しましょう。

falseです。

なので、このタイミングで上記スクリーンショットのQueryStringを参照すると、XSSな値が入っていても、このタイミングではエラーとなりません。

でも、Request.ValidateInput()でマークフラグをセットすると、同じものが今度は例外となります。

続いて、同じコードでValidateInput()を呼ばずに、requestValidationMode=”4.0”の時。

IsValidationEnabledもtrueで、例外も起きます。

面白いのは、同じコードを続けて実行すると二回目以降は例外が発生しないところです。これは興味深い挙動ですね。

不思議な仕様ですねー。だって、この状態でも、Request.Unvlidated().QueryStringでオリジナルを取得することはできるんだから。過去の遺産だったりするのかなー。

やっと、本題。AllowHtmlを成立させるために必要なのはモデルのプロパティ名毎に検証を実施しないとダメですが、ここまでの流れで分かる通り、マッピング対象のコレクションにアクセスした段階で検証が発動する仕組みなので、このまますんなり行くとは思えません。がしかし、Reques.QueryStringやRequest.Formのアクセスは要素に関係なくエラーになるにもかかわらず、Actionへの引数となるマッピングの場合はマッピングが発生しない要素のにたいする検証は実施されてません。

どうやって実現してるんでしょうね。Form/QueryStringへのアクセスはすべて引っ掛けられてるなら途中介入するなんてできそうな気がしないです。

エントリを読み進めるとどうやら、コレクションが内部で保持しているArrayListとHashtableを置き換えてるようです。何と置き換えてるかはエントリの通り、LazyValidationArrayListとLazyValidationHashtableです。Microsoft.Web.Infrastracture.DynamicValidationHelper配下。だからといって、コレでも要素アクセスに限り検証し、プロパティマッピングでは検証しないというルールに繋がらないです。ふむむー。

改めてMVC3のソースを確認すると、そこにはIUnvalidatedRequestValuesと見慣れないインターフェースを使ったValueProviderたちがいました。あれれ？これの実装クラスがUnvalidatedRequestValuesクラスのインスタンスを内包したクラス。UnvalidatedRequestValuesといえば、Request.Unvalidated()で取得できる検証スキップコレクション。

さらに各種ValueProviderはNameValueCollectionValueProviderを派生したもので、IUnvalidatedValueProviderを実装してます。

public interface IUnvalidatedValueProvider : IValueProvider {
  ValueProviderResult GetValue(string key, bool skipValidation);
}

ははーん。見えてきましたね。MVC3からのValueProviderたちはコレを実装した形になっているので、マッピング対象の値をForm/QueryString等のコレクションから取得する際に、こっちのGetValueを呼び出すことで判断してるんですね。この中を少し見てみるとValueProviderResultPlaceholderを各ValueProviderからの戻り値とする際に、検証コレクションと未検証コレクションを切り替えて返す。

検証されるべきコレクションはインフラストラクチャの値をそのまま利用し、検証をスキップしたい時のコレクションはUnvalidatedRequestValuesを利用する。それをModelMetadataのRequestValidationEnabledから判定(AllowHtmlはここをセットするための属性クラス)。すっきりした！

途中出てきたLazyValidationArrayList/LazyValidationHashtableがインフラストラクチャが実施する検証を遅延してくれてるんだろーか。その辺はリフレクションとかしまくっててわかりにくし。FormやQueryStringにアクセスするとエラーが起きるのはそのままだから、なにが遅延かわかりにくいです。どーしてなーん？

こんな感じの実装になってるからAllowHtmlが成立するというのがわかったので良しとします。こうすることでWebPagesとも検証コードが同一のものにできるわけですね(WebPageHttpHandler.ProcessRequestInternalでEnableDynamicValidation)。この辺はSystem.Web.UI.Page派生じゃないものに対しても正しく検証を行うために必要なところですよね。Pageディレクティブないし。

ちょっとスッキリ。

DB Migration on EF4 alpha 3

noreply@blogger.com (たけはら) — Fri, 23 Sep 2011 02:21:00 +0000

Code First Migrations: Alpha 3 Released - ADO.NET team blog - Site Home - MSDN Blogs

EF.Migrationのアルファ3でた。前回はSQL CompactとSQL Expressへの依存が入ってたみたいで、ちゃんと動かせなかったけど、今回これは削除されたって。これでやっと試せる。

せっかくなので

↑この2つを試してみよう。

そのまえに！すでにEF4.1のパッケージをインストールしている場合は、削除するか最新版に更新しましょう。今回は削除したけど。これが残ってるとマイグレーションできないので気をつけてね。

まずはNoMagic(AutomaticMigrationsEnabled = false;)。書かれてる通りの操作をするとあれよあれよと、DBが更新されていく。

データベースが作られてBlogsテーブルが出来る。
Blogsにカラムとユニークインデックスの追加、Postsテーブルが追加。
Postsにカラム追加しつつ、カスタムのUpdate文を実行。

※黄色い箇所は手書きしましょう。

既存のデータベースにたいしての、途中からのマイグレーションはできないってさ。

どうやってトラッキングしてるのかというとCodeFirstではEdmMetadataユーザーテーブルだったのが、__MigrationHistoryシステムテーブルに引っ越して管理されてます。

Add-Migrationで変更分のコードを自動生成。差分は手で入力。DbMigrationの派生クラスが作成されるので、いかようにもいじれますね。ただ、どんなメソッドがあるんだろね。ドキュメント希望。どっかにあるけ？

Update-DatabaseでデータベースにSQL発行。-Verbose付けとくと発行されるSQLが実行時に確認できます。ただ、手元の環境では-Scriptがエラーで動きませんでした。SQLをファイルにしてくれるオプションのはずなんだけどなー．．．。

続いてMagic(AutomaticMigrationsEnabled = true;)。何がマジックかというと、Add-MigrationしないでいきなりUpdate-Database。すると、ちゃんとMigrationHistoryにAutomaticMigrationとしてレコードが作られて、テーブルも作成されている。凄いね。

カスタムSQLの実行や、カラム初期値を指定する場合なんかだと、コードに指定したメタから生成される情報からだと足りないから、手書きで足してたんだけど、Automaticだとどうするかというと、これがまた単純にAdd-Migrationを呼んで、空のマイグレーションファイルを作成(Up/Downが空)しておいて、そこに書きこんでいくだけ。適用はUpdate－Databaseで、ドーン！

面白いね。しかもコレ、途中経過のDbMigrationがいないのに、ちゃんとDownしていく。なんで？？-Verboseつけて実行すると、ちゃんと差分カラムの削除だけ実行してる．．．。まさにマジック！気持ち悪ーい。

でも、多分AutoMigrationはオススメしないかなー。何をやったのかの履歴が目で見てわからないもん。バージョン管理デキナイヨ！コードでするからやらないよ！？なのかな。

途中までTumblrで書いてたけど中途半端に長くなったので、こっちに移動しました。なのでスクリーンショットもなくてすいません。ただ！やればわかる！書いてることなぞるだけだし。MVC4のMobileチュートリアルよりよっぽどミスしないよ。

せっかくなのでお試しあれー。

あ、そうそう、結局EFのCodeFirstなのでデータベースを接続文字列ベースにしたいときは、App.ConfigにconnectionStringsを追加してその名前をDbContextの派生クラス(今回ならBlogContext)のctor : base(“名前”)とすればいいです。

IIS7でnode.js

noreply@blogger.com (たけはら) — Sun, 28 Aug 2011 13:21:00 +0000

Installing and Running node.js applications within IIS on Windows - Are you mad? - Scott Hanselman

node.jsをIISで動かす！ファイル更新で自動リサイクルは楽チンでいいですね！受け口がIISだからIISのその他の便利モジュールがそのまま使えるのもいい。

install.batでやってることも紹介してくれてるので、同じ手順でIIS Expressでも大丈夫！なはず。

iisnode.dllっていうネイティブモジュールが橋渡し。よさそうな雰囲気。プロセス数の設定とか、いろいろ調整できるのも素晴らしす。

と、いうわけで、試しに動かしてみました。

インストール手順。

node.jsのバイナリダウンロードしてc:\nodeにコピー
iisnodeのバイナリをc:\inetpub/iisnodeにコピー
※ソースから自分でビルドしても可
iisnode内のinstall.batを実行

以上。簡単ですね！node.exeのパスを変えたい場合は、install.batの確認場所の変更と、web.configでnodeProcessCommandLine指定でどーぞー。

なんかいいね。6000req/sec。たいしたもんだ。ただ、iisnode.dllがちょいちょい落ちる(アプリケーションプールごと道連れ)。まだまだ発展途上。でもネイティブモジュールのスゴさを垣間見れるし、手軽にnode.jsをWindows環境で走らせることが出来ていいです！

ちなみにハンセルマンさんのエントリでも書いてる通り、AppPoolのアカウントをLocalSystemにしとかないと動きません。あと、wcatのsettings.ubrはちゃんとsettings{}で囲んでおきましょう。wcatについてはよく知りませんが(すません)、wcclientが動いてくれなくて、ちゃんと走りませんでした(手動起動で動かした)。

こんなに簡単にできるなら、何か面白そうなことを考えて試してみたり、node.jsでできることいろいろ追いかけて見たくなりますね！

HighPerformanceSessionStateProvider

noreply@blogger.com (たけはら) — Fri, 19 Aug 2011 09:08:00 +0000

ASP.NET Univarsal Providers のセッションプロバイダを使ってみる (2) « ブチザッキ

カメさんのこのエントリーに対してこんなコメントをしてみたわけですが、具体的なコードを提示しないで案だけ出すって、そんな失礼なことがあっちゃいけねー。江戸っ子なら宵越しの銭はもってちゃいけねー。江戸っ子じゃないんですけどね。

まずは現状確認。カメさんのコードをいただきつつ。ASP.NET MVC3のサイトをデフォルトで作成。ASP.NET Universal ProvidersをNuGetでインストール。web.configでSessionStateの設定をCookieless="UseUri"とTimeout="1"に変更(検証が簡単だからね)。

using System;
using System.Net;

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
      System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();

      GetPage();

      int count = int.Parse(args[0]);

      for (int i = 0; i < count; i++)
      {
        sw.Reset();
        sw.Start();
        var success = GetPage();
        sw.Stop();
        Console.ForegroundColor = success ? ConsoleColor.White : ConsoleColor.Red;
        Console.WriteLine("{0}\t{1}\t{2}\t{3}", 
            DateTime.UtcNow.ToString("yyyy/MM/dd hh:mm:ss.fff"), 
            sw.Elapsed, i, success ? "OK" : "NG");
      }
    }

    static private bool GetPage()
    {
      var result = true;
      try
      {
        var request = WebRequest.Create("http://localhost:52855/");
        {
          using (var response = request.GetResponse())
          {

          }
        }
      }
      catch
      {
        result = false;
      }

      return result;
    }
  }
}

ずるくないもん！オマージュだもん！

コレとMVCサイトで実行した結果(クリックでズーム)。

セッションを生成するコンソールは3個でCPUはMAX。白行はエラーなく進んだところで、赤行はASP.NET側でエラーになったところ。

1分でセッションは切れるので、1分後からドカドカ古いセッションの削除が始まります。

概ね680セッションあたりで飽和。エラーと正常実行を繰り返す感じです。切ないですね。セッションの削除が同時実行されててんやわんやな例外。

これを解消するために、InitializeRequestをoverrideしたSessionStateProviderクラスを定義します。

やることはSessionsテーブルにExpires列のインデックスがなければ作成と、セッション初期化時の有効期限切れセッションの削除をEFのDeleteObjectじゃなくSQLのDelete文を実行するように。

ちょっと長いですけど。

using System;
using System.Configuration;
using System.Data.Common;
using System.Reflection;
using System.Web;
using System.Web.Providers;
using System.Web.Providers.Entities;

namespace UniversalProviders
{
  public class HighPerformanceSessionStateProvider : DefaultSessionStateProvider
  {
    private string _connectionStringName;
    private bool _initialized = false;

    public override void Initialize(string name, System.Collections.Specialized.NameValueCollection config)
    {
      _connectionStringName = config["connectionStringName"];

      base.Initialize(name, config);
    }

    private void ExecuteSql(ConnectionStringSettings connectionStringSettings, Action<DbProviderFactory, DbCommand> functor)
    {
      var providerName = connectionStringSettings.ProviderName;
      var factory = DbProviderFactories.GetFactory(providerName);
      using (var connection = factory.CreateConnection())
      {
        connection.ConnectionString = connectionStringSettings.ConnectionString;
        connection.Open();

        var command = connection.CreateCommand();

        functor(factory, command);
        command.ExecuteNonQuery();
        connection.Close();
      }
    }

    private void CreateSessionIndex(ConnectionStringSettings connectionStringSettings)
    {
      ExecuteSql(connectionStringSettings, (factory, command) =>
      {
        command.CommandText = @"IF not EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(N'[dbo].[Sessions]') AND name = N'IX_Sessions')
begin
CREATE NONCLUSTERED INDEX [IX_Sessions] ON [dbo].[Sessions] 
(
[Expires] ASC
) ON [PRIMARY]
end
";
      });
    }

    private void RemoveExpiredSessions(ConnectionStringSettings connectionStringSettings)
    {
      ExecuteSql(connectionStringSettings, (factory, command) =>
      {
        command.CommandText = "delete Sessions where Expires < @0";
        var parameter = factory.CreateParameter();
        parameter.ParameterName = "@0";
        parameter.Value = DateTime.UtcNow;
        command.Parameters.Add(parameter);
      });
    }

    private MethodInfo GetCreateSessionEntities()
    {
      var modelHelper =
        Assembly.GetAssembly(typeof(Session))
                .GetType("System.Web.Providers.Entities.ModelHelper");
      return modelHelper.GetMethod("CreateSessionEntities", 
        BindingFlags.NonPublic | BindingFlags.Static);
    }

    public override void InitializeRequest(HttpContext context)
    {
      var connectionStringSettings = ConfigurationManager.ConnectionStrings[_connectionStringName];
      if (!_initialized)
      {
        var initializer = GetCreateSessionEntities();
        initializer.Invoke(null, new object[] { connectionStringSettings });
        CreateSessionIndex(connectionStringSettings);
        _initialized = true;
      }

      RemoveExpiredSessions(connectionStringSettings);
    }
  }
}

クラス名はもちろんHighPerformanceSessionStateProviderデス！

Web.configも上記のように変更しちゃいましょう！customProviderの指定がDefaultSessionProviderでオリジナルに戻ります。

セッションが飽和するのが、940件くらいのところです。もちろん例外なんて起きませんよ。有効期限切れのレコード削除なんて何回実行したって、無いものはない！潔し！ちなみに先程の数値もそうですけど、コレが同時実行の限界値なわけではないです。マイノートPCの同時実行の限界くらいです。Webの受付のね。DbProviderFactoriesを利用することでEFと同じだけのポータビリティ(言い過ぎ)。

名前ほど早くないけど、エラーが起きないから実用的なんじゃん？読み込み性能は気にしてないでーす。あくまで新規セッション作成時のパフォーマンス向上委員会です。言い訳がましい．．．。

ご利用は計画的に！

Azureでは動かしてないので、そちらの検証はたぶんカメさんがその３でやってくれるんじゃないでしょーか。

Controllerを名前から生成するしHTMLを書き換えたりもしてみる

noreply@blogger.com (たけはら) — Sun, 14 Aug 2011 11:31:00 +0000

Developer @ ADJUST : ASP.NET MVC のコントローラクラスを、コントローラ名から取得したいのだけれど...結局、ぜんぶ列挙!?

前回のエントリーからはや１ヶ月以上経過したこのブログ。エアコンが壊れてて、バリバリ節電に貢献できてる気はするけど、辛い毎日でブログどころではないですよ！

で、坂本さん、上記の件ですが以下のような方法はいかがでしょうか。単純に型が欲しいだけならインスタンスは不要なので無駄な感じはしなくもないですが。必要なのがインスタンスであれば一番いい方法だと思います。

var factory = ControllerBuilder.Current.GetControllerFactory();
var controller = factory.CreateController(Request.RequestContext, "Home");
var type = controller.GetType();
factory.ReleaseController(controller);

コレと言って、自信で発明したものはなく、やってることはMvcHandlerでやってることと同じです。MvcHandlerってあれです、MvcRouteHandlerが返してくるIHttpHandlerのことです。

内部でタイプキャッシュとかしてくれてるので、パフォーマンスには自信があります！あると思います！

ここから別件。

もう暑さで脳みそが働かない．．．。けど、これだけじゃ坂本さんも納得しないと思うので、全然関係ない面白い機能紹介。といっても、URLRewrite 2.0の機能です。ハイパフォーマンスWebサイトの構築には必須のOutputCacheなんですが、クローラーなんかはUser AgentがCookieに対応してないと言ってくるじゃないですか。browserファイルで対応するのが王道ですが、それだと追従していくのが大変面倒くさい。

Creating Outbound Rules for URL Rewrite Module : URL Rewrite Module 2 : URL Rewrite Module : The Official Microsoft IIS Site

想定している状況を簡単にいうと、SessionのcookielessはuseDeviceProfile。PCサイトとケータイサイトを同一アプリケーションで実行。PCサイトは積極的にOutputCacheを利用し、ケータイサイトでは消極的(Viewでは使わない)に利用。この場合、PCサイトにクローラが来るとそのままではCookielessとしてセッションが生成されるので、OutputCacheにSessionIDを保持したHTMLが出力されてしまって都合悪い！

ということなんですが、伝わるでしょうか．．．。

OutputCacheをVaryByUserAgentにするのも手ですね。いろいろ方法はあると思うんですけど、こないだ試したのがPCサイトの場合、出力されるHTMLにSession IDが含まれることが正常系ではありえないので、PCサイトの場合、Response.FilterでURLにSession IDが含まれてたら消してしまうという方法。Response.Filterでやるよりももっと簡単なのがURL Rewrite 2.0の出力書き換えを利用するっていう方法。どうですか、面白そうじゃないですか？

ちなみにOutbound Rule用に独自Provider書いたりもできるけど、そこまでやることはあんまりないかなー、と思いますがどうでしょう。

<rewrite>
  <outboundRules>
      <rule name="Sessionless" preCondition="html" enabled="true">
          <match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script, CustomTags" customTags="All" pattern="(.*)/\(S\([0-9a-z]+\)\)(.*)" />
          <action type="Rewrite" value="{R:1}{R:2}" />
          <conditions>
              <add input="{REQUEST_URI}" matchType="Pattern" pattern="\)/mobile" ignoreCase="true" negate="true" />
          </conditions>
      </rule>
      <customTags>
          <tags name="All" />
      </customTags>
      <preConditions>
          <preCondition name="html">
              <add input="{RESPONSE_CONTENT_TYPE}" pattern="text/html" />
              <add input="{REQUEST_URI}" pattern="/mobile" negate="true" />
          </preCondition>
      </preConditions>
  </outboundRules>
</rewrite>
<urlCompression doDynamicCompression="false" />

だいたいこんな感じの設定です。これをWeb.configに書いておきましょう。system.webServer配下です。ケータイサイトが/mobile配下という前提です。

実験。MVCサイトをデフォルトのまま生成し、Web.configに上記設定を追加しないで動作を確認。

この状態で出力されるのは↓。

そりゃそうですね。中身は↓。

なんてことないですよね。

今度はsessionStateのcookielessをUseUriにしてみましょう。見た目は同じなのでソースだけ。

画像をクリックして大きくしてみるとわかりますが、Session IDを含んだURLですよね。

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>Home Page</title>
    <link href="/(S(f4grns0hiatkwquk55qulbmd))/Content/Site.css" rel="stylesheet" type="text/css" />
    <script src="/(S(f4grns0hiatkwquk55qulbmd))/Scripts/jquery-1.5.1.min.js" type="text/javascript"></script>
    <script src="/(S(f4grns0hiatkwquk55qulbmd))/Scripts/modernizr-1.7.min.js" type="text/javascript"></script>
</head>
<body>
    <div class="page">
        <header>
            <div id="title">
                <h1>My MVC Application</h1>
            </div>
            <div id="logindisplay">
                    [ <a href="/(S(f4grns0hiatkwquk55qulbmd))/Account/LogOn">Log On</a> ]
            </div>
...以下省略

今度は先のURLRewrite設定をOnにした場合。

あら素敵。ウソじゃないよ！URLにはちゃんとSession ID入ってるでしょ？

これでクローラが来てもOutputCacheにへんてこなものが仕込まれることないですね！あと、動的圧縮をオフにしてるのは既知です。設定いいんですけど今回はこれで。

役に立つやら立たないやらな情報でした！

全角数値を半角数値に変換するModelBinder

noreply@blogger.com (たけはら) — Thu, 30 Jun 2011 03:45:00 +0000

拝啓、まゆきっつぁん

いつも、The Shodoにて筆の練習をさせていただいてます。ただ、いつまで経っても筆ぺんでは上手にかけるようになれません。本物の習字道具を使わないと練習の成果が出ないのでしょうか？The Fudepenで練習すると効果が期待できるかもしれないですね。是非、考慮いただければと思います。

先日のmvcConf @:Japan懇親会での一件について。ふと、思い出したので書いてみました。あの時はValueProviderがどうのこうのという話になったような気がしないでもないですが、ValueProviderではレイヤ低すぎて型は意識されてないのダメですね。

こんな感じでいかがでしょうか？整数に限定してますが、応用すると他にもいろいろできると思います。

public class IntegralModelBinder : DefaultModelBinder
{
  private readonly List<Type> _integralTypes = new List<Type>
  {
    typeof (sbyte),
    typeof (byte),
    typeof (char),
    typeof (short),
    typeof (ushort),
    typeof (int),
    typeof (uint),
    typeof (long),
    typeof (ulong)
  };
  private const string WideIntegrals = "１２３４５６７８９０一二三四五六七八九零壱弐参肆伍陸柒捌玖零";
  private const string NarrowIntegrals = "123456789012345678901234567890";

  protected override void SetProperty(ControllerContext controllerContext, ModelBindingContext bindingContext, PropertyDescriptor propertyDescriptor, object value)
  {
    if (!_integralTypes.Contains(propertyDescriptor.PropertyType) || value != null)
    {
      base.SetProperty(controllerContext, bindingContext, propertyDescriptor, value);
      return;
    }

    var providerResult = bindingContext.ValueProvider.GetValue(propertyDescriptor.Name);
    value = providerResult.AttemptedValue;

    var narrow = string.Join("",(value + "").Select(c => WideIntegrals.Contains(c) ? NarrowIntegrals[WideIntegrals.IndexOf(c)] : c));
    var converter = TypeDescriptor.GetConverter(propertyDescriptor.PropertyType);
    try
    {
      value = converter.ConvertFrom(narrow);
      bindingContext.ModelState.Remove(propertyDescriptor.Name);
    }
    catch{}

    base.SetProperty(controllerContext, bindingContext, propertyDescriptor, value);
  }
}

試しに以下のようなモデルを定義してみました。

    public class Person
    {
        public string Name { get; set; }
        public int Age { get; set; }
        public DateTime? Birthday { get; set; }
        public byte Rank { get; set; }
    }

AgeとRankが整数型なので処理対象となります。Global.asaxでDefaultBinder(ModelBinders.Binders.DefaultBinder = new IntegralModelBinder();)を差し替えて実行した結果は↓こんな感じになります。

@model ZenBinder.Models.Person
@{
    ViewBag.Title = "ホーム ページ";
}

<h2>@ViewBag.Message</h2>

@using (Html.BeginForm())
{
    @Html.EditorForModel()

    <button type="submit">送信</button>
}

まずはフォームを出すでしょう。簡単にEditorForModelを使います。

普通に半角だけで試して送信してみると、ちゃんと動きます。同じものを全角にしてみても結果は同じになります。

変換出来ない場合はDefaultModelBinderの挙動になります。十とか百とか千も変換するためのマッピングを用意すれば、もう少しオシャレさが増すかもしれないです。

いかがでしょう。ケータイでの入力に是非応用してみてください。

mvcPhotosの出来るまで

noreply@blogger.com (たけはら) — Fri, 17 Jun 2011 15:02:00 +0000

ちょっと書いてみます。あんまり面白く無いですよ。

ASP.NET MVCをメインにした企画をやってみたいとチャックから連絡があって、喋る人が決まったところで各々にテーマがふられました。んで、たけはら担当として「クライアントサイドのテクノロジをメインに扱うセッションを」というリクエストから始まるんですが、ぶっちゃけ「それMVC関係ないじゃない．．．」と愕然としたものです。

とはいえ、テーマを無視するのもあれだからと、まずはセッション概要を伝え(もちろんこの時にはまだ何をするのか決めてないので、ぼかしまくった感じで)募集開始。そろそろ真面目に考えないとね～、と思いつつ仕事も忙しかったしで、ほっといたらあっという間に5月中旬。そろそろスライドだけでも書かねばと書き始めるものの、何を作るかは全く決まらず．．．。とりあえずの方向性としては

作ったものに参加者もその場でアクセスできる(だけど会場内のネットワークでは自マシンに参加者がアクセス出来ないはず)
アーキテクチャを意識する
MVC使いつつクライアントサイドモリモリ
コードは参加者へのプレゼント

の４点。

※ネットワークについては、昨年のTechEDでダメだったのを経験してたので。

はてさて、どうしたものか。Twitterは他の人が絶対利用するだろうからパス。単純に外部サーバーにWebアクセスしてみんなでワイワイする感じで何がいいかな～、って考えるとどうしてもMvcGraffiti(みんなでお絵かき)とかぶる。となると、手堅い方法はメールか。ケータイなら絶対繋がるはず。メールということはPOP3の実装は必要だな～。メールなら写メがいいかも。という流れでとりあえずPOP3の実装と画像のリサイズ部分だけ先行コーディング。

いろいろ悩んだ挙句、普通に写真共有っていうところに落ち着くんだけど、どうやってクライアントサイドモリモリを達成するか。そこは後回しにしてアーキテクチャ。この時点でAppHarborをプラットフォームにして、ストレージはGoogle Storage使ってみようかと実験。でもGoogle Storageが思ったようにいかないからS3にチェンジ。モデルはCodeFirstで、ストレージは置き換えられるようにProviderとして実装。MVCでのサーバーサイドはシンプルにAPI的なものと、UA切り替え出来るような仕組みをどうするか考えつつ、ワーカーによるバックグラウンド処理でメールとストレージのつなぎをやろうと決める。UAに合わせてViewを切り替えるのはいろんなやり方があるけど、出回ってるやり方を実装してもつまらないので、随分悩んだ末にRoutingとViewEngineのコンビネーションで行う方法を思いつく。さすがオレ。

クライアントサイドはこのころすごく気になってたknockout.jsとModernizrを使うことで、うまいことやろうと思いつつ具体的なことは決めずにサーバーサイドをゴリゴリ作る。あと、それっぽくテストコードも用意することで、スタックというかレイヤというか、その辺を意識しやすいようにしておこう。

ちょっと横道にそれますが、ControllerのテストをしやすくするためにFormCollectionをパラメータに使う例をよく見ますね。でも意味ないですよね。そこは普通に入力モデルを渡せばいいじゃないっていうふうに思うわけですよ。だって、FormなりのValueProviderからModelBinder経由した入力モデルへのマッピングって、Controllerのテストじゃ無いからですよ。通常のFormを想定した場合、FormCollectionからUpdateModelをするなら、それはもうMVCが提供してくれるModelBinderのテストをするようなもんでしょう。意味無いじゃん！なので、ModelBinderのテストはMVCの開発チームに任せて、自分たちの書いたコードに対するテストを書きましょう。ただ、今回Controllerのテストは書いてないですけどね！てへ。

ここまで全然コード解説じゃないですけど、セッションで話したいのはそもそも製品の紹介じゃなくて「アプリケーションの作り方」。何をどういう設計で作るかを決めることで詰みです。「拳(コード)で語る」のがプログラマーですよ。だって、ASP.NET MVCも１～３へと進み、４以降になったら製品の使い方、コードの書き方なんて変わるわけですよ。Razorなんてものも出てくるし。だけど、考え方とか適用の仕方ってMVCっていうアーキテクチャスタイルとか、デザインパターンとかって基礎として使い続けるじゃん？そこ意識すること大事だと思うんす。

ただでも、このやり方は諸刃で、聞きに来てくれる層によってはドン引きされるんです(経験あり)。だって「お前の作ったアプリケーションを見に来たんじゃないんだよ！」とか「そのアプリでオレのプロジェクトは解決できない！」という意見もあるからね。いろいろです。どんな意見も、それぞれの人のコンテキストでは正論っす。ただ、自分にとっては、目の前の問題の答えを提示する局所最適じゃなく、全体最適を目指すほうが楽しい。なので、これからもこのやり方は変わらないでしょう。

はっ！熱くなってた！しっけいしっけい。

サーバーサイドが概ね出来たところで、クライアントサイドの実装に入るわけですが、PC,iPad,iPhone、そして日本が誇る超精密パーソナル通信機器、通称ガラケー対応も無視できない。モダンブラウザ向けにはjQuery Mobile使おうと思ってたんだけど、Azure担当大臣のだいちゃんが「jQuery Mobileでモテモテになるっす！」とか言い出しやがって、かぶるじゃねーかよ、的なね。まぁ、いいか。んじゃ、オレ適当に実装する、ということになりました。なので、見た目かなりしょぼくなったけど、オレのせいじゃないから！エロ大臣のせいだから！！Azureチーム金持ってるからって可愛いキャラ多すぎなんだよ。ASP.NET界隈では緑のキグルミしかいないっつーの。羨ましくなんか．．うっぐ。泣かない。

はいはい。クライアントサイドでどういう感じに動かすのか、図に書いて最初に実装したのが、↓こんなやつ。

受信画像をタイル状にランダム表示。緑も意識してみた。だけどコレがまたダサいのなんのって。イメージ通りに作ったはずなのに。自分のセンスに絶望。

ランダムがだめなのかと思って順番に表示するようにしたりしたけど．．．。根本的におかしい。マジやべー。

色がだめなのか！？と思って黒くしてみた。

で、最終的には↑こうなるんだけど、みんな知ってた？ウィンドウサイズに合わせてサムネイルの画像サイズは１００→５０→２５と収まりよくなるようにリサイズするんだよ？

http://mvcphotos.takepara.com/

試してみてね。

ソースはこちら。

http://mvcphotos.codeplex.com/

Source Codeタブをクリックして右端のLatest VersionにあるBrowseで見たり、Downloadで取得してね。

書き疲れた．．．。もういい？仕様書もマニュアルもなしで、コードを追いかけるのも大変だと思うので、今回作成したmvcPhotosの実装をザックリ書きだしておきます。

POP3でメール受信
クラウドストレージとローカルストレージを切り替えやすくするためのストレージプロバイダ化
画像のリサイズ
EF CodeFirstによるDAL
データベースアクセスをRepositoryにより抽象化
サーバーサイドでもDAL用のモデルと、入出力用のモデルを分けることでレイヤ分離と検証ルールの明確化
動的画像リサイズを行うためのコンカレント制御と非同期Controller
複数のUserAgentを同一Controllerで処理するためのViewEngineとRouting制御
モダンブラウザの判定と、動的スクリプト読み込みにModernizr
knockout.jsによるクライアントサイドでのMVVM実装
自作Service Locatorと、DependencyResolver実装
DIを３パターン実装(探してみてね！)

こんな感じです。

ちなみにパネルディスカッションの最後でゴニョゴニョ言ってたことなんですけど「大事なのはMVCの心を理解しようとし、SoC - Separation of Concerns - 関心の分離を意識すること」。つまりきちんと役割を分離して、実装も可能なかぎり分離して参照関係を単純にしましょうね、と言いたかったですが言葉足らずのドヤ顔で失礼しました。

あと、一色さん、変なやりとりでスマセンした。失礼ぶっこいてスマセンした。ホントはすごいシャイボーイなんです。自分で言うのもなんですが、草食系男子なんです。型は古くて時化には強いタイプですけどシャバいやつなんす。

今後ともご贔屓に～。

メモ帳ですいません

noreply@blogger.com (たけはら) — Mon, 13 Jun 2011 13:00:00 +0000

mvcConf @:Japanでしゃべりましたね。あまりにも大雑把な説明っぷりに自分でもビックリです。オレ、こんなに雑だったんだ．．．もっと繊細だと思ってた。なんつっ亭たけはらです。

雨の中、足を運んでくれたたくさんの参加者の方々に感謝の気持ちでいっぱいです。

mvcConfといえば、知る人ぞ知るマニアにはたまらないイベントです。それを日本で日本人だけで、ASP.NETバカ集合させてしゃべらせようと企んだチャックの度量には度肝を抜かれました。初めての試みだし、人が集まるのか、どのような背景の人が参加してくれるのか全く未知数で、ランチも交通費もでないという低予算のなか、よくもまぁなんとかなったもんですね。

個人的には全然言いたいことがいえずに、あっという間に終わってしまったので、ブログを通して言い足りなかった部分、特にサンプルに盛り込んでいるテクノロジや設計方針なんかを、ちょびっとだけ書き残しておこうと思います。

まず当日、スライドの内容が思い出せるきがしなかったので、メモを書きました。それがコレ↓です。

mvcPhotos

http://mvcphotos.takepara.com
http://mvcphotos.takepara.com/mobile

mvcphotos@takepara.com

サイトURL設計

Home
    Index
Photos
    Index - Jsonable
    Tags – Jsonable
    Create (GET/POST)
    Image
Tags
    Index – Jsonable
※/mobile配下も同じ

アーキテクチャとしてみるWeb Stack

ViewEngineでのView切り替え
同一コントローラを利用する
knockoutjsを使ってMVVMなクライアントサイド実装
Modenizrでのブクライアントサイド機能判定
Modernizr.load活用
クラウド利用によるスケール、可用性の確保
AppHarborとAWS
メールを利用したデータ入力
サーバーサイドを極力API化
ODataを出力しdatajsで取得する。
テスト
少しずつでいいからテストも書いていこうね
Mockじゃなくても、StubやFakeを用意する。
razordo.it / guttokita.ccもよろしく！

参照ページ

IS 7.0 における ASP.NET アプリケーションのライフサイクルの概要
http://msdn.microsoft.com/ja-jp/library/bb470252.aspx
ASP.NET ページのライフサイクルの概要
http://msdn.microsoft.com/ja-jp/library/ms178472.aspx
ASP.NET 2.0 Provider Model: Introduction to the Provider Model
http://msdn.microsoft.com/en-us/library/aa479030.aspx
HTML5 Showcase for Web Developers: The Wow and the How
http://www.htmlfivewow.com/
Architecture Center - MSDN -
http://msdn.microsoft.com/es-es/architecture/en/
The art of simplicity: Using the AsyncController in ASP.NET MVC 2
http://bartwullems.blogspot.com/2010/01/using-asynccontroller-in-aspnet-mvc-2.html
Last Call: W3C Invites Broad Review of HTML5 and Five Related Specifications
http://www.w3.org/News/2011.html#entry-9105
HTML5と関連仕様がラストコール（最終草案）となる。W3Cが幅広いレビューを募集－ Publickey
http://www.publickey1.jp/blog/11/html5w3c_1.html
20 Things I Learned About Browsers and the Web
http://www.20thingsilearned.com/ja-JP
DependencyResolver
Brad Wilson: ASP.NET MVC 3 Service Location, Part 1: Introduction
http://bradwilson.typepad.com/blog/2010/07/service-location-pt1-introduction.html
Fun with ASP.NET MVC 3 and MEF | MIX11 | Channel 9
http://channel9.msdn.com/events/MIX/MIX11/OPN07
WebFormでの開発はページコントローラパターン
ページコントローラ
http://msdn.microsoft.com/ja-jp/library/ms978764.aspx
ASP.NET でのページコントローラの実装
http://msdn.microsoft.com/ja-jp/library/ms998548.aspx
InfoQ: モバイル開発についての調査
http://www.infoq.com/jp/news/2011/05/A-Survey-on-Mobile-Development
単体テスト: テスト代替の連続性について検討する
http://msdn.microsoft.com/ja-jp/magazine/cc163358.aspx

ココまで。

Jsonableは渾身の仕込みだったけど、響かなくて残念でした。

リンク多いけど、参考になるサイトばかりで紹介しておきたかったのでメモに書いてました。気が向いたらのぞきに行ってみてはどうでしょう。

パネルディスカッションで「Page Controller」がどうのこうの言ってたんですけど、なんとなくPageとControlと聞き間違いされてる気がしたので改めて「Page Controller」デス！

実装サンプルを用意して適用方法を解説しようというセッションなので、最初からセッション資料なんてこれだけでよかったかも。今度からそうしようかな。技術的な解説よりもライブコーディングをいれたほうがピンと来やすいかもしれないしねー。「御託はいいよ・・・拳で語ってくれ」と誰もが思ったことでしょう。

次のエントリはコード解説を書こうと思います。が、途中でギャー！ってなってポイってしても、そこは笑って許してね！

ClayFactory

noreply@blogger.com (たけはら) — Sun, 05 Jun 2011 01:08:00 +0000

Clay面白いかも！

NuGet Package of the Week #6 - Dynamic, Malleable, Enjoyable Expando Objects with Clay - Scott Hanselman

Clay - Home

ORM使ったリポジトリを使った場合、戻りの型って結構融通効きにくいじゃないですか。select対象のクラスを全部手書きするのかよ、って。だからといって無名クラスは戻せないじゃない。objectでリフレクションとか本末転倒。

なのでdynamicを使うことにするんですけど、そのためにLINQ selectの射影をdynamicにする簡単なヘルパーを用意しとくと便利ですね。

public static class ObjectToDynamicExtensions
{
  public static dynamic ToDynamic(this object obj)
  {
    dynamic model = new ExpandoObject();
    var properties = obj.GetType().GetProperties();
    foreach (var property in properties)
    {
      ((IDictionary<string, object>)model)[property.Name] = property.GetValue(obj, null);
    }
    return model;
}
}

使用例

return from person in db.People
       select new {
         FullName = person.FirstName + 
                    " " + 
                    person.LastName,
         Age = ((DateTime.Today.Year*10000 + 
               DateTime.Today.Month*100 + 
               DateTime.Today.Day) - 
               (person.Birthday.Year*10000 + 
               person.Birthday.Month*100 + 
               person.Birthday.Day))/10000
       }.ToList().ToDynamic()

使い道はこんな感じのマッピングなんですけど、ここでちょっと残念なのが、ASP.NET MVCのViewにdynamicを渡すと、ほとんどのヘルパーが機能してくれないこと。残念ですね。凹みますね。

ちゃんと型付けしとけ、っていうのはもちろんそうなんですけどね。だからScaffoldingもあるわけでして。

とは言え、柔軟な実装にしたい。単純にマッピングをしたいようなときにはClayいいかもという流れです。

dynamicをインターフェース実装のプロキシに変換してくれるみたい。そうなればもう強い型付け完了。

インターフェースは規約で判定するみたいだけど、namespaceどうするんだろ。気になる。あ、でも、Entity ModelとOutput Modelを両方共クラスにするんじゃなくて、Output Modelはインターフェースにしちゃう感じなのかな。

dynamicから特定のインターフェースに変換したくなるときって、よくあるきがしてきた！ワクワクするね！

@RenderPageとHtml.RenderPartial

noreply@blogger.com (たけはら) — Fri, 06 May 2011 05:30:00 +0000

いや～、連休ももうすぐ終わってしまうと思うと、ちょっぴりアンニュイな気持ちになってしまいます。アンニュイってララバイくらい意味がよくわからない。

Razor使ってますか？使ってますよね。お腹すいたらRazorだし、テレビ見ながらRazorですよ！

疲れてるのかな．．．。

~/Views/Shared/_Partial.cshtml

@{
    var message = Model ?? (PageData.Any() ? PageData.First().Value : null);
}
ゴールデン @message

↑こんな部分ビューを用意しました。

~/Views/Home/Index.cshtml

@{Layout = null;}
<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="utf-8" />
    <title>連休</title>
</head>
<body>
<p>@@RenderPage - 
  @RenderPage("~/Views/Shared/_Partial.cshtml", "ウィーク")</p>
<p>Html.RenderPartial - 
  @{Html.RenderPartial("~/Views/Shared/_Partial.cshtml", "ウィーク");}</p>
<p>Html.Partial - 
  @Html.Partial("~/Views/Shared/_Partial.cshtml", "ウィーク")</p>
</body>
</html>

↑そしてそれを利用するビューも用意しました。

ここで問題です！このページ(Index.cshtml)を表示するとどういう表示になるでしょーか？

答え

ビックリした？ねーねー、ビックリした？オレ、すげービックリした。

なんでHtml.RenderPartialだと”ゴールデンウィーク”と表示されないんでしょうね。ソース追っかけたりしてスゴイ悩んだんですよ。そもそもRazorではストリームに直接出力うするHtml.RenderPartial使えないのか！？とか仕様を疑ったり(RenderPartialの実装がMVC3になってTextWriter渡す実装に変わってるから関係ないのにね)。

うーん、煮詰まった。ふと、順番入れ替えたらどうなるのか試してみたんす。

<p>Html.RenderPartial - 
  @{Html.RenderPartial("~/Views/Shared/_Partial.cshtml", "ウィーク");}</p>
<p>Html.Partial - 
  @Html.Partial("~/Views/Shared/_Partial.cshtml", "ウィーク")</p>
<p>@@RenderPage - 
  @RenderPage("~/Views/Shared/_Partial.cshtml", "ウィーク")</p>

@RenderPageを最後に移動。

おや～？ちゃんと出た。あれ～。この際Html.Partialは無視して試しに親戚のHtml.RenderActionはどうなるのか試してみたっす。

HomeControllerに以下を追加。

[ChildActionOnly]
public ActionResult Week()
{
    return Content("ウィーク");
}

Index.cshtmlを以下のように変更(@RenderPageを最初に持って来てHtml.RenderAction追加)。

<p>@@RenderPage - 
  @RenderPage("~/Views/Shared/_Partial.cshtml", "ウィーク")</p>
<p>Html.RenderPartial - 
  @{Html.RenderPartial("~/Views/Shared/_Partial.cshtml", "ウィーク");}</p>
<p>Html.RenderAction - 
  ゴールデン @{Html.RenderAction("Week");}</p>

Html.RenderActionは平気みたい。このまま@RenderPageを最後に移動。

<p>Html.RenderPartial - 
  @{Html.RenderPartial("~/Views/Shared/_Partial.cshtml", "ウィーク");}</p>
<p>Html.RenderAction - 
  ゴールデン @{Html.RenderAction("Week");}</p>
<p>@@RenderPage - 
  @RenderPage("~/Views/Shared/_Partial.cshtml", "ウィーク")</p>

ちゃんと出ますね。ということはですよ、同じWebPage中では@RenderPageした後はHtml.RenderPartialが正しく動かないということですよ。これってもしかして．．．。あ、いや、仕様かもしれないし。どういう事？教えてWebMatrixMan～！

※@RenderPage自体がRazor構文なのでWeb Formsでは関係ない問題です。

ぷっすぷすにしてやんよ、Glimpseで。

noreply@blogger.com (たけはら) — Wed, 04 May 2011 07:59:00 +0000

Glimpse - A client side look at whats going on in your server

なんと素敵なツールでしょうね！

↑ChromeでGlimpseをオンにしたうえに、デベロッパーツールもオンにした状態。かぶせまくり。

これ何？っていうのは上記Glimpseサイトのビデオか、MIX11でのHanselmanさんのセッションビデオ見れば一発でわかります。と言ってしまうとブログに書く必要が無くなってしまうので、少し説明すると、Trace.axdやelmah.axd、RouteDebuggerを全部ひっくるめて組み合わせてさらにサーバーサイドの情報をひと通り参照できるようにするツールデス。分かりにくいっすね。

とにかく、NuGetでInstall-Package Glimpseと入力してプロジェクトに入れて見ましょう。

その状態でデバッグを開始すると、おや？ナニも変化ないですね。なので、URLに/Glimpse/ConfigといれてGlimpse機能をOnにしまいしょう。Onにした後はURLをもとのページに自分で戻すことを忘れずに。

そうすると画面右下に変な目玉アイコン(Glimpseアイコンね)が表示されるのでそこをクリック！

そうすると出てきます。

すごいねー。ちなみにブラウザに表示されてるのはプラグインとかじゃなくて100％JavaScriptだけで作られたものです。

ソース表示すると</html>の後にデータがレンダリングされて、最後にglimpseClinet.jsがロードされてるのが確認できます。

あとは、見たまんまです。各タブにそれぞれ情報が表示されます。

Binding
まだ開発中～。Binderの情報がでる予定(だと思います)
Config
Web.Configの設定内容をセクション別に表示
Environment
サーバーの実行環境の情報
Application Assemblies/System Assembliesが見れるのは嬉しいですね
Execution
ActionInvokderの実行内容を表示(だと思う)
Filterの実行も見れるよ！
Glimpse Warnings
Glimpseの何か
MetaData
どこぞのMetadata
Remote
リクエスト履歴っぽい
Request
HttpRequestBaseの中身からCookie,Form,QueryStringを表示
Routes
表示内容(アクション)に到達するルーティングの解決順とマッチしたルート
Server
ServerValiablesの内容
Session
Sessionの内容
Trace
System.Diagnostics.Traceに出力した内容
Views
表示内容(View)の解決に至る過程
XHRequest
まだっぽい

全部スクリーンショットをとるのが面倒だったから動かして確認してみてね！

んじゃ、そもそもGlimpseの仕組みはどうなってるの？って気になるよね。NuGetからインストールすると使うのは楽チンだけどソースが確認できないから、改めてソースをダウンロードしましょう。

Glimpse/Glimpse - GitHub

真っ先に気になるのが、PreApplicationStartCode。当たり前のようにスタートアップコードが書かれてる。んで、その中身はMicrosoft.Web.Infrastructure.DynamicModuleHelper.DynamicModuleUtility.RegisterModuleを使ったカスタムIHttpModuleの動的登録。その中で各種プラグイン(タブで表示する情報を取得したりするもの)をMEFで登録。

Moduleでハンドリングするタイミングは以下の４つ。

context.BeginRequest += BeginRequest;
context.EndRequest += EndRequest;
context.PostRequestHandlerExecute += PostRequestHandlerExecute;
context.PreSendRequestHeaders += PreSendRequestHeaders;

ここから結構気になってるExecutionで表示してるのがホントにActionInvokerに介入した結果なのかチェックしてみよう。

ExecutionプラグインのSetupInitでいろいろ仕込んでますね。ControllerFactoryとDependencyResolverをGlimpseのものに置き換えてます。GlimpseControllerFactory.CreateControllerでIControllerExtentions.TrySetActionInvokerを呼んでCastleのInterceptorを利用して、プロキシを生成しそれをActionInvokerにセットしてました。これでプロキシが必ず呼び出されるから、実行をインターセプトして実行情報を取得できるということですね。うほ。

DependencyResolverを利用した場合にも大丈夫なようにGlimpseDependencyResolverが用意されてて、こっちでも同じくProxyを生成するように抜かりなし。

他のプラグインもIGlimpsePlugin実装になってて、SetupInitしてGetDataを呼ぶことで各種データをHttpContext.Itemsに入れることで、最終的にGlimpseRespondersがJsonにシリアライズ。まるっとApplication編集に保存してGlimpseResponders.StandardResponseがResponse.Writeしてる。

Glimpseの仕組み

MEFを使ったプラグイン構造でContext.ItemsからApplication変数にデータを保持(configのsaveRequestCountはこの履歴保持数ということみたい)し、それをレスポンス(リクエスト毎にGuidを発行してコンテキストがきちんと判定できるよう保持)。各種情報はプラグインが自立して取得するけど、実行状態のインターセプトはCastleがProxyを生成して介入。

イロイロなプラグインを作っていけば、データの取得と表示はベースの機能でまかなえる素敵設計であるのと、.NET4、MVC3の機能もめいいっぱい利用したお洒落実装。これは萌える。萌え萌え。ぷっすぷすにされちまったぜ！

Dapper.NET

noreply@blogger.com (たけはら) — Tue, 03 May 2011 14:45:00 +0000

dapper-dot-net - Simple SQL object mapper for SQL Server - Google Project Hosting

これ。Massiveと同じくらい短いコードのORM。WebMatrix.Data.Databaseみたいなものですね。

オープンソースとしてたくさん存在する軽量ORMのなかでもDapperがスゴイところがパフォーマンス。どのくらい早いのかは上記サイトを確認してみると各種ORMとの速度比較が出てます。

A day in the life of a slow page at Stack Overflow

ASP.NET MVC & SQLServer & LINQ to SQLのスタックで有名な大規模サイトといえばStackoverflow.comですね。なんとそのStackoverflow.comでパフォーマンスに問題が出てきたので解決するために、このDapperを利用したというじゃないですか。

そもそもORMでN+1問題が出やすいので、LINQならjoin使ってたくさんのSQLを発行しないようにするとか、DBとのあいだのやりとりもちゃんと確認する(パフォーマンスに問題があると認識したならの話です。問題になってないなら気にしなくていいですよ)必要がありましょう。その辺はちゃんと実装したとしてもDapperが早いということです。Emitしちゃってるし。

使い方も簡単でIDbConnectionの拡張メソッドとして実装してるので、DBコネクションさえあれば簡単に導入できます。もちろんモデルクラスをPOCOで定義しておくことが最速を維持する秘訣。

AdventureWorksLT2008R2をDBに利用するためのサンプル。

public class Product
{
  public int ProductId { get; set; }
  public string Name { get; set; }
  public string ProductNumber { get; set; }
}

using (var connection = connectionFactory())
{
  var result = connection.Query<int>("select count(*) from Product").Single();
  Console.WriteLine(result + " products.");
}

// 1テーブルを1クラスにマッピング
using (var connection = connectionFactory())
{
  var result =
      connection.Query<Product>(
          "select * from Product where ListPrice between @low and @high",
          new { low = 10.0, high = 100.0 });
  Console.WriteLine("-- simple mapping:" + result.Count());
  foreach (var p in result)
  {
      Console.WriteLine(string.Format("ID:{0},Name:{1}", p.ProductId, p.Name));
  }
}

// ジェネリック指定しないで1テーブルをマッピング
using (var connection = connectionFactory())
{
  var result =
      connection.Query(
          "select * from Product where ListPrice between @low and @high",
          new { low = 10.0, high = 100.0 });
  Console.WriteLine("-- dynamic mapping:" + result.Count());
  foreach (var p in result)
  {
      Console.WriteLine(string.Format("ID:{0},Name:{1},Price:{2}", p.ProductID, p.Name, p.ListPrice));
  }
}

ここで、実際にテーブルにはたくさん項目あるけど、モデルには省略しちゃってるんですけど、このままSQLにjoin含めた場合、ちゃんとモデルにはマッピングできませんでした。dynamicだとうまくいくんだけど、その辺の整合性はちゃんととっておかないとダメなわけですね。でもdynamicな戻り値なら早いわけではない。

var stopwatch = new Stopwatch();
stopwatch.Start();
for (var i = 0; i < 100; i++)
{
  using (var connection = connectionFactory())
  {
    var result =
        connection.Query(
            @"select p.*, c.ProductCategoryId as CategoryId, c.Name as CategoryName
          from Product as p 
            inner join ProductCategory as c on 
              p.ProductCategoryID = c.ProductCategoryID 
          where p.ListPrice between @low and @high",
            new { low = 10.0, high = 100.0 });
    foreach (var p in result){}
  }
}
stopwatch.Stop();
Console.WriteLine("dapper time:" + stopwatch.ElapsedMilliseconds + " ms");

stopwatch.Reset();
stopwatch.Start();
for (var i = 0; i < 100; i++)
{
  using (var l2s = new AwDataContext(connectionFactory()))
  {
    var result = from p in l2s.Product
                 join c in l2s.ProductCategory on p.ProductCategoryID equals c.ProductCategoryID
                 select
                     new
                         {
                             ProductId = p.ProductID,
                             p.Name,
                             Category = c.Name
                         };
    foreach (var p in result) {}
  }
}
stopwatch.Stop();
Console.WriteLine("linq2sql time:" + stopwatch.ElapsedMilliseconds + " ms");

大きなサイトへ導入されてるというのは、興味深いじゃないですか。それだけの負荷で問題が起きないように丁寧な実装がされてるわけで(どっちもだけど)。

今後、より使いやすくなることを期待しつつ見守っていきたいプロジェクトです。

IIS ExpressでSSLを有効にしてデバッグ

noreply@blogger.com (たけはら) — Sat, 23 Apr 2011 15:32:00 +0000

Working with SSL at Development Time is easier with IISExpress - Scott Hanselman

Hanselmanさんのエントリに書かれてる通りデス！

IIS ExpressでSSLを有効にしたデバッグだと無効な証明書だと警告はでるけど、HTTPSでのテストはコレでできますよね。

だけど、名前はlocalhostに限定です。これはまぁ、そういうバインドしかapplicationHost.configに登録してないからなのと、アクセス許可をしてなからなんですが(詳しくはmvcConf 2 - Vaidy Gopalakrishnan: IIS Express | mvcConf | Channel 9)、その辺をちゃんと登録して気持ちよく使いましょうという内容ですね。途中URLRewriteでAccountControllerへのアクセスをHTTPSに書き換えるというのが挟まってるけど、コードで対応するならここは飛ばしてもOKです。

netshへのcerthashの登録、信頼されたルート証明機関の証明書として証明書を登録、最終的にIisExpressAdminCmdでACLの許可登録で気持よく、マシン名でもSSL有効な状態でアクセスできます。

というのを、自分の環境でも確認してみましょう。

１．ASP.NET MVCサイトを作成

もちろんVS2010で行うのが簡単ぽんなんですが、VS2008でも同じようにできるので(applicationHost.configとnetshなので)、そっちしかない場合はそっちで。プロジェクトの設定で、外部プログラムを起動するを利用しましょう(IIS ExpressのVS2008/VS2010利用)。

今回は簡単なVS2010で新しくなったMVC3 Toolsで作ります。

いい感じにHTML5ですね！

２．プロジェクトのプロパティでSSL有効化

trueにするだけの簡単な作業です。これでSSL URLが入ります。この例だと https://localhost:44301/ ですね。

この状態でまずは実行してみましょう。

文句は言われるけど、普通に問題なくアクセスできますね。楽チンデス。IIS Express最高！

３．localhostじゃなく好きな名前でアクセス

マシン名でもいいんですが、そこはほら、恥ずかしい名前付けてる場合もあるじゃないですか。そんな状態で表示するのもどうかと思うわけですよ。なので、今回は完全カスタムな名前にしてしまいます。

takepara-local

という名前にします。これが恥ずかしい名前じゃないかと言われると、まぁ微妙ですが。あ、ちなみに自分のマシン名はそんなに恥ずかしい名前じゃないですよ。

IisExpressAdminCmdでアクセスできるようにしましょう。

※”.”でドメインな感じのマシン名だとsetupFriendlyHostnameUrlに失敗します。

これでブラウザからアクセスしてみましょう！

残念。エラーです。何か忘れてますね。そうですね、applocationHost.configにバインド登録してなかったですね。

グレートですね。ちなみにhostsにtakepara-local登録して、netshでurlacl登録しても一緒です。

このまま、調子にのってHTTPSにしてみる。

残念。ダメでした。

４．証明書を作成

takepara-localの証明書を作成してませんでしたね。hanselmanさんのエントリに書かれてるとおりです。makecertしましょう。CNだけ変えて後はそのままで。

makecert -r -pe -n "CN=TAKEPARA-LOCAL" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

VSコマンドプロンプトから実行しましょう。パス通ってて確実。

証明書をnetshで登録。

netsh http add sslcert ipport=0.0.0.0:443 appid={214124cd-d05b-4309-9af9-9caa44b2b74a} certhash=864759f75a04d030e243ecf1cfe19ce336653374

警告でるけど、気にせず表示。

５．証明書を信頼

このままでもいいんですが、やっぱり気持よく。

信頼しちゃいましょう。自分のマシンで、自分で作った証明書。信頼しちゃえばいいじゃないか！

Chrome厳しす。まぁ、いいか。警告でなくなったしね！

６．Accountコントローラを厳しく

URLRewriteで同じようになってもいいんですが、あえてコードで対応しましょう。と、言っても難しいことはなく、AccountControllerにRequireHttps属性を付けるだけ。

これで、AccountControllerへのアクセスがHTTPSになってなければ、リダイレクトされます。リダイレクトされるということはHTTPでのPOSTは無視される(リダイレクトはGETデス)ので、気をつけましょう。

この動きが気持ち悪いときはViewでURLを埋め込むときにHTTPSにしてあげる必要があるので、修正箇所が随分増えちゃいますが、通常の開発であればViewでもちゃんと書いて、ControllerへのRequireHttpsも付ける2段構えになるのが王道でしょう。抜け道なし。ViewのURLなんて嘘つくからね。

例えば、_LogOnPartial.cshtmlを以下のようにする。

@if(Request.IsAuthenticated) {
    <text>Welcome <strong>@User.Identity.Name</strong>!
    [ @Html.ActionLink("Log Off", "LogOff", "Account", "https", "takepara-local", "", null, null) ]</text>
}
else {
    @:[ @Html.ActionLink("Log On", "LogOn", "Account", "https", "takepara-local", "", null, null) ]
}

これで、必ずHTTPSのURLが生成されます。

画像てんこ盛りですが、手順通りやればうまくいくので、HTTPSでのテストをやりたい場合は是非どうぞ。

なんか、うまくできない！という場合はタスクトレイのIIS Expressを終了させてやり直してみるといいかも。applicationHost.config書き換えしたときなんかは特に。

MIX11をChannel9からまとめどり

noreply@blogger.com (たけはら) — Sun, 17 Apr 2011 10:21:00 +0000

更新：2011年4月19日 4:07

残念なお知らせと、うれしいお知らせがあります。

Mix 11 Videos - Download them all with RSS - Scott Hanselman

残念なのからいくと、このエントリは用なしになりました。嬉しいのは公式にMP4 Highが配信されました。

ダウンロードしなおすぜ！頑張れオレ！

MIX11 | Channel 9

いっぱいですね～。120個くらいですかね。MP4だけダウンロードしてiPadに入れて通勤時に全部目を通しておくのが、ラスベガスに行けなかったマニアのおつな楽しみ方というものでしょう。

http://channel9.msdn.com/Events/MIX/MIX11/RSS

とはいえ、Feedから取り出せたりするほど、便利なわけでもなく。やり方あるのかな？

でもそんなこと気にしない。ListタブをクリックすればすべてのMP4動画へのリンクがありますね。ということは、HTMLにはちゃんと動画のURLが埋まってるわけですね。となれば、スクレイピング！

なんてね。今回はちょっと趣向を変えてIE9のコンソールでJavaScriptを実行して取り出してしまいましょう！と、思ったけど、なんかちょっと思ったような出力が得られなかったので、Chromeで取り出してしまいましょう！てへ。

まずはChromeでページにアクセス。

http://channel9.msdn.com/Events/MIX/MIX11?sort=status&direction=asc#tab_sortBy_status

Shift+Ctrl+iでコンソールをひらきましょう。

MIX11のページにはjQueryが読み込まれてるので、やりたい放題ですよ。まずは変数の初期化。

var list=[];

と入れて改行。

続いて、listにエレメントから取り出したMP4一覧をタイトル込みで入れる。

$(".entry-meta > .downloads a[href*='.mp4']").each(function(i,v){list.push("wget -O \""+$(v).parents(".entry-meta").find(".title").text().replace(":","-").replace("?","？") +".mp4\" "+ $(v).attr("href"));});

↑これをコピペして改行すると、ぞろぞろ表示されます。

が、結果はlistに格納されてるので、続けて

list

と、入力して改行。

あとはコレをさらにコピペして、都合のいいように編集してコンソールからwget！curlでもいいっす。ちなみに複数の解像度のファイルがあるので、タイトルだけでファイル名にすると重複しちゃうので、その辺は目視で変更。さらにファイルとして使えない文字もあったりするので、ちょこっと修正。お好みに合わせて、どーぞー。ただいまダウンロード中の図。

※パスは都合のいいように書き換えてね！

ちなみにIEで実行したのが↓こちら。

ちょっとコピペしにくい。というかできない。

これで見放題ですな。ぐへへ、ぐへへへ～。たまりませんな～。あ、でも解像度低いとiPadでちょっと見づらい。文字潰れ気味。スライドはギリセーフだけど、コードが見れるかどうかが大事なので、ダウンロード後にちょっと確認しないとね。