OptimizingPlone
概要
Ploneがバージョン1.0までの間は、APIはまだ不安定だとせざるを得ません。これはいくつかのものをドラスティックに移動するかも知れないということです。最近Ploneのパフォーマンスについて良く聞かれます。このページは現状で、Ploneの最適化と現実世界での例の概略を述べるものです。このドキュメントは完全ではありません。
現状
- Ploneにはいくつかの指摘されるべき点があります。それはデバッグ方法に関するものです。Ploneは当初たったの2人で始まりました。出来る限り速くなるようにして来ました。
- Ploneは柔軟でほとんどのシチュエーションに適合するように作られました。この一般的な視野に立つと、我々はいくつかのパフォーマンスの問題でうまく行っていません。いくつかのユーザビリティの問題についてもです。例えば、ヘッダに@importを書き出してしまうスクリプトなどです。これはパフォーマンスと柔軟性のために行われました。現実世界では、この関数呼び出しを外し、@importをハードコーディングすることに置き換えています。これによりデザイナーがマクロを開いたとき、スタイルシートを見ることになります。
- ユーザビリティの観点から物事を正しくしようとする最大限の努力が払われました。時には、これはパフォーマンス上のコストとなります。例えば、plone_ui_slots/workflow_review_slot.ptは、高価なmy_worklistsを呼び出します。これは、あなたが見れるすべてのworklistにあるすべての未処理タスクを合併しようとするためです。すべてのシステムに置いてそれぞれのページに対してこれを行うのは非現実的で、それが呼び出されたものやworkflowやページによっては隔離されているべきです。
- ものごとは今動いている際中です。最近まで右/左側のカラムにあるすべてのslotsはportal_boxesという1つのファイルに含まれていました。これは今は違います。これらのui slotsはそれぞれ分割されたフォルダのPage Templateに移動されました。今は、これらのslotsはより簡単にカスタマイズ、追加できますし、すぐれたアップグレード方法を持っています。まだまだ移動しようと思っているものはたくさんあります。portal_buttonsやportal_tabsなどです。
最適化のアイデア
- すべてのui_slotsをショートサーキット可能にする。
- マクロをインラインできる。
- SQUIDを使う。Ploneのすべてのコンテンツを提供するわけではない。Ploneはマイヤフーとなることを意味しているわけではない。
- 並のハードウェアで最低20リクエスト/秒でヘッダが返されなければならない。
- plone_tabs/plone_barsは現在とても遅い
- CSSの絶対パスをインラインにすることと@importをレンダリングするのに特別な関数コールをしなくてもよくすること(ドキュメントに必要)。
- footerは何もしていない。リクエスト/秒の上限となるべきだ。
- カレンダーはショートサーキットされるか、結果をキャッシュされるべき。ページリクエスト毎にカタログをクエリーするのは馬鹿らしい程高価である。
- main_templateはfooterのリクエスト/秒の半分以下を目指す。
- キャッシュ戦略(Zopeの内部キャッシングサービスを利用する必要がある)。
- カタログの結果(カレンダー、ニュースなど)
- ユーザのためのsecurity_info。checkPermissionを呼ぶ必要がないときはしない。
- メンバーのrosterをキャッシュする。
- getActionUrlByIdについて。Ploneにはそれは謎だ。cherryにactionsを取り出さなければならない。1つのページビューのためにはlistFilteredActionsFor()は1回だけの呼び出しにしなければならない。それは高価だ。
- Plone coreにslotが挿入される前に、それがどのくらい高価的かをいくつかのマイナーなベンチマークを取らなければならない。
- たくさんのslotに関する問い合わせは、portal_slotsツールに偏りすぎる。slotsを中央に集め管理したい。
- CMFは遅いが、スピードの改善はパイプラインになると期待している。すでに起動時の相当のスピードアップを見ている。
現実世界
現実は、管理者がいくつかのベスト・プラクティスに従って、サイトを成功させるように命令する。結局、ここにより情報が集まることを期待する。しかし、それが集まるまでは、パフォーマンスに関するトリックとして取るべき手段は、
- すべてのイメージ/ファイル/静的コンテンツはApacheかSQUIDによって提供されるべきだ。それに関するHOWTOはたくさんある。
- Filesystem Directory Viewを作ってそれをskinpathに置いた場合で、skinの中から
のように呼んだ場合は、それはskinpathにあるので動作する。しかし、絶対パスを使わない場合は、あなたのいるベースhrefから呼ぼうとし、そのイメージを何度も呼び出すことになり、ブラウザがそれをキャッシュするチャンスが与えれられないだろう。 例えば、あなたが/cmf/reportsにいて、上で言ったimgタグがページにある場合、それはhttp://mysite/cmf/reports/my_image.gifをフェッチする。
しかし、あなたが例えば/cmf/marketingに居て、上のimgタグがページにある場合、http://mysite/cmf/marketing/my_img.pngをフェッチするだろう。
これはあなたがイメージに絶対パスを与えていないために起こる。それは獲得が働いているために動作する。しかし、イメージを何度もリロードするためにそれは良くない。これを防ぐためにタグを
のように直すべきだ。
