[1.6.1.0] Bug - Speeds drop drastically if you press Clear Cache button

[736Online]

I have found what I believe to be a pretty major bug in the latest software. And I have been able to duplicate this same issue on both a shared and VPS account.

 

If you go into performance and click the Clear Cache button your website will slow to a crawl of 6-12 seconds with no other changes being made. I have tested this on a fresh install as well as on a test version stocked with stock on default themes and customs...all with the same result. I've also tried several combinations of settings as well as reuploading the cache folder in case the button broke some sort of write permissions and that failed as well.

 

Has anyone else run into a problem with your site suddenly slowing down? This could be your cause as well!

[736Online]

-Was not the answer to fix the issue

Edited August 18, 2015 by 736Online (see edit history)

[736Online]

This doesn't seem to be a long term fix, the issue keeps popping back up and never gets back down to the fast speeds. This error is still present on both VPS and shared hosting accounts.

[Mister Denial]

I also have experienced this cache-speed issue. I have a powerful VPS hosting, and my fast 2.5 second shop jumped up to 10 seconds! This happened after upgrading from 1.6.0.9 to 1.6.1 using 1-click.

[736Online]

DId you run updates on your modules after the install? I'm still trying to track down the real root cause.

[Mister Denial]

DId you run updates on your modules after the install? I'm still trying to track down the real root cause.

 

No, no module updates. I simply did the 1-click upgrade. After the successful upgrade, I cleared the browser cache to refresh the BO and do some testing. I noticed it was very slow. I then cleared the browser cache, no change, painfully slow.

 

I disabled all non-native modules during the upgrade, and did not enable any after the upgrade. So whatever causes the problem was caused during the upgrade. I also tested on IE, FF and Chrome. And ran tests on Gtmetrix, Pingdom and Webpagetest. The problem on all three was the time to first byte, which was usually in the 8-10 seconds range. After that, the rest of the waterfall was quite fast.

[Mister Denial]

I did some more testing after my rollback. When I upgrade the store, before clearing the cache in the BO it runs smooth. As soon as I clear the cache, it gets A LOT slower - like 10 seconds added.

[yo7hli]

I can confirm this behaviour. as soon as you clear smarty cache both the BO and FO slows down, in my case from ~200ms TTFB to arround 2 seconds.

Seems to break the opcode caching somehow, cant figure out how and why.

 

[736Online]

What hosting service are you two using? 

[Mister Denial]

I can confirm this behaviour. as soon as you clear smarty cache both the BO and FO slows down, in my case from ~200ms TTFB to arround 2 seconds.

Seems to break the opcode caching somehow, cant figure out how and why.

 

In my case it's even worse, it drops from 1-2 seconds to 10-15 seconds. And it's always the TTFB that is increased, like it's taking forever to compile and render the page code.

 

I have tried enabling and disabling various performance settings, no noticeable effect, except this: if I disable cache altogether, the site gets faster. It "only" then takes 7-10 seconds to load.

 

I am on a VPS at Myhosting with following configuration:

Apache 2.2.27

PHP Version 5.4.31

MySQL Version 5.6.23

[yo7hli]

Also on a decent VPS running debian 8 with Apache 2.4, PHP 5.6.

Some other details: First time after finding out this bug i switched to disk caching and it started working almost as before, ~300 ms TTFB.

Cleaned cache again, prestashop slowed down, now every caching method seems to have no effect.

Then I switched to FPM/fastcgi, disabled caching in prestashop, enabled zend opcache, things started working great, of course, till I cleaned the cache again.

Now nothing works no matter what I do.

 

I also noticed that even tho opcache (or any other caching engine for that matter) caches both the code and the vars, all the subsequent requests to the cache are missed.

 

Its time to downgrade I think.

[Mister Denial]

Its time to downgrade I think.

 

Bellini suggested trying a clean installation on my server to see if the problem persists - and it does! A clean 1.6.1 installation, works super fast, both BO and FO - until I clear the cache. After that, it drops from 1.5 seconds to 10 seconds +.

 

So the problem is not caused by the upgrade itself, it is that the new PS 1.6.1 version seems to have different configuration requirements, and something is conflicting with smarty cache.

[736Online]

I'm starting to think that it's a mysql issue. I erased everything on my server and did a fresh install using MariaDB instead and now I only have the TTFB increase on the first request, all subsequent request are normal speeds. 

[Mister Denial]

I'm starting to think that it's a mysql issue. I erased everything on my server and did a fresh install using MariaDB instead and now I only have the TTFB increase on the first request, all subsequent request are normal speeds. 

 

