💉 🧙 🚽 IISのプロセスとドメイン間で共有アセンブリを共有する 🤛🏻 🤾🏾 😁

マイクロサービスの世界では、新しい機能を追加するには、新しいサービスを作成します。同時に、新しいユニットを追加するコストは少なくとも150 MBのRAMですが、コードは非常に小さく、原則として、同じアセンブリが使用されますが、バージョンが若干異なります。

この記事では、サーバー設定のみによる最適化パスを示します。そのため、アプリケーションの書き換えと再コンパイルは不要です。結果は、マイクロサービスごとに平均25 MBになります。

2.プロセスメモリの構造

最初のステップとして、プロセスメモリが占有しているものを特定し、この最適化が特定のケースで重要かどうかを判断する必要があります。メモリ構造を分析するには、Sysinternalsの1つのアプリケーション-VMMapが必要です。

VMMapを開いて、サイトがホストされている特定のw3wpプロセスの構造を考えてみましょう 。アプリケーションの上部には、3つの水平チャートがあります。

コミット済み-プロセスで使用可能なメモリ

プライベートバイト-仮想メモリ

ワーキングセット-物理メモリ（RAM）

図の色は、さまざまなタイプのメモリを示しています。ワーキングセットの上位4つを構成するのは、そのうちのほんの一部です。

イメージ-イメージローダープロセスにロードできる実行可能ファイル（.exeや.dllなど）

マネージヒープ-.NETランタイムによって割り当てられるメモリ。通常はアプリケーションデータが含まれます。

ページテーブル-仮想アドレスを物理アドレスにマッピングするメモリ領域

ヒープ-通常はアプリケーションデータを含むCまたはC ++ランタイムで割り当てられたメモリ

メモリの種類ごとに、メモリの割り当て方法と場所に関する詳細情報を取得できます。

合計WS-物理メモリの数

プライベートWS-他のプロセスと共有できない物理メモリの量

共有可能なWS-他のプロセスと組み合わせて使用できる物理メモリの量

共有WS-現在他のプロセスと共有されている物理メモリの量。

VMMapアプリケーションの詳細な説明については、[1]、[2]を参照してください。しかし、w3wpプロセスに戻り、メモリタイプごとに上位3つを検討します。

220 MBの73がImageになります

220 mbから60ヒープ

マネージヒープに220 MBの58

さらに、マネージヒープにはJITに関連付けられたメモリが含まれることに注意してください。 Managed HeadのサイズからGCのサイズを引いた値として計算できます。

2.1初期条件

8 GbのRAM、2つのIntel Xeon ES-2676 v3 2.40GHzコア、OSとしてのWindows Server 2012 R2を備えたAmazon t2.largeインスタンスがあります。 IISを実行する47のマイクロサービスの内部。

各マイクロサービスには、アセンブリのバージョンを返すメソッドを持つコントローラーがあります（以下の例を参照）。サイトを「ウォームアップ」するために呼び出すのは彼です。

public class VersionController : ApiController { [Route("version")] [HttpGet] public IHttpActionResult Version() { return Ok(Assembly.GetExecutingAssembly().GetName().Version); } }

次に、全体像を見るためにサイトを立ち上げ、「ウォームアップ」します。このプロセスを自動化するために、PowerShellスクリプトを提供しています（githubへのリンク）。

その結果、47のサイトが6分43秒で立ち上げられ、サーバーのRAMをすべて占有しました。 1つのマイクロサービスの平均サイズは7 GB / 47 = 152 MB（OSでは1 GB）でした。

ここで、 ProcessExplorerのプリズムを通してw3wpプロセスを検討します。 .NETアセンブリタブに移動すると、3つのいわゆる アプリケーションドメイン：sharedDomain、defaultDomain、siteDomain （/ LM / W3SVC / 3 /）。ただし、後者は、各サイトに独自のアプリケーションプールを作成する場合にのみ当てはまります。

複数のサイトを1つのアプリケーションプールに結合すると、どのような変更が発生しますか？ N個のappDomainsは、/ LM / W3SVC / 3 / ...という名前で追加されます-siteDomain 、ここでNは追加されたサイトの数です。

いくつかのアセンブリはsharedDomainにあり、いくつかのアセンブリはappDomainsにあることに注意してください 。この場合、 sharedDomainにあるアセンブリはアプリケーション内の単一のインスタンスに存在し、 siteDomainsにあるアセンブリはドメインごとに独立してロードされます。

