1Gig Server上のLiferayでポートレットを実行する - パフォーマンスの問題

Question

Liferay Portal内で実行されるカスタムポートレットアプリケーションがいくつかあります。

解決策は、エントリレベル（RAM < = 1ギガ）のクライアントコンピュータにインストールされます。赤いテープのために、クライアントが短期間にハイエンドのコンピュータに切り替えることはあまりありません。

問題は、アプリケーションが非常に遅いということです。

エントリレベルのコンピュータでうまく動作するように、Liferayの設定を最適化する（またはポートレットアプリケーションを最適化する）ためのヒントは何ですか？

または、Apache PlutoやGateInのような軽いポートレットコンテナの代替ポートレットに切り替えるのは良い方法ですか？

エントリーレベルのコンピュータでLiferayのようなポータルを実行することはできませんか？また、既存のポートレットを移植して、標準のJava Webアプリケーションを分離して、パフォーマンスを向上させることも検討してください。

Answer 1

チューニングの価格を比較し、フットプリントを最小限に抑え、その結果をこれ以上購入できないかもしれない1ギガバイトのRAMの価格と比較します。

次に、ポータル環境からJava Webアプリケーションへの移植の価格を比較してください.Liferayが提供するかなりの機能をやり直す必要があるため、箱から出してください。アイデンティティ管理など。別のものとしてコンテンツ管理。これには、新しいサーバーだけで済むような時間がかかります（お金に等しい）。

〜40€/月あなたはそれがサーバーよりも、ラズベリーパイの大きさを、このようなアプリケーションを提供する方法より可能であり、ネットワーク接続、電源もサポートを含む、ホストされたサーバーを取得することができます（<合計40ユーロ、ラズベリーパイは年間40ユーロ未満のホスティングを見てきました）。

「赤いテープ」とは何を意味するのかよく分かりませんが、間違ったターゲットに間違いがあると思います。 Liferayをチューニングするポイントがありますが、私はこのような最適化には向かないでしょう。

あなたは使用しているバージョンについて言及していません。そのハードウェアを使用していますが、これは古代版であると仮定しています。現在のバージョンの前では、Liferayはほとんどモノリシックでした。あなたはかなり構成することができます（キャッシュ、いくつかの機能を無効にする）彼らは抜本的な利点をもたらすことはありません。現在のバージョンはモジュール化されており、使用しないコンポーネントを削除してフットプリントを減らすことができますが、インフラストラクチャの規模に合わせて構築されていません。

そして、そのような種類のハードウェアでポータルを実行している場合、データベースと別のWebサーバーを同じボックスで実行しているわけではありません。これは最初の変更です：同じOS /ボックス上でLiferayの外で実行されているすべてを最小限に抑えます。