The whole time I only had the TTFB issue on the first request, all others were fast. In my case the problem is that the first request takes 8-10 seconds to compile.

 

Because this issue happens also on a clean installation, as soon as cache is cleared in BO, I think it's a smarty cache issue, caused by some server requirement that changed in 1.6.1 and that was different in 1.6.0.9

[736Online]

To be clear my issue was my website was fast before clicking to clear the cache and then request would increase to up to 10 seconds on TTFB going from page to page, but the other parts of the site like loading images and everything else would be fast.

 

TTFB was always slow no matter what would happen.

 

Now I've switched to and tested on MariaDB and only the very first visit from a single visitor (I'm guessing to rebuild the cache profile or something?..) has a slow TTFB and all other subsequent visits are fast with TTFB under 1 second.

[Mister Denial]

 

Now I've switched to and tested on MariaDB and only the very first visit from a single visitor (I'm guessing to rebuild the cache profile or something?..) has a slow TTFB and all other subsequent visits are fast with TTFB under 1 second.

 

Yes, that sounds like cache is now working the way it should. It's logic that the very first visitor will get a slow TTFB, when the page initially compiles, and then everything goes fast.

 

What happens when you clear cache again? Same thing, first visitor slow and then fast?

 

Does anyone from Prestashop on this forum have any input on this? Because I would assume that most people use the default SQL settings, and don't seem to have issues.

[736Online]

Same thing, I can clear the cache over and over with no issues except the very first visit. I noticed that on their blog post about the launch of the new version that they used MariaDB so I gave it a try and it worked out so far.

 

BUT if I turn on CCC it doubles the TTFB (still staying under 1.5seconds)

[Mister Denial]

That seems normal behavior to me, that the first visitor gets a slow reaction.

 

I didn't know about MariaDB and that Prestashop is now using it, but I am going to check if my hosting company can test it, and if that solves my problem, I will make the change too. Did you need to conver the DB or anything? Because right now my tables are all Inno DB, with a few MyISAM tables from older modules (my shop was a 1.4 installation).

 

Do you know if MariaDB also works fine with 1.6.0.9 by any chance?

 

Also, what are the differences between MariaDB and Inno?

[736Online]

I was able to do an "install in place" and everything just worked. I didn't need to adjust phpmyadmin or anything. I did test with 1.6.0.9 and it worked fine. 

 

I think another issue could be the fact that a lot of host have the databases separate from the server itself and that adds to the slowness. I installed the database on the server itself and there's no connection delays.

[Mister Denial]

What do you mean by install in place? I am unsure how I would go about upgrading my existing Inno DB tables to MariaDB.

 

Regarding the SQL server being separate, that could cost a few milliseconds indeed, but for example on my VPS in 1.6.0.9, the TTFB is usually only one second, and the whole page load time less than 3. With the Page Cache module, it drops to 300ms TTFB and a page load of less than 2 seconds.

[Mister Denial]

UPDATE: I just ran the debug tool on my slow PS 1.6.1 cleared cache test site, and noticed that all SQL queries start with "SELECT SQL_NO_CACHE" - desptie cache being enabled. Could that be part of the error?

[parsifal]

Isn't it possible that your finding about the queries is something normal when using the default Performance Options (Filesystem-based cache, instead of MySQL-based)?

 

 

Unless the queries are different when compared to those in a fresh/before-clearing-the-cache installation...

Edited August 18, 2015 by parsifal (see edit history)

[Mister Denial]

Isn't it possible that your finding about the queries is something normal when using the default Performance Options (Filesystem-based cache, instead of MySQL-based)?

 

That is very well possible, I am no SQL expert. Just thought I'd point it out as possible cause for the slow queries. Something was changed between 1.6.0.14 and the latest 1.6.1, and that causes the cache clearing function in the BO to completely screw up the performance of the website. It looks like PS is compiling every page on every call, instead of caching them. Like smarty cache is not working at all.

 

[garyjj127]

I had the exact same problem with clearing the cache. It reduced the load speed to 44 seconds for my home page! I don't know whether this is an exact fix, but I went into the back office and reset all the performance parameters (changed the CCC settings to "no"). I then changed cache from "file system" to MySql, then back again. I now have load speeds back to 6 seconds (slightly slower than before, but better than 44 seconds!).

 

Of course, it could be that the cache recompiling that caused the initial slow speed in the first place?

[pipo1000]

Hi,

 

