| ＞ Liferayプロジェクト |
OutOfMemoryError は様々な原因で発生します。ひとつの提案としては、お使いのアプリケーションサーバ/コンテナの起動オプションでメモリ容量を増やしてみることが挙げられます。
以下の JVM オプションで Java でのメモリ使用量を制御できます。
推奨: Liferay は多数の jar ファイル――もっと具体的に言えばクラスを読み込むので、MaxPermSize は 128mb に増やすことをおすすめします。 最大ヒープサイズを 1024m に上げる (?Xmx1024) のもよいプラクティスです。
JVM のメモリ使用量が最適になるよう設定するためのパラメータは他にもいくつもあります (特に JDK 1.5 以降を使っている場合)。ガーベッジコレクタで new 世代と old/tenured 世代をチューニングすると大きな改善が得られています (http://blogs.sun.com/watt/resource/jvm-options-list.html を参照)。
これらの設定を行える場所は、以下のとおりです。
===Liferay 4.x ではどのバージョンの Java/Jikes を使うべきですか?=== Liferay 4.x は JVM 1.4.2 または 1.5 での実行をおすすめします。1.4.2 をお使いの場合は、Jikes 1.2.1 が必要です。1.5 をお使いの場合は、Jikes 1.2.2 を使用してください。
4.4.0 では、Liferay のデフォルトでは Jikes が使われないようになったため、必要ありません。
===VM の起動時間を改善したいのですが何かいい案はありますか?=== Liferay の再起動には数分 (5 分以上) かかることがあります。私たちは 4.1 の Liferay Enterprise を仮想ウェブサーバで実行しています。 起動速度を上げるために使わないポートレットを外してみましたが、あまり変わりません。
高速化のために他に何かできることはありますか? もちろん、仮想サーバではなく物理サーバを使うというのはあるでしょうが。他にはどうでしょう?
起動時の引数を利用して、JVM により多くのメモリを割り当てます。-Xmx1024m にすると効果があるでしょう。 Liferay の利用目的に応じて、不要なウェブアプリを /webapps (Tomcat の場合) から削除することができます。
他に役立ちそうなのは、portal-ext.properties で
を設定することです。このプロパティは、ポータルの一部である Lucene のコンテンツインデックス再作成を行わないように指定するものです。
null になっている変数 uri は、portal.properties の "servlet.service.events.pre.error.page" から値を取得します。 このプロパティはデフォルトではコメントアウトされています。
このエラーは Tomcat 5.5.20 で Liferay 4.1.2 を使用した場合にのみ発生します。Windows では Tomcat 5.5.17 に戻すと問題を回避できます。Linux では Tomcat 5.5.20 でも動作します。
これは通常、画像の登録が Counter テーブルのプライマリカウンタと同期中であることを表しています。
SQL コンソールを開いて以下のクエリを実行してみてください。
select * from Counter;
<Context path="/liferay-portal" crossContext="true">
edit ,${catalina.home}/common/lib/ext/*.jar
portal.ctx=/liferay-portal
set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx1024m -XX:MaxPermSize=128m -Dfile.encoding=UTF8 -Duser.timezone=GMT -Djava.security.auth.login.config=%CATALINA_HOME%/conf/jaas.config
1) クラスパス内の設定ファイル portal-ext.properties を編集または新規作成し、以下の内容を設定する
portal.ctx=/mycontext
2)
2.1) Liferay 4.3、4.4、5.x 以降および以前のバージョンの WAR 版:
多くのアプリケーションサーバでは、単純に war を //mycontext.war// にリネームできます。
Tomcat では、META-INF/context.xml も作成できます。
<Context path="'''/mycontext'''" reloadable="true" >
<Resource
name="jdbc/LiferayPool"
auth="Container"
type="javax.sql.DataSource"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost/lportal?useUnicode=true&characterEncoding=UTF-8"
username="root"
password=""
maxActive="100"
maxIdle="30"
maxWait="10000"
/>
<Resource
name="mail/MailSession"
auth="Container"
type="javax.mail.Session"
mail.transport.protocol="smtp"
mail.smtp.host="localhost"
/>
<Realm
className="org.apache.catalina.realm.JAASRealm"
appName="PortalRealm"
userClassNames="com.liferay.portal.security.jaas.PortalPrincipal"
roleClassNames="com.liferay.portal.security.jaas.PortalRole"
debug="99"
useContextClassLoader="false"
/>
</Context>
2.2) Liferay バージョン 4.2 およびそれ以前のエンタープライズ (EAR) 版:
liferay_portal.ear/META-INF/application.xml を編集して以下の内容を設定します。
<module>
<web>
<web-uri>portal-web.war</web-uri>
<context-root>/mycontext</context-root>
</web>
</module
3) 配備される web.xml を編集し、root_path の context-param を以下のように設定する
<context-param>
<param-name>root_path</param-name>
<param-value>/mycontext</param-value>
</context-param>
エンタープライズ版では、このファイルは portal-web.war/WEB-INF の中に入っています。
4) WAR ファイルの名前を mycontext.war に変更する (これはアプリケーションサーバによっては不要)
//'注: 手順 5 は Liferay v.4.3.x では不要になりました。//'
5) /html/index.html を編集する: <body onLoad="javascript:location.replace('/mycontext/c')">
===実行している Liferay の jar のバージョンを知るには? === "\lib" の中に versions.txt というファイルがあり、これを見るとどのバージョンの Liferay jar ファイルが読み込まれているかがわかります。
General Guest のレイアウトを変更できる権限のあるユーザでポータルにログインします。General Guest コミュニティに切り替えて、ページの設定を変更します。
なんらかのバンドルを使っている場合は、portal-web/WEB-INF にある liferay-portlet.xml を編集し、'active' 要素を使って、不要なポートレットを無効にすることができます。
<portlet>
...
<active>false</active>
</portlet>
拡張環境を使っている場合は、元の liferay-portlet.xml を変更する必要はありません。単に liferay-portlet-ext.xml を編集して、無効化したいポートレットごとにエントリを追加してください。
無効化されたポートレットは Liferay に読み込まれなくなるため、CPU サイクルやメモリ空間を消費しません。
注:
GUI Admin ポートレットでポートレットのアクティブ/非アクティブ状態を編集すると、データベースにレコードが書き込まれます。データベースのレコードは上記で説明した XML 設定ファイルよりも優先されます。したがって、GUI Admin ポートレットでポートレットの状態を編集すると、それ以降はデータベースが優先され、XML 設定ファイルでポートレットの状態を変更しても反映されなくなります。
最初に読み込まれて初期ページにリダイレクトする index.html ファイルがあります。このファイルを編集して、他の URL へのリダイレクトを設定してください。
デフォルトは '/c' で、これはユーザがログオンしていなければゲストコミュニティへ、ログオンしていれば各自のプライベートページへ転送するようになっています。
- 現在では、PortalUtil.getPathMain()を呼び出すjspになっています
現在は、’Power User’ ロールを持つユーザがログインすると自分のデスクトップに転送されます。このデフォルトの動作を変更する方法は現時点ではありません。
この機能要求を追跡するために、JIRA にチケットが登録されています: http://support.liferay.com/browse/LEP-1420|http://support.liferay.com/browse/LEP-1420
当面は、拡張環境を使用し、ある程度のプログラミングを行うことでこれを実現できます: boards/message/25021|http://www.liferay.com/web/guest/devzone/forums/message boards/message/25021
この機能をポータル内のすべてのポートレットについて変更するには、portal.properties の以下のパラメータを "false" にします。
layout.show.portlet.access.denied=false
この機能をポートレット単位のレベルで変更するには、特定のポートレットに対して liferay-portlet.xml で "show-portlet-access-denied" パラメータを "false" に設定します。liferay-portlet.xml での設定は、portal.properties を設定を上書きします。
この機能をポータル内のすべてのポートレットについて変更するには、portal.properties の以下のパラメータを "false" にします。
layout.show.portlet.inactive=false
この機能をポートレット単位のレベルで変更するには、特定のポートレットに対して liferay-portlet.xml で "show-portlet-inactive" パラメータを "false" に設定します。liferay-portlet.xml での設定は、portal.properties を設定を上書きします。
CSS や JavaScript のコードを含める方法は 3 つあります。
1) ページに対してテーマを使用します。CSS コードは以下の JSP に格納されます。
/ext/ext-web/docroot/html/themes/[theme name]/templates/css.jsp /ext/ext-web/docroot/html/themes/[theme name]/templates/css_cached.jsp
JavaScript コードは以下の JSP に格納されます。
/ext/ext-web/docroot/html/themes/[theme name]/templates/javascript.jsp /ext/ext-web/docroot/html/themes/[theme name]/templates/javascript_cached.jsp
2) ポータルの下記ファイルに CSS と JavaScript を含めます。
/ext/ext-web/docroot/html/common/themes/top_head.jsp
3) liferay-portlet.xml で、ポートレットごとのパラメータ "header-css" および "header-javascript" が使用できます。以下のファイルをリファレンスとして使用してください。
/portal/portlets/sample-jsp-portlet.war/WEB-INF/liferay-portlet.xml
ブラウザ内で JavaScript の読み込みを最適化する方法について詳しくは、Javascript / JS Files in a portletsに説明があります。
概要 : すべてのポートレット (Liferay EAR に含まれているものと、別個の WAR で配備されたものの両方) は、2 種類の方法を使って、デフォルトの HttpSession オブジェクトで属性を共有することができます。
//注意//: すべてのポートレットが同じ WAR にパッケージされている場合はポートレット間で同一のセッションを共有できますが、ポータルとは別のセッションになります。ポータルは自身の WAR に入っているためです。
方法 1 - ポートレット間で属性を共有する:
この方法は、ポートレットに対してポートレットのセッションへのアクセスを与えることが必要になります。この方法では名前空間の分離が使用できません。この方法は多くのシナリオでは便利ですが、ポートレットがセッションに格納されている他のポートレットの (あるいはポータルの) 属性を上書きしてしまう可能性が生じます。例えば、ユーザがログインした後で、ポータルがセッション内に "user" というオブジェクトをセットしたとします。あるポートレットでもセッションに "user" というオブジェクトをセットしていた場合、前にポータルがセットしていた "user" オブジェクトは追い出されてしまいます。 注: private-session-attributes 要素は 4.2.0 以降でのみ利用可能です 。
1) 各 WAR の liferay-portlet.xml で、セッション属性を共有したいポートレットすべてについて、以下のパラメータを設定します (デフォルトは true)。
<private-session-attributes>false</private-session-attributes>
2) Action クラスまたは JSP で、以下のようなコードを使ってセッションの属性をセットします (これはデフォルトの setAttribute() 呼び出しとまったく同じです)。
session.setAttribute("id", "1234567890");
3) Action クラスまたは JSP で、以下のようなコードを使ってセッションの属性を取得します (これはデフォルトの getAttribute() 呼び出しとまったく同じです)。
String id = (String)session.getAttribute("id");
方法 2 - ポータルの属性をポートレットに渡して共有する:
別個の WAR で配備されたポートレットはポータルとは別のセッションを持つため、この方法では、名前空間を付けたセッション属性をポータルのセッションから各ポートレットのセッションにコピーするようにします。この方法の利点は、方法 1 のように属性がうっかり上書きされてしまうようなことが起こらないということです。欠点は、属性をポータルからポートレットへ書き出すのみであるということです。言い換えると、ポートレット側では属性を更新することができません……読み取りだけが可能です。 注: private-session-attributes 要素は 4.2.0 以降でのみ利用可能です。
1) 各 WAR の liferay-portlet.xml で、名前空間の付けられたセッション属性を共有したいポートレットすべてについて、以下のパラメータを設定します (デフォルトは true)。
<private-session-attributes>true</private-session-attributes>
2) portal-ext.properties で以下のプロパティをオーバーライドし、すべてのポートレットで共有したい名前空間付き属性として使用する値のリストを、カンマ区切りで指定します。
session.shared.attributes=LIFERAY_SHARED_
3) 自分のポータルクラス (例えば LoginPostAction) で、以下のようなコードを使って、すべてのポートレットと共有したい属性をポータルのセッションにセットします。
session.setAttribute("LIFERAY_SHARED_id", "1234567890");
4) ポートレットの Action クラスまたは JSP で、以下のようなコードを使って、ポータルによってセットされた属性をセッションから取得します。
PortletSession psession= req.getPortletSession();
psession.getAttribute("LIFERAY_SHARED_id", PortletSession.APPLICATION_SCOPE);
概要 : すべてのポートレット (Liferay EAR に含まれているものと、別個の WAR で配備されたものの両方) は、2 種類の方法を使って、デフォルトの HttpServletRequest オブジェクトで属性を共有することができます。
Method 1 ? 名前空間を分けずに属性を共有する
//' 注意:// ' この方法は、ClassCastException を引き起こす可能性がある (特に、複数の WAR に入っている複数のポートレットで共有する場合) ため、おすすめしません。 '
この方法は、同一のリクエストに対するアクセスをすべてのポートレットに与えるようにするものです。この方法では、名前空間は使用しません。すべてのポートレットが同一のリクエストを共有するため、互いに属性を上書きしてしまう可能性があります (上記でセッションについて説明したの同様)。この事実により、後述の方法 2 をおすすめします。
1) 各 WAR の liferay-portlet.xml で、リクエストの属性を共有したいポートレットすべてについて以下のパラメータを false に設定します (デフォルトは true)。
<private-request-attributes>false</private-request-attributes>
2) Action クラスまたは JSP で、以下のようなコードを使って属性に値をセットします (これはデフォルトの setAttribute() 呼び出しとまったく同じです)。
request.setAttribute("id", "1234567890");
3) Action クラスまたは JSP で、以下のようなコードを使ってリクエストから属性値を取得します (これはデフォルトの getAttribute() 呼び出しとまったく同じです)。
String id = (String)request.getAttribute("id");
方法 2 ? 名前空間を指定して属性を共有する
この方法は名前空間を指定された属性のみ、リクエストを通じてすべてのポートレットで共有できるようにするものです。
1) 各 WAR の liferay-portlet.xml で、名前空間を指定されたリクエスト属性を共有したいポートレットすべてについて、医科のパラメータを true に設定します (デフォルトは true)。
<private-request-attributes>true</private-request-attributes>
2) portal-ext.properties で以下のプロパティをオーバーライドし、すべてのポートレットで共有したい名前空間付き属性として使用する値のリストを、カンマ区切りで指定します。
request.shared.attributes=LIFERAY_SHARED_
3) Action クラスまたは JSP で、以下のようなコードを使って、すべてのポートレットと共有したい属性をリクエストにセットします。
request.setAttribute("LIFERAY_SHARED_id", "1234567890");
4) Action クラスまたは JSP で、以下のようなコードを使って、他のポートレットによってセットされた属性をリクエストから取得します。
String id = (String)request.getAttribute("LIFERAY_SHARED_id");
はい、Liferay はクラスタリングをサポートしています。おおまかに言えば、他のクラスタ環境と同様に処理されます。通常はサーバ群の前段にロードバランサが配置されます。Liferay のオブジェクトはサーバキャッシュへサーバごとにキャッシュされます。Liferay では Ehcache のサポートが提供されており、オブジェクトが修正されたらクラスタ内のすべてのサーバへブロードキャストメッセージが送出されます。メッセージを受け取ったサーバは自身のキャッシュを破棄し、更新されたオブジェクトをデータベースから取得します。クラスタ環境での Ehcache の設定は、以下の 3 つのプロパティファイルで制御されます。
設定ファイルは Java のクラスパスから読み込まれます。
関連項目: *Availability Guide|http://wiki.liferay.com/index.php/High Availability Guide|高可用性ガイド *http://wiki.liferay.com/index.php/Clustering|http://wiki.liferay.com/index.php/Clustering|クラスタリング
/portal/sql ディレクトリに、Liferay がサポートしている全データベースをクリーン (つまり drop) したり再作成/再ビルドするための ant スクリプトが用意してあります。新しいバージョンの Liferay で既存のデータベースを変更する必要がある場合は、必ずアップグレード用のスクリプトが提供されます。
上述の通り、Liferay ではデフォルトだと Ehcache を使ってオブジェクトをキャッシュします。他のキャッシュプロバイダにもサポートしていますが、クラスタ環境でのサポート対象は Ehcache のみとなっています。キャッシュプロバイダを変えるには、portal.properties で hibernate.cache.provider_class プロパティを変更します。Liferay をご利用頂いているお客様には、データベースクラスタを使ってパフォーマンスを改善されている方も多くいらっしゃいます。オープンソースの代替ソフトウェアとしては、よく http://sequoia.continuent.org/HomePage|Sequoia をおすすめしています。比較的大規模なクライアントの多くは、主にフェールオーバーを目的にデータベースクラスタリングを使われています。
JSP を事前コンパイルすることができます。実施できるパフォーマンス改善策としてはこれが唯一のものです。
はい、JavaScript、CSS、画像ファイルは、すべて Liferay でキャッシュできます。JavaScript や CSS については、いずれかのテーマの "templates" ディレクトリを調べてみてください。2 つの JSP ファイル――css_cached.jsp と javascript_cached.jsp があるはずです。これらのファイルが、ご期待どおりの動作をします。画像ファイルについては、データベースに格納された画像は他のオブジェクトと同じように OSCache でキャッシュされ、実際にサーバ上に配置されている画像はお使いのブラウザによってキャッシュされます (キャッシュを無効にした場合を除く)。
はい。ただし、2 つのポータルサーバが同一バージョンの Liferay を実行している場合に限ります。コミュニティから LAR をエクスポートすると、そのコミュニティのページ、ページ上でのポートレットのレイアウト、各ポートレットの設定、各ページで使用されていたテーマへのポインタがエクスポートされます。該当するテーマが利用できないポータルサーバに LAR をインポートした場合は、デフォルトのテーマ (ふつうは "classic") で代用されます。該当するポートレットが利用できない LAR をインポートすると、ポートレットのあった場所に、そのポートレットが利用できない旨のメッセージが表示されます。
1) portal-ext.properties で以下のパラメータをオーバーライドし、独自のログイン後アクションクラスを追加します。
login.events.post=com.liferay.portal.events.LoginPostAction,com.my_company.portal.events.LoginPostAction
2) 独自の LoginPostAction クラスは、com.liferay.portal.struts.Action を継承し、以下のシグネチャで run() メソッドを実装する必要があります。
public void run(HttpServletRequest req, HttpServletResponse res) throws ActionException
com.liferay.portal.events.LoginPostAction を参考にすることができます。
3) run() メソッドで、オブジェクトの取得、HttpServletRequest オブジェクトを介した HttpSession へのアクセス、セッションへのオブジェクトのセットに必要な任意の処理を行うことができます。
app.server.USERNAME.properties ファイルで、下記の 2 つのパラメータを追加します。
app.server.jboss-tomcat.deploy.archive.type=ear app.server.jboss-tomcat.deploy.archive.unpack=false
拡張環境から "ant deploy" を実行すると、ビルドスクリプトが物理 EAR ファイル (not an exploded version) の作成と JBoss 配備ディレクトリへのコピーを行います。
*注: 以上の内容は Liferay バージョン 4.2 以降に適用されます。
Liferay で画像を表示するには、2 つの方法があります。
1) ポータルへ画像をアップロードするのに使用できる "Image Gallery" というポートレットがあります。アップロードされた画像は以下のようにすることで HTML からアクセスできます。
<img src="/image/image_gallery?img_id=1001">
お気づきのとおり、画像を表示するためにはその ID を知らなければならないため、これは必ずしも画像へアクセスするための最適な手段とはいえません。しかし、おそらく最も手早く、負担のかからない方法です。
2) 画像はページのテーマに含めることができます。どのテーマも同一のディレクトリ構造を持ち、その中に "images" というディレクトリがあります。images ディレクトリ内で、さらに細かく分類したディレクトリ (例えば、blogs、ocument_library、message_boards など) に分けて格納することもできます。任意にディレクトリを作成して、必要な画像をここに置くことが可能です。ファイルにアクセスするには以下のような方法を使います。
<img src="<%= themeDisplay.getPathThemeImage() %>/your_portlet/some_image.gif">
新規ユーザをデフォルトのコミュニティに関連付ける方法は 2 つあります……ひとつは GUI を使って行うもの、もうひとつはプロパティファイルを使って行うものです。
GUI を使う場合、Admin ポートレットに行き、Users タブをクリックし、Default Associations タグをクリックします。"Enter the default community names per line that are associated with newly created users" というラベルのついたテキストボックスに、各コミュニティ名を改行区切りで入力します。最後に Save ボタンをクリックします。以降、新規ユーザが作成される度に、ユーザはデフォルトのコミュニティに関連付けられます。
(訳注: Liferay 6 を日本語表示で使っている場合は、管理権限のあるユーザでコントロールパネルを開き、左側サイドバーの「ポータル」カテゴリにある「設定」をクリックします。右側サイドバーの「ユーザ」をクリックし、「デフォルトの関連付け」をクリックすると、「コミュニティの管理」と書かれたテキストボックスがあります。ここにコミュニティ名を改行区切りで入力します)
2 つ目に、portal.properties の admin.default.group.names プロパティをオーバーライドすることで上記とまったく同じことが行えます。例えば、
admin.default.group.names=Support\nHuman Resources\nSales
コミュニティ名を "\n" で区切ることに注意してください……これが GUI での改行区切りに相当します。
現時点では、ユーザの初回ログイン時に表示するコミュニティページを選択する方法はありません。基本的には、リスト中のコミュニティをアルファベット順に並べたときに最初になるものが表示されます。上記の例でいうと、Human Resources のホームページが表示されます。
portal-ext.properties に以下の行を追加します。
hibernate.show_sql=true
Liferay v4.4 以降、組織が従前よりも大幅に強化されました。特に、組織を多階層化し、(組織のロールを通じて) 管理を委譲したり、ユーザが複数の組織に所属したりする (そして、組織ごとに別のロールを持つ) ことができるようになりました。
この機能強化を考慮に入れて、コミュニティとの主な違いを挙げると、以下のようになります。
Velocity テンプレート
##portal_normal.vm
#set ($myService = $request.getAttribute('myService'))
Foobar: ${myService.find('foobar')}
public class TemplatingRequestAttributesFilter extends OncePerRequestFilter {
private static final String MY_SERVICE = "myService";
private MyService service;
protected void initFilterBean() throws ServletException {
super.initFilterBean();
WebApplicationContext webctx = WebApplicationContextUtils.getWebApplicationContext(getFilterConfig().getServletContext());
this.service = (MyService)webctx.getBean(MyService.class.getName());
}
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException {
try {
request.setAttribute(MY_SERVICE, entryRetrieverFacade);
chain.doFilter(request, response);
} finally {
request.removeAttribute(MY_SERVICE);
}
}
}
web.xml
<filter>
<filter-name>TemplatingRequestAttributesFilter</filter-name>
<filter-class>de.kqv.liferay.filter.TemplatingRequestAttributesFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>TemplatingRequestAttributesFilter</filter-name>
<url-pattern>/c/portal/layout</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>TemplatingRequestAttributesFilter</filter-name>
<url-pattern>/c/portal/css_cached</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>TemplatingRequestAttributesFilter</filter-name>
<url-pattern>/c/portal/javascript_cached</url-pattern>
</filter-mapping>
Enterprise Admin ポートレットで 2 つの手順を踏みます。
これは非常に結論の出しづらい質問であり、本当にケースバイケースで回答する必要があります。Liferay の主な用途が CMS としてでありログインユーザがほとんどいない場合、ユーザあたりの処理数は非常に高い値になります。各ユーザがログインして、特定のポートレットやポートレットデータに対してカスタム権限を持つという利用が多いのであれば、同時接続ユーザ数はずっと少なくなるかもしれません。顧客がどの JVM を使用するか、JVM の設定をどうするか、どのサーブレットコンテナを使用するか、アプリケーションサーバを使用するかどうか、Liferay 内でどのポートレットやサーブレットフィルタを有効にするかといった点にもよります。各サーバに対して十分なメモリ量 (32 ビット OS では 2?4GB、64 ビット OS ではそれ以上) を確保することを必ずおすすめしていますが、ユーザ数が増加するにつれ、Liferay の性能はメモリよりも CPU によって影響を受けるようになることが少なくありません。これは具体的な内容はケースバイケースになりますが、Liferay に配備されたカスタムコードにも非常に強く依存します。また、一般的なボトルネックがデータベースである (そのため、データの多くは Liferay のセカンドオーダーキャッシュにキャッシュされる) ことを認識するのも重要です。
この分野でのtipsがいくつかあります。まず大事なのは「パフォーマンスチューニングは早期に行う」ということです。これは重要なタスクであり、経験を積んだテストエンジニアでもひと通り結果を出すのに少なくとも 2 週間はかかります――その結果によって、(1) カスタムコードを改善する、(2) ハードウェアをアップグレードする、(3) ハードウェアを追加する、(4) より新しいバージョンの Liferay にアップグレードする (メジャーバージョンアップごとにパフォーマンス改善が盛り込まれています)、といった対策を行うことになります。性能を束縛しているのが CPU なのかメモリなのかを判断するには、こちらのhttp://dsoguy.blogspot.com/2006/09/performance-tuning-tips-for-java-no.html|ブログを参照してください。一般には、たいていの場合、最初はシステムメモリに束縛されていることがわかり、(JVM のメモリ使用量をチューニングすると) 次に CPU に束縛されるようになる、といった流れになるでしょう。
James McGovern は Hartford Financial Services Group, Inc. (Fortune 100 企業です) のエンタープライズアーキテクトで、セキュリティを専門にしています。同氏は Liferay に対して独立したセキュリティ監査を実施し、非常に良好な結果を得ています。同氏のブログから 3 つの投稿を紹介します。
加えて、Symantec (アンチウィルスおよびセキュリティソフトウェアのメーカー) は sheets/ent-datasheet i3 J2EE 7.5.1 8 2006.en-us.pdf|i3 という自社製品に Liferay を使用していますし, Borland JBuilder にも faq.pdf|TeamInsight のポータルとして Liferay が同梱されています。
下記の 2 つのリンクでベンチマークの情報が公開されており、大規模なユーザベースで Liferay がいかにスケール可能かが示されています。
はい! バージョン 4.4.0 以降、コンテンツに @page_break@ トークンを挿入できるようになりました。
ゲストに対しては、portal-ext.properties で設定できます。ユーザに対してはテーマの portlet.vm をカスタマイズする必要があります。ファイルを以下のように修正してください。
#if ($permissionChecker.isCompanyAdmin($company_id)) $theme.iconOptions() $theme.iconClose() #end
こうすると、アイコンをすべてみられるのは管理者だけになり、他のユーザには最大化と最小化のアイコンだけが見えるようになります。 vm ファイルの修正後は、忘れずにサーバの停止・起動を行ってください。
[PageInfo]
LastUpdate: 2012-12-11 18:55:23, ModifiedBy: hozawa
[Permissions]
view:all, edit:login users, delete/config:members