Symphony.

I have a Symphony 2.2.5 installation with around 60 sections using 600 fields. Accessing the edit page for a single section (/symphony/blueprints/sections/edit/{id}/) sometimes takes around 20 seconds or more, sometimes it's rather fast. No, I don't know what triggers the extreme deviation.

Q1: Is there any known reason for the above phenomenon?

Q2: Does anybody know if the section editor has become faster or slower in Symphony 2.3? (AFAIK, there have been additions to it, which might mean that it's even worse now.)

There could be a couple of factors here, some I have experienced before.

1. Select Box Links with many entries (ie, more than the default 20)
2. Many Select Box Links in the page.
3. Lots of fields.

I think the only way to see if it is improved is to try an upgrade locally and test it.

Could it be that you mean the entry editor? I was referring to the section editor.

(The number of entries for a Select Box is no more than a number in the section editor.)

I think the only way to see if it is improved is to try an upgrade locally and test it.

Yep, one more thing on the list when I try and upgrade this biest. :-)

I just thought maybe someone has experience with this phenomenon…

How many fields does your largest section have?

I see two potential problems:

1. The Duplicator script is not optimised for large sections. This is problem in Symphony 2.2.5 and 2.3
2. The CSS is not optimized for really large sections. There were animations issues due to the usage of gradients in 2.3 but I think we fixed that already. There lies a general problem in the 2.3 stylesheets: a lot of things could not be changed due to compatibility concerns and thus a few areas (frames for example that are used by Duplicators) are overly complicated and way too specific.

The focus of 2.3 was to update things conceptionally, but no one found the time to clean-up and optimize things after the initial release.

If you are already having problems in 2.2, it would be important to know what causes these issues first.

Thanks for your feedback. Up to now, I am not even sure if the delay is in Syphony's HTML generation or in the browser. But I will check it out when it gets slow again and report back.

I believe Nitriques added some fixes to the integration branch that help speed up this section. It was found to have problems and delays painting and calculating the layout due to JS/CSS. A way to help narrow this down is to use Chrome dev tools and see if the delay is server generating the page or if its the painting of the layout.

Another factor would be the FileUpload field. Given I have lots of folders and subfolders in workspace folder, this particular line would increase loading time for section editor massively (up to 30s).

By adding some paths to ignore_list, all is good now.

Thanks for the input, guys. I will watch/debug it and tell you what it was.

Thinking again Michael, I remember a performance boost that was added to 2.3 to the FieldManager, which on a normal site, would give moderate gains, but of something to your scale, the savings would be huge.

In the 2.2.x branch, when you view the Section Editor page, Symphony grabs all of the fields for the section (by reading the fields table), and then queries each field to return the settings. The problem here is it's very linear, the number of queries to create that page is going to be 1 + number of fields. If you have a section with 60 fields, then that's going to be at least 61 queries to the database.

In 2.3, this was changed to be more sane, the FieldManager is smarter in that it can accept multiple field ID's, and if the field ID is omitted and it's given the section ID, it will group fields by type which greatly reduces the number of queries. So if you have 60 fields, but you are only using 5 field types, the number of queries is probably more like 6. A huge difference and one that will be massively noticed on a site of your scale.

Perhaps this is something that I can help with and we look at backporting those changes to your installation?

Vlad, that's very interesting! I never would of even considered that, but you are correct, if you had a number of directories then that function would begin to be expensive. Perhaps that function is a candidate for review, updating it to use the DirectoryIterator.

@vladG: Thanks for this pointer, I never noticed this. Great catch.

@brendo: Yes, it might be interesting to backport this if it turns out that the PHP part is the bottleneck. But I should also think about updating this installation some day, because it should run on the latest and greatest Symphony. :-)

Unfortunately at the moment the phenomenon is not occuring (of course…). I am sure it will come back.

Meanwhile I know that the bottleneck is in Symphony/PHP. It is not a rendering issue in the browser.

I have an idea what happens: Most of my sections include an SBL field. This SBL field has to render all available sections and fields, of course. And these are many. So my guess is: The issue is cause by the overall number of sections and fields.

Funny: Once the page gets loaded, a reload is rather fast — maybe because the query gets cached by MySQL?