sharedDomainにあるアセンブリには、DomainNeutralフラグと、GAC（グローバルアセンブリキャッシュ）またはネイティブイメージキャッシュのいずれかを指すパスがあることに注意してください。

MSDN [3]は、「ドメインニュートラルアセンブリ」の次の定義を提供します。

単一のインスタンスに存在し、1つのプロセスのappDomains間で共有されるアセンブリ
一度Jittし、他のappDomain共通データ構造と共有するアセンブリ：MethodTables、MethodDescs
アセンブリとそのすべての依存関係がGACに配置されている場合、アセンブリはドメインニュートラルになります（GACに配置できるのは署名済みのアセンブリのみです）

「Pro .NETパフォーマンス：C＃の最適化」[4]の本では、署名済みアセンブリ（厳密な名前のアセンブリ）をGACに配置することをお勧めします。

後者は、このアセンブリを参照するすべてのアプリケーションのネイティブイメージの作成も容易にします。

したがって、アプリケーションのサイズを容易にするために、署名済みアセンブリをGACに配置し、負荷プロファイルに従ってapplicationPoolsにサイトをグループ化する必要があります。

最初の問題を解決するために、Windows SDKに付属のコンソールアプリケーションaspnet_intern.exeがあります。

アプリケーションは使用されたアセンブリを分析し、指定されたディレクトリにコピーして、ソースファイルをシンボリックリンクに置き換えます。これにより、ディスクスペースを節約し、w3wpプロセスを高速化します[5]。

例：

管理者モードでコマンドラインを開き、Windows SDKディレクトリに移動します

 cd C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\

すべての可能なオプションに関するヘルプを取得する

 aspnet_intern.exe /?

実際にインターンせずにすべてのアセンブリのリストを取得する

 aspnet_intern -mode analyze -sourcedir "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files" > C:\internReport.txt

* 32ビットアプリケーションの場合、パスを使用：C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files

ディレクトリCのインターンアセンブリに直接：\ ASPNETCommonAssembliesは次のコマンドを実行します

 aspnet_intern -mode exec -sourcedir "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files" -interndir C:\ASPNETCommonAssemblies

PowerShellの例

 $intern_path = 'C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\aspnet_intern.exe' $intern_param = '-mode', 'exec', '-sourcedir', 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files', '-interndir', 'C:\ASPNETCommonAssemblies' & $intern_path $intern_param

GACでアセンブリをダウンロードするには、Windows SDKを使用する必要がありますが、 gacutil.exeアプリケーションを使用する必要があります。インターン後、署名済みおよび未署名のアセンブリを含むディレクトリを取得しました。

GACに署名できるのはGACにのみインストールできるため、それらをインストールするには小さなPowershellスクリプトを作成する必要があります。

 $asm_path = 'C:\git\IISSharingAssemblies\common-assemblies-legacy' $gac_path = 'C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\gacutil.exe' #install assembly to GAC Get-ChildItem -recurse $asm_path | where {$_.extension -eq ".dll"} | ForEach-Object { Write-Host "Try to install assembly $_" & $gac_path "/i", $_.FullName } #uninstall assembly from GAC #Get-ChildItem $asm_path | where {$_.extension -eq ".dll"} | ForEach-Object { # & $gac_path "/u", ([System.Reflection.AssemblyName]::GetAssemblyName($_.FullName).FullName) #}

applicationPoolsでサイト統合の実験を手動で実行しますが、後者はWebAdministrationモジュール[7]を介してPowerShellツールを使用して実行できます。

特定のケースでは、47のマイクロサービスを、それらの負荷プロファイルに従って6つのapplicationPoolに結合します。設定をバックアップ、復元、または他のマシンに転送するには、 appcmd.exe [7]、[8]に注意することをお勧めします

 #clean all sites cmd.exe /c "%windir%\system32\inetsrv\appcmd.exe list site /xml | %windir%\system32\inetsrv\appcmd delete site /in" #cleam all pools cmd.exe /c "%windir%\system32\inetsrv\appcmd.exe list apppool /xml | %windir%\system32\inetsrv\appcmd delete apppool /in" #To Export the Application Pools on IIS 7 : #cmd.exe /c "%windir%\system32\inetsrv\appcmd list apppool /config /xml > c:\apppools.xml" #To Export all you're website: #cmd.exe /c "%windir%\system32\inetsrv\appcmd list site /config /xml > c:\sites.xml" #To import the Application Pools: cmd.exe /c "%windir%\system32\inetsrv\appcmd add apppool /in < c:\apppools.xml" #Stop all Application Pools: cmd.exe /c "%windir%\system32\inetsrv\appcmd.exe list apppool /xml | %windir%\system32\inetsrv\appcmd stop apppool /in" #To Import the website: cmd.exe /c "%windir%\system32\inetsrv\appcmd add site /in < c:\sites.xml"

