home‎ > ‎その他‎ > ‎

スクリプト制限への第一歩

Original Title : The First Step Toward Script Limits
Original Post : Jack Linden, 2010/03/19 9:41:43


regionのパフォーマンス改善と土地所有者・コンテンツクリエイターによりよいツールを提供するという、長期計画の一環としてロードマップの一環として、スクリプトの明確な数値化とコントロール方法について作業を行ってきました。ここれまでregion内のアバター数とプリム数については制限がありましたが、スクリプトにはありませんでした。

この抜けのために、regionのパフォーマンス問題の原因の多くはスクリプトの過剰使用で引き起こされています。それゆえ最終的にregion上のスクリプト使用には上限を設けざるを得ません。一regionに過剰にスクリプトがあるとメモリ確保のためにそのregionのあるシミュレータが属するサーバ全体にパフォーマンス低下を引き起こします。これは他に何もしていないはずなのに影響を受けてしまう土地所有者にとって公平ではありません。また、あるparcelで過剰に使用されると同一regionの他のparcel 所有者に悪影響を与えます。

この計画は大まかに以下の3段階から成っています。

  1. 情报:第1段階では、スクリプト入りオブジェクト・装着物の負荷情報を詳細にresidentsに提供することです。残念ながらViewer 2とSnowglobeでしか機能しませんが、4月リリース予定のServer 1.38では、情報提供を提供します。我々はビューアを1.23にこの機能を追加するには、しかし、サードパーティの開発者や視聴者に統合することが期待されていません。
  2. ツール: プロジェクトの第2段階は、2010年以降になりますが、スクリプトの負荷を管理・コントロールするためのツールを提供する予定です。また、調整時間を必要なユーザに与えるために早期に制限についてのガイダンスを提供します。この制限では、スクリプトを多用しているregion以外の大多数のユーザには影響を及ぼさないでしょう。
  3. 実施: プロジェクトの最終段階は、最終的にregionレベル、region内にどれだけのサイズの土地を所有しているか-プリム数制限と同様-にもとづくスクリプト制限を最終的に実施します。制限値は高めに設定する予定なので、大半のユーザには制限実子に縁る影響はないでしょう。

つまり、情報、ツール、最終的な施行、です。

Server 1.38ではどのような情報を見ることができますか?

Server 1.38の導入後、Viewer 2.0を使用すると、About Land画面に新しいボタンが追加されます。このボタンからスクリプト・リソース(メモリ)の使用状況詳細画面が表示されます。Parcel上のオブジェクトに関するタブと、アバターの装着物のタブがあります。parcel所有者はparcel上のオブジェクト単位の詳細情報を見ることができ、リソースの消費場所特定と、必要であればそのオブジェクトの削除が行えます。estate owner や estate managerは、region全体のオブジェクトについての確認が行えます。

(※使用状況画面で確認できる)数値は何を意味しますか?

(※状況確認画面の)Landタブでは、同一regionに所有するparcel全体で使用されているメモリ量合計が数値で表示されます。プリム数の使用料がregion中の所有するparcel合計であるのと同様に、スクリプト・リソースにも適用されます。

例えば、2parcelを所有し、片方では小さな16kのスクリプトを実行し、もう片方で64kのスクリプト10個を実行しているとすると、640k + 16k = 656k という合計値が表示されます。

Avatarタブでは、現在装着しているものに含まれるスクリプト・リソースの数値が表示されます。

また両方のタブでは、同様にURL数の使用量も表示されます。この外部ウェブサービスと会話するためのHTTP-in機能で使用する外部URLも、スクリプトが消費する別種のリソースです。

技術的な話題..(なぜ数値を負荷読みすべきでないのか)

スクリプト使用状況で表示される数値はスクリプトに予約されているメモリ量で、実際にはスクリプトがそれ以下のメモリしか使用していなくとも、そのスクリプトが使える最大メモリサイズを表示します。なぜ我々は正確なメモリ使用量を表示しないのかと疑問に思われるかもしれません。理由は、スクリプトの正確なメモリ使用量は予測できず、また、ダイナミックに変化するためです。システムは、予期せぬメモリ量オーバを起こさずスクリプトが稼働するよう、リソースを管理する必要があります。オブジェクトをrez(同時にスクリプトのメモリ割り当てに成功)できるか、できたならrezした時点より多くのメモリを使用してメモリ・オーバーを起こさずスクリプト停止を招かないかどうか、を知る必要があります。予約メモリを割り当てるようにすることでスクリプトの挙動を予期することができるのです。

スクリプトは LSL あるいは Mono としてコンパイルすることができます。 LSLスクリプトの場合、1スクリプトでは単純なものでも常に16kのメモリを割り当てられます。シミュレータのメモリから16kのメモリブロックが割り当てられ、スクリプトはrezされた瞬間から常にそのメモリを使用できます。Monoスクリプトでは必要なだけメモリを使用することができます。もし数バイトのメモリしか使わないのであれば、シミュレータはその分だけを割り当てます。このことを利用して我々はMono virtual machineを紹介しました。極端なケースのいくつかではLSLの4倍のメモリを利用するものがあったので、Monoへの変更を必要なときにシングルクリックだけで行えるよう、Monoスクリプトでは64Kまでメモリを増やせるようにしました。

以来、それまでSecond Lifeでは不可能だったコンテンツを開発できるようMonoスクリプトに与えられた余分のメモリを多くのスクリプターが利用し、またその64Kのメモリ量に依存するようになっています。そのため初期段階ではこの64KをMonoスクリプト用の予約メモリ割り当て量として表示します。今年末までには、Monoスクリプトのこのメモリを64Kから4Kに下げられるようにする予定です。それまでは一般的にMonoスクリプトの方が実際は効率的ではあってもLSLの方が効率的であるかのような数値が表示されます。平均的なMonoスクリプトの実際のメモリ量は9KBで、LSLで常に使用される16KBよりも7KB少なくなっています。単純な機能にMonoを利用することは、大抵の場合、この消費量低減は考慮に値します。

我々は難しい選択を迫られました。片方では実際よりもLSLの利用するメモリ量を誇張し、もう片方では確保メモリ量を表示し短期間の間だけLSLが効率的であるかのように見えることを受け入れるか。我々は、MonoがまもなくLSLが確保する16KBよりも少ないメモリ量に定義できるようになることを念頭におき、プロジェクトの初期段階では実際に確保されるメモリ量を表示することを選択しました。Monoの確保メモリ量軽減が2010年第3四半期に実現し、スクリプト制限実施時に間に合うことを目標にしています。そうなればMonoは、メモリに重点を置くスクリプトにとって重要な選択肢となるでしょう。

そして?

4月にServer 1.38がリリースされた後、Viewer 2のインストールしスクリプト・リソース使用状況を確認していたき、どのように機能しているかを見て慣れ親しんでいただくよう推奨します。ただしこれはまだ初期段階であることをお忘れなく。可能な限り有用な情報を提供できるよう変更する予定です。

春から夏にかけて、スクリプト状況を活用するツール開発の作業に入る予定です。また、制限がプリムと同様に適切に保証されているか、Viewerが表示するスクリプトリソース使用状況のレベルに合わせて、もしあれば、制限がどのような影響を与えるかについて、話し合いを持ちたいと思っています。

ディスカッション

Comments