Speed issues in CMS

[RVXD]

We used this module in a lot of our sites and noticed a major decrease in speed of the CMS. Especially if used in combination with more complex pages with many elemental blocks, the CMS can become unusable. Each time a page is opened in the CMS, the frontend is completely rendered (templates and image resizing). This takes up a lot of resources and slows everything down. Removing the module increased CMS speeds from 20 seconds to 2 seconds loading time on heavy pages.
It would be better if the module only calculates the scores on request and not always.

[hubertusanton]

Hi remy, Thanks for reporting, I'll check this out and fix it. Whats the number of blocks? Maybe i can repoduce problem by creating blocks Best regards, Bart

…

________________________________ Van: Remy Vaartjes <notifications@github.com> Verstuurd: donderdag 12 november 2020 09:25 Aan: hubertusanton/silverstripe-seo Cc: Subscribed Onderwerp: [hubertusanton/silverstripe-seo] Speed issues in CMS (#40) We used this module in a lot of our sites and noticed a major decrease in speed of the CMS. Especially if used in combination with more complex pages with many elemental blocks, the CMS can become unusable. Each time a page is opened in the CMS, the frontend is completely rendered (templates and image resizing). This takes up a lot of resources and slows everything down. Removing the module increased CMS speeds from 20 seconds to 2 seconds loading time on heavy pages. It would be better if the module only calculates the scores on request and not always. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#40>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAEOELHMFGWZNHUGRN7AQZTSPOLYRANCNFSM4TS7BFRA>.

[RVXD]

Hi Bart,

if you create a page with 10 blocks and another with only one block. You notice the speed difference between the two.
Also making Page.ss empty and reloading the page in the CMS, makes the difference clear.
In my case I have a page with multiple gallery blocks, a form and some basic content. Each block has approx. 6 large images.

Probably the larger the HTML source, the larger the images, the slower it gets.

Of course one could argue, to make the frontend faster, but this is not always easy.

Each time a user loads the page in the CMS the function getPageContent is called to render the entire HTML content and parse the DOM, but most of the time the module results are not needed, because user is only editing basic content:

public function getPageContent()
    {
        $response = Director::test($this->owner->Link());
        if (!$response->isError()) {
            return $response->getBody();
        }
        return '';
}

The server I use has 4 cores and 8GB memory. PHP memory_limit set to 512MB.

Regards,
Remy

[hubertusanton]

Hi remy,

What about creating a setting to let a page type not reindex score always but do this reindexing score with a button/action in the cms?

[OldStarchy]

In my testing, I've worked out that loading the edit page in the cms CMS causes the frontend page to render 7 times.

This is likely causing huge slowdowns considering that each call to getPageContent will also run any database queries invoked by the templates. Caching the return value of that function should speed up the score calculation.

I'll make a PR for this, but I'm going to target v2.2.1 first as that's what we're currently using and upgrading isn't an option for us at the moment.

[OldStarchy]

In my tests just now, for a page with 2 blocks, caching the page content took load times from 23s to 5s.

[OldStarchy]

I can't create a PR for 2.2.1 since there's no branch pointing to that version 😢.

Here's the code that I would have put in a PR

	public function getPageContent() {
		static $cache = [];

		if (!isset($cache[$this->owner->ID])) {
			Config::inst()->update('SSViewer', 'theme_enabled', true);
			$rendered_layout = $this->RenderLayout();
			Config::inst()->update('SSViewer', 'theme_enabled', false);

			$cache[$this->owner->ID] = $rendered_layout;
		}

		return $cache[$this->owner->ID];
	}

[hubertusanton]

hi @OldStarchy

That's a great load time improvement! Why are you using 2.2.1?
I create tags (versions) from the master branch when i think it is 'releasable' as a version, not sure thats the way to go though. If you'd like I can create a branch for 2.2.1 if this helps? Or you can add this to master and then we create a new release/ tag from this ?

[OldStarchy]

Why are you using 2.2.1?

Unfortunately upgrading to SS4 isn't an option for this project at the moment.

If you could create a 2 branch that would be great, I'll submit a PR for 2.2.2

not sure thats the way to go though

So long as it makes sense, its probably good enough

Or you can add this to master

I'll make 2 PRs, one for the 2 branch and one for master, which should get you a 2.2.2 tag as well as a 4.1.2 .

[hubertusanton]

@OldStarchy Thanks a lot, i created the 2 branch! Hope this helps

[OldStarchy]

During my testing on SS4 I've encountered an issue: silverstripe/silverstripe-framework#10106