IIS
ASP.NETのセッション管理をAppFabric Cachingで!
AppFabricのインストール（ポイントだけ）
Windows Server AppFabricのダウンロードはこちらから。
4つほどありますが、Server2008R2やWindows7の64bit版であれば、
| WindowsServerAppFabricSetup_x64_6.1.exe |
をダウンロードしてインストール。きっちりCachingサービスと管理ツールを選択するのを忘れずに。
あとドメインに参加していないと、設定はSQLServerに保存できず、共有フォルダを作ってXML管理になります。
なお、AppFabric Cachingの管理ツールは以下から、
スタートメニュー > Windows Server AppFabric > Windows PowerShell のキャッシュ管理
右クリックして管理者として実行しないとダメです。通常権限でも起動しますが、ことごとくコマンドが失敗します。
とりあえずCaching管理ツールから以下のコマンドでAppFabric Cachingを動くようにしておきます。
PS C:\Windows\System32> Use-CacheCluster
PS C:\Windows\System32> Start-CacheCluster
アプリケーションのインストール
今回は勉強がてらEdtterを利用しました。ダウンロードはこちら。
ASPNETDBとEDTTERのmdfがついているので、適宜SQLServerにアタッチして、
Web.configのApplicationServices（ユーザー管理）とEdtterEntities（Edtterの投稿管理）のConnectionStringを書き換えましょう。
あとはIIS7で適当に設定すれば動くようになります。
AppFabric Cachingの設定
セッション管理のためのキャッシュの作成と、セキュリティ関連の設定の変更をします。
まず、キャッシュを作成します。今回はsessionという名前でキャッシュを作成します。これは後述するweb.configの設定と合わせる必要があります。
PS C:\Windows\System32> New-Cache session
そしていったんCacheClusterを停止しましょう。
PS C:\Windows\System32> Stop-CacheCluster
次に、セキュリティ関連の設定をします。Webサーバーと同じサーバーで実行するのであれば、
PS C:\Windows\System32> Grant-CacheAllowedClientAccount
Account: IIS APPPOOL\ASP.NET v4.0
みたいな感じで、アプリケーションプール名を指定します（\の右の部分）。
動作するアプリケーションがNETWORK SERVICE権限で動くのであれば、NETWORK SERVICEを指定しておきます。
が、別サーバーで動かす場合のやり方がわからんので、今回はセキュリティ関連の設定を全部Offにします。（せめてID/PWD認証があれば楽なんですがそれすら無いので）
PS C:\Windows\System32> Set-CacheClusterSecurity
SecurityMode: None
ProtectionLevel: None
以上でAppFabric Cachingの（最低限の）設定は完了です。細かい設定をするともっと大変なのですが、英語のドキュメントも翻訳済みドキュメントも、
ベストプラクティス的なのがどうにも見当たらないので今回はそのままで。
最後にCacheClusterを再開しておきましょう。
PS C:\Windows\System32> Start-CacheCluster
アプリケーションの設定
EdtterのWeb.configを開き、<Configuration>要素の直下に以下の設定を追加します。
<configSections>
<section name="dataCacheClient"
type="Microsoft.ApplicationServer.Caching.DataCacheClientSection,
Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"
allowLocation="true"
allowDefinition="Everywhere"/>
</configSections>
<!-- dataCacheClient要素を追記 -->
<!-- キャッシュの設定などはここに記述する -->
<dataCacheClient>
<localCache isEnabled="true" />
<hosts>
<host name="localhost" cachePort="22233" />
</hosts>
<securityProperties mode="None" protectionLevel="None" />
</dataCacheClient>
そして<system.web>要素の直下に以下の設定を追加します。
<sessionState mode="Custom" customProvider="Velocity">
<providers>
<add name="Velocity" type="Microsoft.ApplicationServer.Caching.DataCacheSessionStoreProvider" cacheName="session" />
</providers>
</sessionState>
最後に、Edtterのソリューションの参照設定に以下のDLLを追加します。
C:\Windows\assembly\GAC_MSIL\Microsoft.ApplicationServer.Caching.Client\1.0.0.0__31bf3856ad364e35\Microsoft.ApplicationServer.Caching.Client.dll
追加したら、参照のプロパティでローカルコピーをTrueにしておきましょう。そうすることで、Microsoft.ApplicationServer.Caching.Client.dllがアプリケーションへの発行時にコピーしてくれます。
（これが正しいやり方なのかどうかわかりません。手動でbinフォルダ内にコピーしてもいいです）
動作確認
ここまで出来たら、VS2010からアプリケーションを発行します。まぁWeb配置ツールはそこまで難しくないので、そのあたりはなんとなくやりましょう。
でもローカルIISへの発行は管理者権限でVS2010を起動していないと許してくれないので注意（めんどくせぇ）
アプリケーションを無事発行、つまりIISにアプリケーションとして配置できたら、Edtterを開いてください。
ここで長時間待たされる場合は、AppFabric Cachingが立ち上がってないとか、導通していないとか、アクセス権がないとか、そこらへんで詰まっている可能性が高いです。
そのあたりで問題が起きなければ、通常通りEdtterの画面がブラウザに表示されるはずです。
試しに、何かセッションを利用するコードを書いて、AppFabric Cachngが使われているかどうか確認してみましょう。
なんでもかまわないので、Controllers\HomeController.csのIndexメソッドに以下を追加してみます。
{
// 書き込み
Session["now"] = DateTime.Now;
ViewData["TotalPages"] = _er.TotaltPages();
ViewData["CurrentPage"] = id;
var entries = _er.GetList(id);
// 呼び出し
var now = Session["now"];
if (Request != null && Request.IsAjaxRequest())
return PartialView("EntryList2", entries);
else
return View(entries);
}
確認用に、Views\Home\Index.aspxの好きなところに、
<%: ViewData["now"] %>
とでも書いておきましょう。
以上で再度ビルドして発行できたら、再度Edtterの画面を開いてみましょう。
わかりやすいよう、VisualStudioでブレークポイントを設定してみます。
これだけだとホントにAppFabric Cachingを使っているかどうかわからないので、
Caching管理ツールで以下のコマンドを実行してみましょう。
PS C:\Windows\system32> Get-CacheStatistics session
Size : 508
ItemCount : 2
RegionCount : 2
RequestCount : 24
MissCount : 2
こんな具合で、きっちりAppFabric Cachingが利用できていることが確認できました。
リロードするたびに、カウントが増えていくのが確認できるかと思います。
FastCGI for IIS7.0のアップデート
件のIIS用FastCGIモジュールがREQUEST_URIなどのサーバー変数をUTF-8でやり取りできない問題の続き。
IIS5.1、IIS6についてはVer1.5 RTW+レジストリ操作で解決しましたが、IIS7.xにいては対応がまだでした。
が、やっとIIS7.0についてアップデートが提供されました。
http://blogs.iis.net/ruslany/archive/2010/03/10/important-update-for-iis-7-0-fastcgi-module.aspx
Windows7やWindowsServer2008R2のIIS7.5用FastCGIのアップデートはまだだがな！
なお、各OSでのFastCGI for IISの状況はこちら。
http://ruslany.net/2010/02/fastcgi-module-differences-across-iis-versions/
Using UTF-8 encoding for server variable valuesがIIS7.5だけNoという。
いやこれ、実質URIにマルチバイトを含めないわけで、非英語圏のアプリケーション的には致命度が半端ないんですが…
Windows Server AppFabric Beta1を試す～その1～
12月と1月は妙に忙しく、まったく検証できなかったので今更ながらWindows Server AppFabricを試していきます。
まずはこちら。英語ですが。
http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx
インストーラはこちらにあります。
が、依存プログラムが多いので、Web Platform Installer 2.0からインストールした方が楽ちんです。
http://www.microsoft.com/web/downloads/platform.aspx
WebPIを起動。
左下のオプションをクリックして、
エンタープライズにチェックをつけます。というかせっかくなので全部にチェックをつけておきます。
すると、WebPIの画面にEnterpriseにタブが出てきます。タブをクリックして、「カスタマイズ」をクリックすると、
AppFabric Beta 1がチェック可能になります。
あとはインストールすれば完了。ただし、注意点が二つ。
- すでにDeveloper版が入っている状態でもSQL Server 2008 Expressをインストールされそうになる
- Windows Firewallが有効になっていないと、Velocityの設定で失敗する
特に後者が致命的なのでご注意ください。アンチウィルスがファイアーウォール機能を備えているからといって、Windowsファイアーウォールを有効にしてると、
Velocity（Microsoft Distributed Cache）用のファイアウォール例外を追加するのに失敗しやがります。
ちなみに前者については、今試したらSQL Server (SQLEXPRESS)のサービスを新規に作りやがりました。ご注意ください。
…と、ここまで書いておいてナンですが、私の環境ではWebPIではDistributedCacheのサービスが動いてないので、手動で再度インストールします。
（というか、会社の環境でもWebPIでうまくいった試しが無い、というかConfigurationWizardが立ち上がらない）
上の方に書いたDownloads/DetailのページからAppFabric Beta1のインストーラをダウンロード（asesetup_amd64_6.1.exe）して、右クリック→管理者として実行をクリック。
WebPIでインストールしてしまっていたので、いったんRemoveします。再起動して、AppFabric Beta1のインストーラを再度実行。
規約を読んで次へ。
DistributedCacheをインストールするよう、チェックをつけて次へ。
DBへのConnectionStringsを指定されるので、前もってMonitoringとPersistence、DistributedCache用のDBを作成しておきましょう。
こんな感じでDistributedCacheの設定をします。こっちもEditボタンで、DBを指定しておきましょう。
後は次へボタンでインストール完了。こちらもWindowsファイアーウォールが有効になってないと、例外追加で失敗するのでご注意。
無事インストールが完了すると、サービス一覧に Microsoft project code named “Velocity” CTP4として追加されます。
続きは次回。
FastCGI 1.5 for IIS6でREQUEST_URIが文字化けする件の解決
こちらのエントリで書いた、FastCGI for IISでのREQUEST_URIの文字化け問題ですが、iis.netのページにこんな情報がありました。
Configure the FastCGI Extension for IIS 6.0
Using UTF-8 encoding for server variables
By default, FastCGI extension uses ASCII encoding when setting server variables that are used by PHP. When requested URL contains non-ASCII characters, then server variables that derive their values from the requested URL string may be set incorrectly. PHP applications that rely on those server variables may not work because of that.
To prevent this the FastCGI extension can be configured to use UTF-8 encoding when setting server variables. To configure FastCGI to use UTF-8 encoding for a particular set of server variables, use the REG_MULTI_SZ registry key FastCGIUtf8ServerVariables and set its value to a list of server variable names, for example:
reg add HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\w3svc\Parameters /v FastCGIUtf8ServerVariables /t REG_MULTI_SZ /d REQUEST_URI\0PATH_INFO
The above example will configure FastCGI extension to use UTF-8 encoding when setting REQUEST_URI and PATH_INFO server variables.
After setting the registry key restart the IIS by using the iisreset command.
Warning: using UTF-8 encoding for server variables may affect how PHP core and PHP applications work. Make sure to verify that applications work as expected after the registry key has been changed.
1月にやっとリリースされたRTW版で追加されたオプションのようです。要は、デフォ設定だとREQUEST_URIやPATH_INFOをUTF-8でやりとり出来ないと。
というわけなので、コマンドラインで上記レジストリエントリへの追加をして、IISのサービスを再起動して完了。
WordPressのclasses.phpを修正していたのを戻して、エントリ単品の記事へ正常にアクセス出来る事が確認できました。
しかしなんでデフォでこんな仕様なんだろう…