Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-80271

user_update_user always writes to database

    XMLWordPrintable

Details

    Description

      Currently the function user_update_user always writes to the database, no matter if actually anything has changed.

      This function is being used a lot in the whole moodle code, also of course in (core) auth plugins like auth_oauth2. In environments where a lot of people simultaneously try to log in to moodle this causes heavy load on the user table because a lot of concurrend writes are performed which is a bottle neck on some (many?) DBMS.

      IMO the behavior of user_update_user should be changed in a way that it only updates the user record if actually at least one attribute has changed. It also should not just pass the whole object to the record_update function, but only the attributes that actually changed (also improves performance).

      Contra:

      • On every call of user_update_user there will be a read on the database. If the user record has to be updated it will be an additional write operation. So compared to the current state there will be an additional read operation (which is not that bad because read operations usually are pretty cheap).

      Pro:

      • Only if there actually is a change there will be a database write operation which usually is the expensive type of database operation, especially if it is concurrent
      • In a DBMS cluster setup where there is a dedicated write node, the bottleneck is being reduced. The additional read operation should not be too expensive, because it can be distributed to (read only) other database slave nodes.
      • In a DMBS cluster setup write operations will always cause load because of replication. This effect will also be reduced.

      Attachments

        Issue Links

          Activity

            People

              phmemmel PhMemmel
              phmemmel PhMemmel
              Meirza Meirza
              Jun Pataleta Jun Pataleta
              CiBoT CiBoT
              Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 3 hours, 22 minutes
                  3h 22m

                  Clockify

                    Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.