Slow site

zebrafilm

Member
I have opened the form to public testing ( http://offerte.zuidwijkcarrosserieen.nl/publictest ) and details are in 'my sites'.

I am struggling to get everything at decent speed.
Form ajax is off
Element calculations have ajax on (most of them are hidden) because the results need to be processed further on in the form.
I have only a few validations done yet and will need many more. They seem to slow down everything the most.
Looking at load times, it seems every time we go to the next page (in multipage form) everything on the whole form is validated again.

Tips welcome!

PS we also have some switch issues in that server rack so extreme load times of + sec10 come from there....
 
I have only a few validations done yet and will need many more. They seem to slow down everything the most..
Only the current visible groups fields will be validated when you navigate between pages. I seems odd to me that validations would slow down the submission, what validations are you using - are they simple "not empty" ones, or are they doing complex db queries to work out validity?

Have you tried setting the form's 'Save part-edited records' option to 'no'? That might speed things up somewhat.

We don't really have anything set up to profile the form submission times, if you fill in the sites ftp details I could update our code to add some logging to show how long each part of the submission process is taking to see if that raises any areas that are slower than others.
 
OK added FTP details. This site developed another issue with the SEO URL's so for now it is back to plain URL's. Not sure if it was the update yesterday or some element wrong. At the moment FABRIK DEBUG is also on. (Not the PDF).

Yes most validations are 'non empty' but only a few up to now. Will need to set them to all fields.
I have 'unhidden 'the calculations' (Berekeningen) at the bottom. They do lookups and also take time of course.
Love to hear suggestions how to speed up or detect where the issues are.

For security the form: (need to be logged in)
http://offerte.zuidwijkcarrosserieen.nl/index.php?option=com_fabrik&view=form&formid=54&Itemid=111
 
OK, as of this commit:

https://github.com/Fabrik/fabrik/commit/e4911184012282b7853d34650c3a4d2c2a31cb9a

... if fabrik debugging is enabled (in our global options), and J! system debug is on, then loading a form with &fabrikdebug=2 will then bypass ANY and all redirects after submission, and just show an otherwise empty J! page with fabrik debug and J! profiler.

I also added profiler marks at the start and end of the main form model process(), just as a start on getting the submission processing profiled.

So we can now start adding the usual ...

PHP:
$profiler = JProfiler::getInstance('Application');
JDEBUG ? $profiler->mark('process: start') : null;
... type stuff to strategic places in the submission code, to give us a better understanding of where any potential bottlenecks may be.
-- hugh
 
Interesting :) Appreciate the work.
So I have replaced form.php with your new version. It seems it doesn't matter if I switch J debug on or off?
Then I should add your Debug code in the elements? group? form?
Not sure where to look for and how to interpret.

If I run the form I get an error after submit:
Fatal error: Call to undefined method FabrikHelperHTML::isDebugSubmit() in /var/www/vhosts/offerte.zuidwijkcarrosserieen.nl/httpdocs/components/com_fabrik/controllers/form.php on line 263
 
There are two files to replace to get this working: the second one is components/com_fabrik/helpers/html.php where the missing method (isDebugSubmit) is defined.
As a general rule, you should never replace only one (or a few) file from one commit but update the whole install because a bug fix or a new feature generally involves changes in more than one file.
 
Yes agree normally I update everything and of course this time only saw one file changed and thought....
Added the extra file but doesn't help me understand much what is going on and why.
My next step could be to disable all elements and start activating them group by group to see if it changes the behavior.
Might need to setup a test site because the client wants to start testing and using it.
 
To use it you have to turn J Debug on AND enable Fabrik Debug (in the Fabrik general options) AND add "&fabrikdebug=2" at the end of your URL.
 
Yes of course I have that. And yes it shows debugging info but beside seeing things like "Slow queries = 0' which I can relate to something, I see no way of checking why validations seems to take most of the time.
Every page changes takes forever with the spinning wheel....

Ajax validation takes 6 secs on a page with only one check.
When I switch of all other groups in the form, it speeds up enormous. Meaning validation is not limited to the visible group/page but every time it seems to validates all element in the form.

Also noticed looking at what gets loaded that despite the Form Ajax checking being off, it seems to still load and delay.
Not sure if you set individual elements to use ajax validation, the whole form automatically switches on, despite backend settings.
 
What I've added so far is really just the start, so we now have the ability to add profile marks in the code, to gain insite in to where any delays are happening.

And yes, best bet is if you can clone this to a test site, and I can then get in and start putting those profiling checkpoints in.

-- hugh
 
Added an extra test site to one of my fast test servers. Shows up in the list. Feel free to play around. There is a bit time pressure of course. Client wants to go live after taking almost a half year to make decisions....(whats new). I'll update from Github with todays version too.
 
Sorry, had a bad day on Friday - recovery form surgery is going very well, but I'm still occasionally having a day that needs more narcotics than my brain can still work on - then got distracted by the weekend. Theoretically it's the Labor Day holiday today here in the US, but I'm working. I'll look at that test site now.

-- hugh
 
Hmmm, not much luck with the test site:

"Error displaying the error page: Application Instantiation Error: Could not connect to MySQL."

-- hugh
 
mm thats super annoying knowing how you are fighting with your energy. Seems the VestControlPanel is not the most reliable one. MYSQL server gone. Anyway I'll give it a last change, everything is up again.
I'll prepare an extra copy on another server and will add it to the list, just in case. Appreciate your efforts (a lot)

Update: both test sites up and updated with latest Github
 
Yes. I just wanted to make sure you'd updated since I committed them, as I think I may have done that after your post about updating.

Apologies for not getting round to this last night, I'm about to go take a look now.

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top