I have the same. I have found that the ../cache/smarty directory does not fill with files at all. Only the latest modules used is being written in de smarty cache. So it keeps compiling the modules over and over again. It looks like it is clearing out the smarty directory after every compile!!!!

 

HELP! Come on Prestashop, help us out!

 

[root@www smarty]# du -ak
4       ./index.php
8       ./compile/b7/d2/27/b7d227eb085f2641c9d7634cc0af9e50090feea9.file.javascript.tpl.php
12      ./compile/b7/d2/27
16      ./compile/b7/d2
20      ./compile/b7
4       ./compile/index.php
72      ./compile
4       ./cache/index.php
4       ./cache/blockcmsinfo/1/2/6/1/13/74/54/a9/7454a9ce2cbc350de710cee1329f5a70730a3073.blockcmsinfo.tpl.php
8       ./cache/blockcmsinfo/1/2/6/1/13/74/54/a9
12      ./cache/blockcmsinfo/1/2/6/1/13/74/54
16      ./cache/blockcmsinfo/1/2/6/1/13/74
20      ./cache/blockcmsinfo/1/2/6/1/13
24      ./cache/blockcmsinfo/1/2/6/1
28      ./cache/blockcmsinfo/1/2/6
32      ./cache/blockcmsinfo/1/2
36      ./cache/blockcmsinfo/1
40      ./cache/blockcmsinfo
212     ./cache
292     .
 

[pipo1000]

After some digging in GIT and looking at the smarty code I have found when I change;

 

../config/smarty.config.inc.php

 

and change SmartyCustom into Smarty suddenly I get cache files again and all feels a lot faster;

 

global $smarty;
$smarty = new Smarty();
$smarty->setCompileDir(_PS_CACHE_DIR_.'smarty/compile');
$smarty->setCacheDir(_PS_CACHE_DIR_.'smarty/cache');

 

Hope this helps!

[Mister Denial]

After some digging in GIT and looking at the smarty code I have found when I change;

 

../config/smarty.config.inc.php

 

and change SmartyCustom into Smarty suddenly I get cache files again and all feels a lot faster;

 

global $smarty;

$smarty = new Smarty();

$smarty->setCompileDir(_PS_CACHE_DIR_.'smarty/compile');

$smarty->setCacheDir(_PS_CACHE_DIR_.'smarty/cache');

 

Hope this helps!

 

Thanks for that advice, I am going to try that and see if that works for my problem. I am also currently checking with my hosting company and on Github, I'll post my findings here.

[webbwayne]

Thanks for that advice, I am going to try that and see if that works for my problem. I am also currently checking with my hosting company and on Github, I'll post my findings here.

Did this work for your site? I'm running into the same issues. Once I clear cache my website slows down. It all started when I upgraded to 1.6.1.

 

 

Anyone find a solution?

[pipo1000]

There is a Forge ticket for this problem;

 

http://forge.prestashop.com/browse/PSCSX-6607

 

please vote for this issue!

[webbwayne]

After some digging in GIT and looking at the smarty code I have found when I change;

 

../config/smarty.config.inc.php

 

and change SmartyCustom into Smarty suddenly I get cache files again and all feels a lot faster;

 

global $smarty;

$smarty = new Smarty();

$smarty->setCompileDir(_PS_CACHE_DIR_.'smarty/compile');

$smarty->setCacheDir(_PS_CACHE_DIR_.'smarty/cache');

 

Hope this helps!

 

This fix worked for me. Hopefully prestashop comes out with an official fix.

[Mister Denial]

It worked for me too. Speed went from 10 seconds to 2.5 seconds.

 

Thanks a lot pipo!

[adm666]

THanks a lot, guys, thanx pipo!

 

Definetely, reverting to Smarty() form SmartyCustom() made something for speed-upping. Not much, but nevertheless.

 

Still there problem with (WTF) long spinning buttons like "save".

[garyjj127]

THanks a lot, guys, thanx pipo!

 

Definetely, reverting to Smarty() form SmartyCustom() made something for speed-upping. Not much, but nevertheless.

 

Still there problem with (WTF) long spinning buttons like "save".

The spinning save button is infuriating!! I have noticed that even though it takes ages for the spinning button to respond, the database updates quickly when saving. I ran two versions of the same page in different browser windows, and made a change to one and hit save. While waiting (10 seconds!) for the spinning button to save, I refreshed the page in the other window, and the changes had been made. So it seems that this may be due to the software rather than a slow DB connection, although admittedly I have no idea where the problem lies.

 

Seems to me that most of the slow speed issues are to do with database requests/responses from PS, rather than slow server speeds.

[buco]

