では、Glassfish V3 Prelude でベータ版/製品版をリリースすることを考えている私は気が狂っているのでしょうか? 私のコンテンツはすべて動的なので、わざわざ前面に apache をセットアップすることも考えていません。これを行うと、AJP や mod_jk などを必要とするため、セットアップが複雑になり、機能の点であまり提供されません。
したがって、デプロイ時に 3 つの war ファイルが作成されます。約 90 の接続が保留されている 3 つの JNDI データ ソース、最大 160 の PGSQL データストアへのスケーリング....
3 つの戦争は CMS システムと grails アプリケーションで構成されていますか?
このセットアップの前にApacheを配置する必要がないという私の論理に致命的な欠陥がありますか?
GlassFish/Tomcat/Resin/Jetty などの前で Apache を使用することの最大のボーナスは、それがもたらす汎用性です。たとえば、Tomcat は Apache を置き換えることができ、比較的うまく機能します。ただし、これは、その 1 つの Tomcat コンテナーからすべてを提供する必要があることを意味します。これは、インスタンスが実行する必要のある多くの余分な処理をスローします。これは、図の Apache では必要ありません。単純な PHP ベースのフォーラムをインフラストラクチャに追加することは、Apache のおかげで 5 分のタスクではなく、突然面倒になります。Apache を前面に配置するもう 1 つの利点は、コンテナーから静的コンテンツを提供する負荷を取り除くことができることです。これは、JK/AJP プロキシーを使用せずに、コンテナーを単独で提供するという私の最大の問題です。システムが少し複雑になり、汎用性が少し低下します。
GlassFish V2 で Grails アプリをテスト実行していますが、Apache でフロントエンドする説得力のある理由が見つかりません。Tomcat のパフォーマンスの向上により、Tomcat で Apache を使用する理由がますます少なくなっていることをどこかで読んだことがあります (場所を思い出してソースを引用できればと思います)。その要点は、追加されたパフォーマンスには、それだけの価値がないほど複雑さが追加されたということでした.
あなたを V3 Prelude に向かわせる特定の機能はありますか?