Hi, we built a site in 2017 using Umbraco Forms 4.4.7 on Umbraco 7.5.14 for one of our clients and it’s been running without issue for over a year until yesterday when a newly added form starting showing problems with submissions taking a long time.
The site is hosted on AWS and so displays a 504 Gateway Time-out error as the form submission page takes too long to respond (up to 6 minutes). The form will usually work once per session and then on further submissions in the same session it times out.
I’ve tried debugging the issue, inserts into UFRecords look to run OK but the trace shows a lot of “In member mode” and “Parsing Member placeholders stop” items which on occasion have large time intervals between them suggesting a lock up somewhere.
Umbraco Forms supports the use of curly brackets as placeholders for variables in key parts of the form process - and throughout the code makes calls to an extension method called
ParsePlaceHolders()
that does the replacing of the {someAlias} with the substituted value.
This occurs when a record is persisted to the database.
Within the ParsePlaceHolders() method is another extension method called ParseMemberPlaceHolders() which writes out the trace messages you describe above eg 'Parsing Member placeholders stop' and is responsible for replacing any {magicStringAlias} with values from the current logged in member who has filled out the form...
The bit that I can see might be causing a delay is this method uses the MemberService GetById method to return the members details and this will hit the database - the details of the Member is cached for one hour, so be interesting to see if immediately filling in the form a second time, is submitted 'much quickerly' as this would indicate that this is where the problem lies.
All properties of the retrieved Member are added to a dictionary to consider for the replacing (so if your logged in members have a hundred properties, this might also be where a delay is caused!) - again the retrieval of these properties is cached for an hour.
Once the properties are retrieved, then they are looped through to do any replacing, I can't imagine this would have a huge impact on time though, it is just string replacement.
So if a 'second entry is quick' the next thing to test would be how long does the following take to run:
Current.Services.MemberService.GetById(memberId);
How many Members are in the site, are the SQL indexes for the Membership tables up-to-date or fragmented?
Thanks for the detailed reply, all good stuff to keep in mind for future development.
Currently the site with the issues doesn't have any Members and the forms don't have any placeholders. However, further review of the logs and tweaking the workflow has led me to believe that the issue is actually with the Amazon Simple Email Service as the delays look to correspond with sending email notifications to administrators.
ahh cool, yes, was interested in what was happening between those two traces... and what could be causing it to be slow there... but yes more likely there is a lag with sending email... or have had issues with indexes on the forms tables before...
Slow form submission on Umbraco Forms 4.4.7
Hi, we built a site in 2017 using Umbraco Forms 4.4.7 on Umbraco 7.5.14 for one of our clients and it’s been running without issue for over a year until yesterday when a newly added form starting showing problems with submissions taking a long time.
The site is hosted on AWS and so displays a 504 Gateway Time-out error as the form submission page takes too long to respond (up to 6 minutes). The form will usually work once per session and then on further submissions in the same session it times out.
I’ve tried debugging the issue, inserts into UFRecords look to run OK but the trace shows a lot of “In member mode” and “Parsing Member placeholders stop” items which on occasion have large time intervals between them suggesting a lock up somewhere.
Is there anything further I can do to debug this?
Could the AWS hosting be an issue?
Hi John
Umbraco Forms supports the use of curly brackets as placeholders for variables in key parts of the form process - and throughout the code makes calls to an extension method called
ParsePlaceHolders()
that does the replacing of the {someAlias} with the substituted value.
This occurs when a record is persisted to the database.
Within the ParsePlaceHolders() method is another extension method called ParseMemberPlaceHolders() which writes out the trace messages you describe above eg 'Parsing Member placeholders stop' and is responsible for replacing any {magicStringAlias} with values from the current logged in member who has filled out the form...
The bit that I can see might be causing a delay is this method uses the MemberService GetById method to return the members details and this will hit the database - the details of the Member is cached for one hour, so be interesting to see if immediately filling in the form a second time, is submitted 'much quickerly' as this would indicate that this is where the problem lies.
All properties of the retrieved Member are added to a dictionary to consider for the replacing (so if your logged in members have a hundred properties, this might also be where a delay is caused!) - again the retrieval of these properties is cached for an hour.
Once the properties are retrieved, then they are looped through to do any replacing, I can't imagine this would have a huge impact on time though, it is just string replacement.
So if a 'second entry is quick' the next thing to test would be how long does the following take to run:
How many Members are in the site, are the SQL indexes for the Membership tables up-to-date or fragmented?
https://docs.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes
regards
Marc
Marc,
Thanks for the detailed reply, all good stuff to keep in mind for future development.
Currently the site with the issues doesn't have any Members and the forms don't have any placeholders. However, further review of the logs and tweaking the workflow has led me to believe that the issue is actually with the Amazon Simple Email Service as the delays look to correspond with sending email notifications to administrators.
Thanks,
John
ahh cool, yes, was interested in what was happening between those two traces... and what could be causing it to be slow there... but yes more likely there is a lag with sending email... or have had issues with indexes on the forms tables before...
is working on a reply...