Hi!

Two questions...

 

- You have problems with the modules tab? When i click in "modules" the time to load is very high (initContent is the problem but i dont know how to correct it)

 

- When you open a tab in other window your time to load is high or load normally?

 

 

I  changed this line and the time to load change, but not the same as 1.6.0.X

 

Thanks!!!

[Mister Denial]

Two questions...

 

- You have problems with the modules tab? When i click in "modules" the time to load is very high (initContent is the problem but i dont know how to correct it)

 

- When you open a tab in other window your time to load is high or load normally?

 

In my case, the slow module tab has always been a problem, even before 1.6.1 - sometimes it only takes 3-4 seconds to load, sometimes 10-20 - I suspect that this happens because the module page checks for new module versions on the Prestashop server.

 

Regarding the slow save icon that keeps spinning, same thing, it also did happen on 1.6.0.9 and prior versions, in my case. But it's true what garryjj127 said, even if the button is still spinning, if you open the same page in another window, the change has been made.

[garyjj127]

In my case, the slow module tab has always been a problem, even before 1.6.1 - sometimes it only takes 3-4 seconds to load, sometimes 10-20 - I suspect that this happens because the module page checks for new module versions on the Prestashop server.

 

Regarding the slow save icon that keeps spinning, same thing, it also did happen on 1.6.0.9 and prior versions, in my case. But it's true what garryjj127 said, even if the button is still spinning, if you open the same page in another window, the change has been made.

I don't have any issues with the module pages or any other pages in the back office, apart from the "Configuration Information" page. Occasionally they take a while to load, but it's usually first thing in the morning, and load pretty quick after that. I guess it's the browser looking to see if the page has changed compared to the cached version.

[codochi]

In my case, the slow module tab has always been a problem, even before 1.6.1 - sometimes it only takes 3-4 seconds to load, sometimes 10-20 - I suspect that this happens because the module page checks for new module versions on the Prestashop server.

 

Regarding the slow save icon that keeps spinning, same thing, it also did happen on 1.6.0.9 and prior versions, in my case. But it's true what garryjj127 said, even if the button is still spinning, if you open the same page in another window, the change has been made.

Following this tip: http://nemops.com/faster-prestashop-back-office-modules-themes-ads/#.Vd9s0PntlOZ

[the.rampage.rado]

After some digging in GIT and looking at the smarty code I have found when I change;

 

../config/smarty.config.inc.php

 

and change SmartyCustom into Smarty suddenly I get cache files again and all feels a lot faster;

 

global $smarty;

$smarty = new Smarty();

$smarty->setCompileDir(_PS_CACHE_DIR_.'smarty/compile');

$smarty->setCacheDir(_PS_CACHE_DIR_.'smarty/cache');

 

Hope this helps!

This worked for me too!

[buco]

Hi again!!!
Finally i think that i solve the problem with BO speed.

 

I change this line on smarty.config.inc.php, but also i clean modules because many of them causes low speed on backoffice.

Mister Denial, if you on local installation rename modules folder and try to move on backoffice, the speed will be faster, after copy on five on five modules from rename folder to modules folder and try the speed.

 

It´s o basically solution but i think that works :-)

Thanks!!!

[dcp]

can you introduce the Page Cache module that you used? 

[Mister Denial]

can you introduce the Page Cache module that you used? 

 

I am using this: http://addons.prestashop.com/en/seo-prestashop-modules/7939-page-cache.html - it works really well, it reduces my TTFB from about 1.3 seconds to approximately 0.3 seconds. And I already have a highly optimized installation. I believe that on a slower server, you will even save more time, especially if you have a slow Time To First Byte.

 

@ UGO: that's a good idea. Maybe we should make a list of slow modules, or a top list of modules that are causing problems on our individual installations, where users can vote on which module is causing them problems.

 

In your case, which modules caused the most slowness?

 

Also, on my current test installation, I am using the original Custom Smarty, there have been Github fixes issued that work. I think when 1.6.1.12 is issued, it should fix the problem.

[garyjj127]

Do you mean this module? http://addons.prestashop.com/en/front-office-features-prestashop-modules/16692-page-cache-faster-prestashop.html

 

The link you provided didn't seem to work. Anyhow, the module seems to make a huge amount of difference! I wonder how it reacts to changes on the site, in terms of updating templates etc..?

[Crezzur.com]

Solution for your problem (will cut wait time to 5 sec max!)

 

https://www.prestashop.com/forums/topic/483603-solution-slow-backoffice-long-wait-for-saving-icons-read-this-now/