「ラックオーバーフロー」に適している可能性がありますが、開発者の観点からは、IIS(レガシークラシックASPの両方を提供)を実行することの長所と短所は何ですか?および.NET)64ビットWindowsホストの64ビットプロセスではなく32ビットプロセスとして?
32/32に対する32/64(iis/server)の主な利点は、IISプロセスごとに最大4GBのメモリを使用できることです。
64/64よりも32/64に期待する利点は、従来の32ビットインプロセスDLL(パートナーベンダーからのDLLがまだあり、すぐに離れることができない)にアクセスしやすいことです。より小さなメモリポインタが与えられた場合、同じコードのより小さなメモリフットプリント。
32/64よりも64/64のパフォーマンス上の利点、または今すぐ完全な切り替えを保証する他の何かがありますか?ここで間違った仮定をしましたか?
64ビットvevrsus32ビットでIISを実行することの唯一のパフォーマンス上の利点は、はるかに大きなメモリアドレス空間へのアクセスを許可することです。
通常のASPXページ処理を行っている場合は、単一のプロセスから4GBを超えるアドレスを指定する必要がない可能性があります。同じマシン上に複数のワーカープロセスがあるWebガーデンで32ビットモードで実行するとします。その場合、各プロセスは最大4GBをアドレス指定できます。
キャッシングを実行すると、大きな利点が得られます。 64ビットプロセスは、巨大なメモリ内キャッシュを維持でき(32GB以上のRAMをサポートしていると仮定))、複雑なページコンテンツまたはデータをWeb上にキャッシュできます。これにより、データの生成が取得よりもコストがかかる場合にパフォーマンスを向上させることができます。たとえば、データが精巧な形式である場合(たとえば、モンテカルロシミュレーションの結果)、またはデータがオフボックスで存在し、ネットワークIO時間は、キャッシュ取得時間よりもはるかに高価です。
キャッシュを使用しない場合、64ビットIISは役に立ちません。ルックアップごとに64ビットポインターが必要になるため、すべてが少し遅くなります。
64ビットサーバーは、SQL Serverなどのデータベースやその他のデータ管理サーバー(たとえば、Exchangeなどのエンタープライズ電子メールサーバー)に使用すると、IIS)などのサーバーを処理する場合よりもはるかに効果的です。または、ワーカーが管理するプロセスを処理します。64ビットのアドレススペースを使用すると、データを管理する必要のあるサーバーは、インデックスやその他のキャッシュとともに、そのデータの多くをメモリに保持できます。これにより、ディスクが節約されますIO =クエリが受信される時間と精緻化時間。ほとんどのWebアプリは、単一のプロセスから4GBを超えるアドレスを指定する必要はありません。
おそらく有用な例えです。輸送では、大型SUVは64ビットマシンのようなものですが、通常のコンパクト乗用車は32ビットサーバーのようなものです。あなたは大きなSUVではるかに多くのものを運ぶことができます、そしてそれはより大きな牽引能力、8人のための座席、そして 8600ポンドのGVWR を持っています。しかし、それだけで、あなたは支払います。トラックは重いです。それはより多くの燃料を使用します。約2人と1つのダッフルバッグだけをカートに入れている場合は、SUVは必要ありません。小さい車の方がいいでしょう。それはより速くそしてより効率的になりえます。
私はあなたが誤った仮定をしたとは思わない。しかし、いいえ、あなたが概説したシナリオのいずれにもパフォーマンスの違いはない可能性が高いと思います。 Windowsの64の32はペナルティで動作しません。 64 on 64を使用すると、パフォーマンスがわずかに向上する可能性がありますが、それは疑わしいことです。 32ビットプロセスではメモリをいくらか節約できる可能性がありますが、これは、最初にプロセスを実行するために必要なサンクによって無効になる可能性があります。
唯一の利点は、あなたが言及したDLLの問題です。これも、アップグレードの理由になる可能性があります(特に64ビットを使用する必要がある場合)。
私は、32ビットのWindows 2003Serverから64ビットのWindows2003 Serverに、両方ともIIS 6を実行していて、ASP.NET 3.5Webサイトのパフォーマンスが許容できないものであったことを経験しました。
64ビットサーバーは、32ビットサーバーより2秒遅れて一貫して実行されます。
IIS 6を32ビットワーカープロセスとして実行するように切り替えた後、パフォーマンスは同等であり、再び同等でした。
検証はしていませんが、IIS7 x64(Vista)と64ビットIISワーカープロセスは問題なく実行されているようです)で行ったテストでは、IIS6win2k3にのみ適用される可能性があると思います。 。
32ビットプロセスにスワップするプロセスは非常に簡単でした。サポートの詳細が記載されたKB記事は次のとおりです。 http://support.Microsoft.com/kb/894435/en-us
ASP.NET 2.0、32ビットバージョンASP.NET 2.0の32ビットバージョンを実行するには、次の手順に従います。
64ビットに戻す方法については、KBの記事を参照してください。
メモリの可用性については、これを参照してください msdn blog 。
メモリの可用性。私のアプリケーションでは、サードパーティのライブラリを置き換える手間をかけずに、32ビットOSの32ビットプロセスから64ビットOSの32ビットプロセスに切り替えるために必要なものを入手しました。そこで、そこで立ち止まりました。利点は次のとおりです。1)各IISワーカープロセスで使用可能な2〜3倍の有効メモリ)2)Webサイトが大量のメモリを使用する32ビットOSでは、他のシステムプロセスとWebサイトが競合します限られた合計メモリ用。アプリケーションについて、ワーカープロセスが使用するメモリの量を確認します。各WPが大量のメモリ(1GBをはるかに超える)を使用していない場合、64ビットワーカープロセスはあまり役に立ちません。
パフォーマンスについては、両方の構成で独自のアプリケーションをテストする必要があると思います。 Daveの投稿 上記は、64ビットでパフォーマンスが低下する可能性があることを示しています。 cheesoが指摘しているように 、一部のアプリケーションではキャッシュのメリットが見られる場合があります(ただし、2GB以上のキャッシュは多くあります)。限定的で単純なアプリケーションを除いて、パフォーマンスを一般化することはできないと思います。パフォーマンスが良いまたは悪い特定のテクノロジーを指摘できる可能性があります。
明らかなメモリの違いに加えて、64ビットOS上の32ビットプロセスは、「WindowsonWindows」またはWOWモードと呼ばれるもので実行する必要があります。これは基本的にサンク/エミュレーションレイヤーです。十分に注意を払うと、パフォーマンスが低下します。