Developerサイトに移行します。見た目やトピックエリアなど更新されますが、開発者に必要とされるコンテンツを引き続き提供していきます。08日クラウド・プロバイダーは、システムを実行してサービスを提供するために必要なインフラストラクチャーのコストと、サービスがプロバイダーにもたらす利益を天秤にかけなければなりません。このような費用便益の検討では、プロバイダーは各種のアーキテクチャーを検討することになります。その選択範囲は、非共有型のアーキテクチャーから共有マルチテナント型アーキテクチャーにまで及びます。非共有型アーキテクチャーの場合、プロバイダーは完全に個々の顧客に専用のハードウェア、ソフトウェア、アプリケーションを提供します。共有型のマルチテナンシーでは、複数の顧客のアプリケーションを単一のアプリケーションでサポートし、ベースとなるハードウェアとソフトウェアのすべてを共有します。この各種アーキテクチャーの間での主なトレードオフは、分離と密度です。密度とは、特定のハードウェアとソフトウェアのセットで提供可能なシステムとサービスの数であり、共有されるリソースが多くなればなるほど、密度が高くなります。間の分離レベルが下がることになります。分離とは、あるテナントが他のテナントのアクティビティーやデータに影響を与える可能性の度合いです。共有/非共有も含まれます。共有しなければなりません。共有すると、通常はインフラストラクチャー層の他の部分での分離がすべて解消されるため、最上位のアプリケーションでその分離を行わなければならなくなります。試用できるマルチテナント機能を紹介します。共有した場合に実現可能なレベルを上回る分離が維持されます。使用する場合に付き物のメモリーの消費を回避できることがあります。このオーバーヘッドが生じる原因には、以下に挙げるものがあります。ヒープが数百メガバイトものメモリーを消費するため。間でヒープ・オブジェクトを共有することはできません。割り当てられたヒープのすべてを使用する傾向があります。コンパイラーが数十メガバイトのメモリーを消費するため。生成されたコードが専用コードとしてメモリーを消費することが原因です。生成されたコードもかなりのプロセッサー・サイクルを費やすため、アプリケーションがプロセッサーを使用する時間も奪われてしまいます。メモリーを消費するため。つのガーベッジ・コレクション・ヘルパー・スレッドがあるだけでなく、複数のコンパイル用スレッドもあるため。同時に発生することがあります。限られたプロセッサー時間を求めて競い合うことになるため、最適ではない状態になる可能性があります。実行する場合に比べ、より望ましい形での分離を実現します。稼働状態にあることから、以降のアプリケーションの起動時間が短くなるというメリットもあります。起動時間の短縮は、スクリプトで使用されることの多い、短時間実行されるアプリケーションには特に有用です。実行されるアプリケーションほどには、各テナントが分離されないことです。自体での障害は、すべてのテナントに影響を及ぼします。実行しなければならない処理によって、わずかながらもパフォーマンスが低下します。このパフォーマンス・ヒットは、テナントの数が増えるにつれ、減少していきます。実行した場合のプロセッサーおよびメモリーのコストを回避することになるためです。コマンド・ラインに追加します。(ただし、この記事の後で説明する制限事項が適用されます)。実際には、アプリケーションは他のアプリケーションと並んで実行されています。共有する各テナントを互いに分離します。