「パフォーマンスおよびスケーラビリティ」の版間の差分

提供:MoodleDocs
移動先:案内検索
編集の要約なし
編集の要約なし
11行目: 11行目:
===すべてのページで決まった数のデータベースクエリしか使用しない Every page should only use a fixed number of database queries===
===すべてのページで決まった数のデータベースクエリしか使用しない Every page should only use a fixed number of database queries===


* Be very suspicious if you ever see database code inside a loop.
* ループの中にデータベースコードがある場合、非常に疑ってください。
* ループの中にデータベースコードがある場合、非常に疑ってください。
** This is sometimes hard to spot if the database access is hidden in a function.
** This is sometimes hard to spot if the database access is hidden in a function.
** これはデータベースアクセスが関数の中に隠されている場合、発見が難しいことがあります。
* Instead use JOINs and subqueries. (<tt>get_records_sql</tt>, <tt>get_recordset_sql</tt>, etc.).
* Instead use JOINs and subqueries. (<tt>get_records_sql</tt>, <tt>get_recordset_sql</tt>, etc.).
** Or look for a Moodle API function that gets the information you want as efficiently as possible. (For example, <tt>get_users_by_capability</tt>)
** Or look for a Moodle API function that gets the information you want as efficiently as possible. (For example, <tt>get_users_by_capability</tt>)

2022年2月2日 (水) 15:01時点における版

作成中です - Mitsuhiro Yoshida (トーク)

パフォーマンスとはMoodleが一定のハードウェアで可能な限り多くのユーザをサポートできるようにすることです。

もちろん、あなたはいつでも大きなサーバを購入できます。「スケーラビリティ」とは2倍の性能のサーバを買った場合、2倍の負荷に対応できるようにすることです。

このページはMoodleコーディングガイドラインの一部です。

スケールおよびパフォーマンスのためのコードを書く Writing code that scales and performs

すべてのページで決まった数のデータベースクエリしか使用しない Every page should only use a fixed number of database queries

  • ループの中にデータベースコードがある場合、非常に疑ってください。
    • This is sometimes hard to spot if the database access is hidden in a function.
    • これはデータベースアクセスが関数の中に隠されている場合、発見が難しいことがあります。
  • Instead use JOINs and subqueries. (get_records_sql, get_recordset_sql, etc.).
    • Or look for a Moodle API function that gets the information you want as efficiently as possible. (For example, get_users_by_capability)
    • See the Database guidelines for how to write SQL that will work on all our supported databases.


Limit the amount of RAM each page requires to generate

  • Large reports should be broken into pages of a fixed size.
  • Processing large amounts of data from the database should be handled with a recordset (when you cannot do all the processing in the database with SQL) and using recordset_walk iterator, as there is no RAM benefit on using recordsets if you load all the results in a massive PHP array.


Be cautious about other external calls

Like a database query, there are other operations that are much slower than just executing PHP code. For example:

  • running a shell script
  • making a web-service call
  • (to a lesser extent) working with files.

Whenever you are doing these things, worry about performance.

How to improve the performance of your code

Measure during development

  • Use tools like JMeter to subject your new code to load.


Measure in production

  • If you're using postgres, there's a script that can parse the logs and output the top 10 slow queries, ready to be plugged into a cronjob to email you every day. It can be found here:

http://git.catalyst.net.nz/gw?p=pgtools.git;a=blob_plain;f=scripts/pg-log-process.pl;hb=refs/heads/pg-log-process-multidb

You need to configure postgres a bit to make it log things in the correct format. Instructions are in the file.

How big can a Moodle site be?

Looking at the statistics, the largest sites in the world currently have

  • Up to 1 000 000 users
  • Up to 50 000 courses
  • Up to 5 000 users per course
  • Up to 50 roles
  • Up to 100 course categories nested up to about 10 levels deep.
  • Up to XXX activities in a course.
  • Please add more things here.

When planning and testing your code, these are the sorts of numbers you should be contemplating. However, do not assume that Moodle sites will never get bigger than this.

Even if you can't test sites this big on your development server, you should use the generator script so you can test your code in a Moodle site that is not tiny.


関連情報