変更後、次の図が表示されます。47サイトが2分33秒で「ウォームアップ」しました。これは2.6倍高速です。使用されたRAMの合計サイズは4.1 GBでした。さらに、1つのマイクロサービスの平均サイズは3.1 GB / 47 = 67 MBであり、2.2倍少ないです。

同じプロセス内のドメイン間でアセンブリを共有することに加えて、異なるプロセス間でアセンブリを共有できますが、後者ではネイティブイメージを作成してキャッシュに配置する必要があります。この目的のために、 ngen.exe [9]を使用します。

ネイティブイメージを使用する利点をリストします。

プロセス間で共有できます
単一プロセスでドメイン間で共有できます
JITコンパイルを必要としないため、使用するRAMが少ない
JITコンパイルと型安全性検証を必要としないため、読み込みが速くなります

署名済みアセンブリと未署名アセンブリの両方でネイティブイメージを作成できます。ただし、微妙な違いがあります。アセンブリがsharedDomainにロードされていない場合、他のappDomainとは共有できません。

 $asm_path = 'C:\git\IISSharingAssemblies\common-assemblies-legacy' $ngn_path = 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe' #install native images from cache Get-ChildItem -Recurse $asm_path | where {$_.extension -eq ".dll"} | ForEach-Object { & $ngn_path "install", ([System.Reflection.AssemblyName]::GetAssemblyName($_.FullName).FullName) } #uninstall native images from cache #Get-ChildItem $asm_path | where {$_.extension -eq ".dll"} | ForEach-Object { # & $ngn_path "uninstall", ([System.Reflection.AssemblyName]::GetAssemblyName($_.FullName).FullName) #}

この段階では、前の手順をすべて繰り返して、新しい手順を1つ実行する必要があります。

署名済みアセンブリをGACにアップロードします
applicationPoolsでのサイト統合
GACに読み込まれたアセンブリのネイティブイメージの作成

その結果、次の図が表示されます。

総ウォームアップ時間2分12秒
合計使用メモリ2.2 GB
1つのマイクロサービスの平均サイズ1.2 GB / 47 = 26.1 Mb

5.結果

ステップ	総ウォームアップ時間	使用されるRAMの合計サイズ	1つのマイクロサービスの平均サイズ	ご注意
初期条件	6分43秒	8 GB	7 GB / 47 = 152 Mb	OSで1 GB。 IISで使用されないネイティブイメージキャッシュ
appPoolsでのサイトの結合、GACでのアセンブリの読み込み	2分33秒	4.1 GB	3.1 GB / 47 = 67 MB	OSで1 GB。 IISで使用されないネイティブイメージキャッシュ
appPoolsでのサイトの結合、GACでのアセンブリの読み込み、ネイティブイメージの作成	2分12秒	2.2 GB	1.2 GB / 47 = 26.1 Mb	OSで1 GB。 IISはネイティブイメージキャッシュを使用します

参照資料

Windows Sysinternals管理者リファレンス。 216-218ページ
http://blogs.microsoft.co.il/sasha/2016/01/05/windows-process-memory-usage-demystified/
https://blogs.msdn.microsoft.com/junfeng/2004/08/05/domain-neutral-assemblies/
Pro .NETパフォーマンス：C＃アプリケーションを最適化します。ページ289
はじめに.NET 4.5 Alex Mackey、William Stewart Tulloch、Mahesh Krishnan。ページ149
https://technet.microsoft.com/en-us/library/ee790599.aspx
http://www.microsoftpro.nl/2011/01/27/exporting-and-importing-sites-and-app-pools-from-iis-7-and-7-5/
https://technet.microsoft.com/en-us/library/ea8d442e-9a0c-49bb-b940-50b22fa64dd4
https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator

ソースコード

https://github.com/sflusov/IISSharingAssemblies

IISのプロセスとドメイン間で共有アセンブリを共有する

2.プロセスメモリの構造

2.1初期条件

3. 1つのアプリケーションのドメイン間でのアセンブリの共有、ドメインニュートラルアセンブリの概念

4.異なるアプリケーション間でのアセンブリの共有、ネイティブイメージ（ネイティブイメージ）の概念

5.結果

参照資料

ソースコード

More articles: