[1.7.8.5] Backoffice very slow - Notification and AdminStat

[Myo]

Hello everyone.

After several days of unsuccessful research, I have come to ask you for help.

For several weeks, I have huge slowdowns in my backoffice, on almost all pages. I have to wait for all ajax requests to complete before I can do anything.

I'm pretty sure the problem is with the notification system when there's a new order/customer/message but I haven't been able to verify that.

I also think stats also slow down pages. I attach my log when launching the Catalog > Category page :

This is all I tried to disable the notifications:

• Advanced Settings > Administration: Notification, all disabled
• Disable the "Order Notifications on the Favicon" module
• Empty the ps_connections, ps_connections_page, ps_connections_source tables
• In classes/Notification.php, I forced the function getLastElements() returned an empty array
• Cache cleared

All these changes have not changed anything, the requests are still all sent.

Unfortunately I can't activate profile mode on my shop, all pages crash when I activate it.

Does anyone know how to disable these notification requests?
Same remark concerning the AdminStat requests which are launched on the pages which have a header with statistics, for example the list of customers which displays the average age of the customers. I don't want to disable my store stats, just turn off sending the request directly in the code if need be.

Thank you.

Edited August 3, 2023 by Myo (see edit history)

[Myo]

Does anyone have any idea how/where to disable the call https://xxx.com/admin123/index.php/common/notifications?_token=xxx ?

[Nickz]

A slow backend could well be a serverissue, shared server with wordpress and Prestahop behave sluggish. 

[Myo]

I have 2 prestashop on the same server, the other is in a lower version, it contains more customers, more orders and more products. Both have the same modules but all the pages of the BO of the first site load in 1 second while the 2nd load in 5-8 seconds. I'm pretty sure the problem isn't with the host.

[Nickz]

Higher version need more energy. Similar to OS in PC, Laptops or phones. 

[Myo]

8 times more energy? From 1.7.7.2 to 1.7.8.5 ? I do not believe it.
Do you know how to turn off notification calls?

[Nickz]

You could comment it where its called from.

[Myo]

And... where is it called from?

Please re-read my first post before giving me your answer.

[Nickz]

No christal ball here, that depends on version and theme, modules. 
f12 could help.

have you empried caches after turing off those notifications?

[Myo]

Cleared cache, I also cleared the contents of /var/cache/

What are you looking for in F12? the call comes from main.bundle.js but I just can't find the source.

I'm on 1.7.8.5

Where can I go to disable the prestashop default call?

[Nickz]

4 hours ago, Myo said:

Where can I go to disable the prestashop default call?

no clue, but it could be that @musicmaster has an idea ?

[Myo]

@musicmaster Be my hero please

[musicmaster]

2 hours ago, Myo said:

@musicmaster Be my hero please

I don't think those calls will take up so much time. It would be a better idea to enable _PS_DEBUG_PROFILING in /config/defines.inc.php and look whether some queries take too much time.

But if you want to play with those notifications: the only thing that I could find that main.bundle.js is included in /classes/controller/admincontroller.php. The relevant part looks like:

    public function setMedia($isNewTheme = false)
    {
        if ($isNewTheme) {
            $this->addCSS(__PS_BASE_URI__ . $this->admin_webpath . '/themes/new-theme/public/theme.css', 'all', 1);
            $this->addJS(__PS_BASE_URI__ . $this->admin_webpath . '/themes/new-theme/public/main.bundle.js');

            // the multistore dropdown should be called only once, and only if multistore is used
            if ($this->container->get('prestashop.adapter.multistore_feature')->isUsed()) {
                $this->addJs(__PS_BASE_URI__ . $this->admin_webpath . '/themes/new-theme/public/multistore_dropdown.bundle.js');
            }
            $this->addJqueryPlugin(['chosen', 'fancybox']);
        } else {

But I have no idea what $isNewTheme is for...

 

[Myo]

Quote

It would be a better idea to enable _PS_DEBUG_PROFILING in /config/defines.inc.php and look whether some queries take too much time.

I can't

Quote

Unfortunately I can't activate profile mode on my shop, all pages crash when I activate it.

 

[musicmaster]

On 7/28/2023 at 4:23 PM, Myo said:

Unfortunately I can't activate profile mode on my shop, all pages crash when I activate it.

I have never seen an error message like this before. I would like to see what is on that line 2013 but I have no idea how that could be achieved. I hope someone else can advise on that.

 - Obviously something more serious is wrong with your shop. But I have no idea what. Did you have a look at the server's error log?

 - Did you try to solve your speed problem by outcommenting the line with "main.bundle.js" in the code I mentioned?

 - Try to disable statistics modules

 

[Myo]

Quote

But if you want to play with those notifications: the only thing that I could find that main.bundle.js is included in /classes/controller/admincontroller.php. The relevant part looks like:

I disabled the import of the bundle and the notifications are no longer called. Unfortunately, my BO is still slow, but I'm glad I can dismiss that point, thanks for the advice.

I managed to display the profiling but only from the Dashboard page. I'm not sure where to look to identify the problem, do you see something suspicious?

[musicmaster]

The loading time of this page looks reasonable.

So your main problem is those AdminStats calls that you mentioned in your initial report.

What are your settings for the StatsData module?

 

[Myo]

I managed to disable all AdminStat calls and saved 2 seconds of loading on the affected pages, but I realize that the longest loading time is on the server side.

The only page where I managed to display the profiling is the fastest on the site, it is unfortunately not representative

I also tried disabling all languages but no change. 

[DavideZ]

Who initiate the calls to common/notifications is the getPush() function in ..../js/admin/notifications.js (on a 1.7.8.8)

In development I've commented the 

setTimeout(getPush, 120000);

line, not for performance, but because if I have "some" browser tabs opened in admin pages, debugging with symfony profiler become difficult, as it will be filled with the notifications requests.