SparkDevNetwork
Registration Template Detail Block can cause high CPU
Description
The Registration Template Detail Block (Obsidian variant apparently), can become very slow to interact with seemingly due to heavy CPU utilization on the browser/tab.
This was seen when adding/editing a Registration Form with many Registrant Attributes in the form.
Actual Behavior
After adding (or editing) many Registration Form Registrant Attributes (20+), the responsiveness of the page/block gets worse and worse. The more edits made, the worse it gets. Appears that each edit causes more and more GET requests (/api/ReminderTypes/ReminderTypesExistForEntityType?entityTypeId=234) with each subsequent edit. When making 1 or 2 attribute edits to the form, the block is responding typically. However, after 15-20+ edits, it gets increasingly slower. The number of server requests send from the browser (viewed in Developer tools) increases with each subsequent edit. For example, the first attribute edit will list about 7 requests. After 10 edits, it is 30 requests (per click on Edit). After 20 edits, it is 50 requests. (request log was cleared each time).
After the ~20 attribute adds/edits, the block becomes almost unusable and very laggy. Saving the Registration Template, and then clicking Edit again seems to "reset" whatever is building the requests.
Expected Behavior
Adding/Editing ~15-20+ attributes to a Registration Template form should not cause CPU spikes and cause such a severe performance issue with the block.
Steps to Reproduce
- Go to 'Event Registration'
- Select a Template (e.g., Connection -> Baptism)
- Click 'Edit'
- Expand the Registrant Form(s).
- Add Registration Attribute to the form:
- Click +
- Set Source to Registrant Attribute
- input name, e.g., test1
- Click Save
- Repeat above 15+ times, e.g., test2, test3,...
Responsiveness of the block will degrade. becomes especially noticeable around 10+. Watching the Developer tools, Network Requests; one will notice many, many requests occurring (thousands if let to build, or an increasing number with each attribute added, if cleared before each attribute added).
Similar situation occurs if you open an existing Template/Form and just repeatedly click the Edit pencil next to an existing Attribute and click Save. So, this issue is not limited to "adds" per se, it seems to be related to the number of edits or changes made before Saving the Registration Template.
Issue Confirmation
- [X] Perform a search on the Github Issues to see if your bug or enhancement is already reported.
- [X] Reproduced the problem on a fresh install or on the demo site.
Rock Version
16.6
Client Culture Setting
en-US
@stevelipinski Hi Steve I wasn't able to recreate the performance issue on the Registration Detail block on the demo site (v16.6) or on prealpha. Please confirm if you're still experiencing the problem on prealpha.
I recreated on demo and the registration form is still there: https://rock.rocksolidchurchdemo.com/web/event-registrations?RegistrationTemplateId=1&ExpandedIds=C174
You need to edit the Form and edit a form attribute like 15x or so and it will start to appear.
I'll double check on another PC/browser just to make sure it isn't something local to my browser. But, I did see the number of HTTP requests happening increasing with each attribute "edit"
@chead4 I was able to reproduce this issue both on the demo site and on an empty local environment.
I was able to track down the issue to line 142 of ReminderLinks.ascx.
The issue is that the refreshReminderCount() function being added to the load event one additional time for each postback.
This means that on every postback, refreshReminderCount() runs once for each postback that has happened. That means if there has already been 50 postbacks, on the next postback refreshReminderCount() function will run 51 times.
Running the refreshReminderCount() function that many times on every postback can lead to high CPU usage. I managed to hit 10% usage just for that browser tab after 70 postbacks. And that's on my powerful laptop. On something with a less powerful CPU such as a phone, this would have a significantly larger impact.
