ASP.NET MVC4でAzure CacheServiceを使ったOutputCacheを有効にすると超遅くなる、という現象があって困ったのでメモ。
Install-Package Microsoft.WindowsAzure.Caching しますWeb.configを編集してOutputCacheプロバイダを設定します。実行してみますわかりやすいようにMiniprofilerも入れてみました。
ﾌｧｯ!?
ローカルでこの遅さ。パーシャルViewとか使うともりもり+100msとかかかります。ありえない。
結論から言うとテンプレートに含まれる既定のMicrosoft.AspNet.Web.OptimizationがASP.NET既定のOutputCacheProvider以外はサポートしてないから処理に時間がかかる、ということでした。
NuGetでMicrosoft.AspNet.Web.Optimizationを1.1.0に更新すれば解決。
まともになりました。ふぅ。
教訓： 更新忘れずに。
焼土下座ーな感じでこんにちは。
Windows Azure Web Sitesのローカルストレージについて勘違いしていたので懺悔の意味も込めてまとめてみました。
|←樹海| ┗(^o^ )┓三
もっと素晴らしいのはきっと、しばやん大先生が纏めてくださると思います。
結論から言うと、Windows Azure Web Sitesのローカルストレージは永続化されるし、複数インスタンスで共有（というより同一のものを見ている）されてるので超COOL、ということです。
実際にどういうことか見てみたいと思います。
どうも、この間のJAZUGイベントのLTで圧倒的多数ｯ! の (´・ω・｀)ｼｮﾎﾞｰﾝ をゲットした@kamebuchiです。
あれか、ストアアプリ動かなかったからか！そうなのか！
あ、しばやん大先生、アプリ作成ありがとうございました。( ´∀｀)bｸﾞｯ!
うまい棒贈呈します。
…
というのは置いといて、この間リリースされたばかりのWindows Azure Cache Service（Preview）をさっそく使ってみたいと思います。
※一応、【祝】Azure日本DC前夜祭！★Japan Windows Azure User Group 3周年のLTフォローアップ的な何かです。
※あ、Cache ServiceはPreviewなので申請が必要です。（すぐにActiveになりますが）
しばやん先生がこんな無茶振り的なのを投げてきたので。
Azure Webサイトから他のWebサイトなどに接続した際のグローバルIPアドレスはどうなのか？という話ですので、実際にAzure Webサイトから他のサイトへ接続してリモートアドレスを取得してみました。
2つのAzure Webサイトとも同じDC（東アジア）です。
Whoisさんによると
NetRange: 65.52.0.0 - 65.55.255.255 CIDR: 65.52.0.0/14 OriginAS: NetName: MICROSOFT-1BLK
ということで、受け口となるAzureのロードバラサのグローバルIPアドレスと外に出ていく際に使われているグローバルIPアドレスは同じネットワークにはいるみたいです。で、結局スケールしようがWebサイトが再起動しようが（内部のローカルIPアドレスはともかく）外に出ていく際のグローバルIPアドレスはそうそう変わらない感じ。
※Azure Webサイトで内部のIPアドレス見えないのでなんともですな。（ネットワーク層触れない）
たぶんWebサイトが動作してるWorkerなクラウドサービスのデフォルトゲートウェイが全部同じの見てるんでしょう。きっと。
外部からの接続を受け付けるグローバルIPアドレス（FQDNに割り当てられたIPアドレス）はWebサイトが起動してる間は有効だと思うので、同じゲートウェイが使われる確率は高そうですね。
IPアドレスで許可してもらわないといけないとかそういう場合は適当に調べてOutboundのIPアドレスが変わらないことを期待して設定するか、レンジでどばっと指定するしかないんじゃないかな。どうせ複数のWebサイトで同じグローバルIPアドレスになるんだししょうがないよね！
ちなみにクラウドサービスの場合は同じグローバルIPアドレスになります。これはわかりやすいですね。
※なんかICMPが拒否されるようになってしまったので、いろいろ不便だわぁ。
Buildで赤シャツさんがデモしてた他のアプリケーションとの認証連携（アプリケーションアクセス拡張機能）がプレビュー公開されました。
なにはともあれ、Previewの申込みをしましょう。（たぶんすぐにActiveになると思います）
検証のお手軽さでいえばクラウドはかなり便利です。
という感じでWindows Azure上では仮想マシンのギャラリーにすでに検証に使える元イメージがあったり。
作成してから10分ぐらい待てば最新のVisual Studio 2013 Previewがさわれるぜ＼ﾉ’∀ﾝ ﾋｬｯﾎｳ
でもですね。でも！
このイメージ、OSはWindows Server 2012なんですよね。全然ダメ！
というわけで、このイメージ使うよりは同じようにWindows Server 2012 R2 Previewなイメージを使って、その後普通にVisual Studio 2013 Previewを入れたほうがなんぼかマシな気がします。
以下1からWindows Server 2012 R2 Preview上にVisual Studio 2013 Previewを入れる際の注意点。
1． Desktop Experienceを入れよう
Server Managerからさくっと入れておきましょう。これがないとWindows Storeアプリの開発に必要なデベロッパーライセンスのアクティベーションができません。
2. ユーザーアカウントを作成する
Windows Azure 仮想マシン作成時に指定するアカウントはビルトインのAdministrator扱いになります。このユーザーでWindows Store アプリを実行したりしようとするとアプリが起動しないので、追加でAdministratorsなグループに所属する別ユーザーを作りましょう。普段はそちらを使えばいいです。
あとはお好みでどうぞ。
Visual Studio 2013 Previewも出たということで、Claudia IDEも対応させました。なんかMaxバージョンの指定がおかしかった？みたいで、Visual Studio 2012でしか動作しなかったので一応2013も指定しなおしてリビルドしたぐらいですが。
そんなわけで無事Visual Studio 2013 Previewで動作しました。
ちなみにターゲットなエディションにExpressも含めてビルドしたんですが、それだとギャラリーにアップロードできなかったので個別にSkyDriveに置いています。Visual Studio Express 2012な方は人柱で試してみてもいいかも。追記：やっぱり動かないみたい
あとついでにWebMatrixManなIDEも対応しておきました。
メモ。
Windows 7以降の場合
netsh http add urlacl url=http://hogehoge.sample:8080/ user=everyone
みたいな感じで管理者としてコマンドを実行してホストするFQDNとポートを全ユーザーに許可します。
あとはVisual Studioのプロジェクトの設定でIIS Expressを上記FQDNでホストするように設定すればいいはず。怒られたら %USERPROFILE%\My Documents\IISExpress\config\applicationhost.config を編集しましょう。
<site name="DevWeb" id="9999">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory
path="/"
physicalPath="C:\application-no-path" />
</application>
<bindings>
<binding
protocol="http"
bindingInformation="*:8080:hogehoge.cample" />
</bindings>
</site>
前回Point-To-Site VPNを手動で設定して使えるようにしましたけど、いちいち証明書選んだり面倒ですよね。何よりWindows Azure Connectで自動的に接続されてたのにそれができなくなったのは不便！ということで、今回は自動接続できるようにしたいと思います。
最初に前回の手順で接続できる状態までしておいてください。
証明書の選択を省くためにはローカルコンピューター上の信頼されたルート証明機関に接続用の証明書を入れておく必要があります。
MMCを起動して、スナップインの追加で証明書を選択し、ローカルコンピューターを選択します。どの証明書ストアを管理するか聞かれるのでコンピューターアカウントを選択しましょう。
信頼されたルート証明機関を選択してインポートを選び、作成したクライアント証明書とそのルート証明書の秘密鍵付き（どちらとも.pfx）をインポートします。
前回作成したVPN接続のプロパティを開き、セキュリティタブのEAPプロパティを表示させます。「このコンピュータの証明書を使う」になっていると思いますが、その横の拡張だかAdvancedだかのボタンをクリックして、先ほど登録した証明書（2種類）にチェックを入れます。
これで設定は完了です。VPN接続を行うと証明書も聞かれずにすんなり接続が終わると思います。
自動接続はちょっと面倒くさいです。とはいっても他に良い案が浮かばなかったのでしょうがなしにタスクスケジューラを使うことにします。
管理ツールのタスクスケジューラを起動して、新しいタスクを作成します。
タスクの起動タイミングはコンピューターの起動時を選択します。
プログラムの開始を選択します。
実行するプログラムは「rasdial」、引数に接続するVPN接続の名前を入れます。
これで一応完了。作成後、プロパティを開き実行ユーザーは設定した人に、ログオンしていなくても実行できるようにして構成をWindows 8なりWindows RTなりにしておきます。
条件タブで任意のネットワーク接続が使用可能な場合のみタスクを開始するようにします。
後の条件（AC電源使用時のみなど）は好きなように設定しておきます。
あとはリトライとかいろいろお好きなように。
設定完了後は一度実行してみて問題なくVPN接続が開始されることを確認します。あとはOS再起動して動作確認しましょう！
これでだいぶ便利になりましたね。というか標準の接続ツールより便利になったｗ
結構前にFreeBSD on Azure とかいうPostしましたが、今になってPinBackきてたのでちょっと補足を。
当時はよくわからなかってなかったのですが、最終的にVHDファイルをUploadする際、OSイメージとしてUploadしてそれを基にすると上手く動作しません。（するにはするけどステータスがおかしい）
原因はAzure上でいうところの「イメージ」は基となるテンプレートなイメージで、それから仮想マシンを作成すると初期化処理が必要になるからです。つまるところWindowsでいえばSysprepされた前提であるVHDで、LinuxであればAzure用のそれ用のツールで一般化しておく必要があります。
で、以前のPostでは「イメージ」としてUploadしてたからうまく動作しなかったというわけ。
回避方法としてはDiskとしてアップロードして、管理ポータル上の仮想マシンの「ディスク」タブで作成を選んで、VHDからディスクを作成すればいいです。
こうすればアップロードしたままの状態で起動させることができます。（初期化処理などが走りません）
ただ、そのまま動作するので、このVHDを雛形として横展開とかそういうのがつらい感じです。（全部同じマシン名などになっちゃいます）
こればっかりはFreeBSD用の初期化処理用ツールみたいなのが提供されないとしんどいですね。
ちなみにこの手法はP2VだったりXPを動かしたりといったことに応用できます。
詳細はこちらが詳しいですのでご一読あれ。
ブチザッキ 