jrchamp
commented
3 years ago It looks like it's doing two service calls per page view:
https://github.com/ucla/moodle-mod_zoom/blob/4784e5bd3e1c3f9d80ec71a8a25c2987375d6173/view.php#L56-L64
The first one is running just to check if the meeting exists so that it can use the thrown moodle_exception to show the recreate notification:
https://github.com/ucla/moodle-mod_zoom/blob/4784e5bd3e1c3f9d80ec71a8a25c2987375d6173/view.php#L90-L100
It seems like it would be safe to throttle/cache those checks so they don't occur more than once per minute or so. Really Zoom will tell them that it's broken, so it might be easier or perhaps better to only perform the "does meeting exist" check inside of if ($iszoommanager) {
The second service call is looking up the user information. Since this is used to display helpful text about the name of the host, this may be another good place to throttle/cache the lookup so that it's not happening for each student: https://github.com/ucla/moodle-mod_zoom/blob/4784e5bd3e1c3f9d80ec71a8a25c2987375d6173/view.php#L177-L186
Has any one else seen knock on performance issues with the view.php page?
I noted that this page makes a call to the Zoom webservice to update the webinar_info.
All of our teaching is scheduled on the hour and we've see big spikes in the time to load this particular page, and I'm wondering if there is a possible bottleneck happening.
Given that a call will be made to Zoom for the same meeting for each student, if you have a class of 200 students, you'd expect to get 200 calls to get the latest meeting info for the same meeting.
(You then scale this up for the however many classes are running at the same time...)
Within a (small) timescale this data is unlikely to change, so could this benefit from some caching of the result to reduce API calls to Zoom? Given the expensive nature of assembling the call, network time etc, we're hypothesising that these could be back-logging.