For the Senior dev: One modules slows down whole site...

[Smile]

Since a few days my Prestashop was quite slow... As we were in the progress of moving to TB it was not something I was worried of...  Yesterday we moved over.... And the speed issue did not improve. The speed is sometimes ok and sometimes 30 sec for a page! As it became worse and wors and we had just an advertorial out also the customers increase slightly... But nothing out of the ordinary... I mean 7-to max 15 users together... 

 

As it became so slow I asked a senior developer to have look into the server. It is costing me money.... The server is a VPS with 2 vCPU and 2 gig ram (centOS/whm/cpanel) ect... A decent server... He searched extensively and could not find the issue.... He came to the folowing advice:

That loading one page needed (to much) CPU. Opening a product page starts multiple processes on the load increases a lot... As one page has also advised other product but often not more than 5. This could be an issue....

That one module is slowing down everything...

 

It's difficult to remember what changes we did do most changes where nothing out of the ordinary... I think... We added one PWA app but disabled it as we were afraid this was the issue...

Some them tpl and css changes...

 

Anyhow the advice was, start clean and disable / enable modules to find the problem. But well this is not so easy as you can not really monitor the changes on a clone on the live server....  Or his other advice was take a clean instalation an buit the store up again adding one module and so on.... Also he mentioned overrides are a mess... so maybe start there....

 

The question is how can I see what module uses / needs so much CPU? How can I dig into this issue? Without buying a second VPS? Although, maybe I can rent one for a month.... Any trick to solve this issue quick? 

[wakabayashi]

Well you need to check them file by file and see what is in there...

[Smile]

So what would be the way going forward:

Go along every override file:

- Determine what module is using it, if possible.

- Disabling it by renaming, if not in use see if you can remove it

- Test test the CPU use of the website BO

- Go to next file....

[Smile]

Also for example I found AdminOrdersController.php apparently it has to do with the Myparcel module. But an old version? Well i don't find this file in the module on github: https://github.com/myparcelnl/prestashop

Can I assume that it is obsolete?

 

<?php
class AdminOrdersController extends AdminOrdersControllerCore
{
    public function sendChangedNotification(Order $order = null)
    {
        return false;
    }
    /*
    * module: myparcel
    * date: 2017-09-05 09:54:47
    * version: 2.0.7
    */
    public function __construct()
    {
        parent::__construct();
        $myParcelFlag = Configuration::get('MYPARCEL_ACTIVE');
        $this->context->smarty->assign(
            array(
                'myParcel'          => $myParcelFlag,
                'prestaShopVersion' => substr(_PS_VERSION_, 0, 3),
            )
        );
        if (true == $myParcelFlag) {
            if ('' == session_id()) {
                session_start();
            }
            $_SESSION['MYPARCEL_VISIBLE_CONSIGNMENTS'] = '';
        }
    }
}

 

[datakick]

30 minutes ago, Smile said:

Also for example I found AdminOrdersController.php apparently it has to do with the Myparcel module. But an old version? Well i don't find this file in the module on github: https://github.com/myparcelnl/prestashop

Can I assume that it is obsolete?

 

Looks like it is indeed obsolete, and you should be able to remove it. These overrides remnants are, unfortunately, common problem with module upgrades. 

Another question is why is there an override for sendChangedNotification method. This method only triggers actionOrderEdited hook. By overriding this method this hook is not executed, which might cause problems with other modules integration.

 

 

[datakick]

Also, you can use Override Check module to quickly find all orphaned overrides. This module is available to install in your backoffice

[Traumflug]

23 hours ago, Smile said:

@wakabayashi We recognized that we have a lot of overrides which might not be needed anymore... But how to get rid of them?

There's a module Override check, which lists all the overrides. With some luck, sorted by the module which installed each override. Find it in the list of modules in back office.

Other than that there's not much choice than to go through all the PHP files in the overrides folder, to find hints on why they're there. One override = one PHP function. One removes an override by deleting the PHP function.

[Smile]

So guys/girls a short update:

I did disabled all overrides from BO -> no effect

I did rename the override folder -> no effect

I did install a clean TB and connected it to my DB. So all files are brand new, and just the default modules ect... -> No effect I can still back a honey cake on the server. I also did run TB cleaner. Does this mean that it might be a DB issue as with a clean installation the same issue arises?

Edited February 5, 2019 by Smile

[Smile]

On the other hand when connecting to the DB using Heidi and requesting 100000 rules from PS_Guest it works perfectly without overload....

 

Good to mention maybe is that recently we switched from ASM back to the normal stock management.....

 

Small update: I did install a clean TB and did do the same test. When opening orders, there are just 6 order... the no CPU problem at all but when opening 5-6 product pages then I also can get the CPU very hot....

Edited February 6, 2019 by Smile

[Smile]

So we might have found the issue. Seems there was corrupt date in the ps_configuration_kpi and ps_configuration_kpi_lang. which caused the KPI's to load every time again.

[Smile]

Is there any news on the html cache in TB? And when it could be working  

 

Or where should I check the progress?

[datakick]

15 minutes ago, Smile said:

Is there any news on the html cache in TB? And when it could be working  

The bug that was causing 500 error code was fixed, so Full Page cache should be usable in the upcoming version.

Note that by default every hooks are non-cached, so when you turn it on, you might even experience some slowdown. To get the benefits of FPC, you will need to turn on caching for hooks that *you believe* should be cached. And this is the hard part -- nobody knows if the hook has some side effects other than rendering the output. If it has side effects, turning caching on will break stuff. So you need to be very careful, and test everything.

[Smile]

Do we know when the next version will be released 😅

[Araz]

.

Edited February 15, 2019 by Araz

[Smile]

Additionally to this DH42.com did fix a PHP setting which I think after all was my own fault. I probably disabled it to bug fix 😉

Quote

Basically the old way cpanel used php was it started the php application with every page load, and when the page loaded the php application on the server would close down. This is very inefficient because you cannot cache to php. Think of it as turning your computer off after everything you do, so a lot of resources goes into starting it back to do something else.

Your server was still using that mode of php. I switched it over to php-fpm, which basically leaves the php application on the server running all the time. That way you do not use resources constantly starting php, at the same time you are able to build up an opcache to further speed things up as well.

Thats about all that was done. I am glad it fixed things for you, it works out well it was something like this and not a bug in thirty bees.

 

Happy it seems fixed!