CiviCRM Community Forums (archive)

Hi,

Was at a customer that was complaining about the speed of editing a contact (more than 10 sec to get the edit screen loaded).

After having checked that apache/mysql... configuration is ok, did compare with sandbox and a local install.

http://sandbox.civicrm.org/en/civicrm/contact/add?reset=1&action=update&cid=102&context=search

And we are above 10s too.

The problem seems to be a design issue:
Beside loading the page (that's about 2sec, not fast but understandable) it:
1) make one ajax request per phone
2) make one ajax request per email
3) make one ajax request per site
4) make one ajax request for the name of the employer

Ajax is fun, but super expensive when abused. There is a limit on how many requests are sent to the same server in parallel, each of these additional requests cost more than a second, and because they aren't done in parallel (and tend to have to wait on the images/css/tinymce...) to get queued, it's delaying being able to use the page.

It' the case here. there isn't a single reason I can imagine of the 4) for instance. It's stored on the same table as the first and last name, why aren't we simply putting in the initial request result ?!?

I haven't looked at the related entities, but it will obviously be much cheaper to put them in the initial request too.

How complicated would it be put them in the main page directly? it would make editing a contact with several phones and emails twice faster.

X+

Hi,

I'm not even convinced we need an ajax call to add a new phone/email. In principle, having a hidden html blob that is part of the initial page and that you copy should do the trick.

And then, there is quickForm, that will probably go all bananas because there is a new field and qfKey hasn't been updated or whatever crazy stuff it does.

Anyway, I think we should have as a rule that if something is loaded in 100% of the cases as an ajax request on the ready(), that's a bug and it should have been included in the initial page (can be as inline json, but part of the initial request, not a separate one)

X+

Prior to the current ajax implementation we used to load ~2-3 hidden rows for fields for each of the data elements that can occur multiple times. The base form was pretty huge and we could only allow a fixed max # of instances of phone, email etc. The current implementation perhaps went too far the other way and we should consider loading at least 1 instance of each enabled item on create and loading all the instances that have data on edit.

Can't load the "all" since there's an unlimited number of instances allowed. :-)

But you find better to load them one by one doing an unlimited number of ajax calls ?

Seriously, pretty sure the difference of speed between loading on the first form 1 or 20 emails is negligible.
X+

I have no idea what's better. I was just saying that there currently isn't a limit on how many of each of this can be used. It probably does makes sense to preload "N" and only use separate subsequent calls when folks need N+. (Keeping in mind that for some larger chunks like the Address block we might want to keep N pretty small.)

Hi,

Filled an issue: http://issues.civicrm.org/jira/browse/CRM-7973

I don't think requesting each related item as a separate ajax call has any benefit over putting them directly in the page, no matter where you start the requests. The problem is almost uniquely the request, not the place you fire it.

Each ajax request takes around 2 seconds to complete. if you have 10 emails+phone+websites, they won't be fired all in parallel, and they will also compete with other resources (css, js, images) that the browser is trying to download (according to my firebug).

Again, editing is more than 10 sec to be ready, mostly due to that. That's probably less accessible, doesn't save a lot of weight on the initial page, and is more resource intensive on the server.

Dave, even if you have more than N, you'll be faster to load all the N directly. Checking with the API, fetching 2 or 20 takes about the same time.

X+