Jump to content

Site speed jumps from 2 to 10 seconds after 1.6.1 upgrade


Recommended Posts

Hello,

 

so, today I tried upgrading to 1.6.1 with 1-click upgrade. Everything went fine. Cleared my browser cache, logged in again, and first impression was that the BO felt slower.

 

Then I tested the front end, and that one was MUCH slower. Network console in Chrome showed page timings of nearly 10 seconds, for the home page, category page, product pages...

 

Wanting to make sure it's not just a problem on my end, I ran Gtmetrix, Pingdom FPT and Webpagetest - they all confirmed, the website takes longer than 10 seconds to load, with TTFB of over 5-6 seconds.

 

I am on a VPS with lots of CPU and RAM, so it most likely is not due to insufficient hardware. There was no error during upgrade. I even tried using the default bootstrap template, no change.

 

Any advice?

 

Thanks for your help!

 

Dan

Link to comment
Share on other sites

 

Thanks for your reply and input! I saw on your post that the solution you found did turn out to not being a solution after all! :-(

Link to comment
Share on other sites

Who are you hosting with? I'm trying to track down the issue.

 

I have a VPS on Myhosting.

 

Apache 2.2.27

PHP Version 5.4.31

MySQL Version 5.6.23

 

I would suggest having a look at the Smarty Debug console, but they got rid of that in the recent versions of PS 1.6 - setting debug mode to true does nothing now, and if there is another way to call the console and look at the potential problems, I don't know how to do that.

Edited by Mister Denial (see edit history)
Link to comment
Share on other sites

Did you try to install a clean copy of PS v1.6.1 just to see if you have the same issue.  That could help narrow down the problem to your server environment, versus an upgrade issue.

 

Hi Mike,

 

thanks for that suggestion, you brought us one step closer to the solution. I installed a blank and clean PS 1.6.1 version on my VPS, it runs really snappy and fast. Then I clear the cache, and BOOM, super slow!

 

So it probably is a tech requirement issue, but what could it be?

 

Because up to (and including) 1.6.0.14 everything runs smooth, even after clearing cache. So it has to be a change introduced in 1.6.1

Link to comment
Share on other sites

@ bellini13: Regarding the issue, with a clean PS 1.6.1 installation, at first it works super fast, but after clearing cache, super slow. I ran the debug tool, and it shows that all queries begin with "select SQL_no_cache" - I am no DB expert, but to me it looks like the website is recompiling all queries for every visitor, and never uses the cache.

 

 

 

Link to comment
Share on other sites

Looking at the first SQL query from your screen shot, which is from line 755 of the Category class.  That last parameter false controls the query cache

$result = Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS($sql, true, false);

That same line of code from PS v1.6.0.14, line 708 in Category.php.  In .14, they did not pass that parameter and it defaults to true in the function definition

$result = Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS($sql);

Now that query only ran for 6.7ms, which is a very small number.  And all of the 285 queries combined only took 155ms, again a very small number.  So I do not believe this is the problem

 

I also noticed from your first screen shot, that most of the time is spent in the displayHomeTabContent hook (5 seconds). 

 

A couple of questions

1) How do you have smarty compilation configured?  Is it force compile, recompile or never compile?

2) I assume Smarty cache is enabled?

3) What smarty cache type are you using (mysql or file system)?

4) Do you have any other caching enable (not smarty caching) at the bottom of the performance page? memcache, apc, xcache etc...?

Link to comment
Share on other sites

I also noticed from your first screen shot, that most of the time is spent in the displayHomeTabContent hook (5 seconds). 

 

A couple of questions

1) How do you have smarty compilation configured?  Is it force compile, recompile or never compile?

2) I assume Smarty cache is enabled?

3) What smarty cache type are you using (mysql or file system)?

4) Do you have any other caching enable (not smarty caching) at the bottom of the performance page? memcache, apc, xcache etc...?

 

Thanks for your input on this. I also do not really believe it's the DB but rather a caching issue with smarty, but I nevertheless wanted to post this because another user with the same issue was able to solve it by switching to MariaDB.

 

Regarding your questions, I know what you're hinting at. Cache is enabled, and it is set to recompile when something has changed. I have Memcache as well as APC installed on my hosting account, but currently none is enabled.

 

In my 1.6.0.9 installation, the above settings produce a really fast result (2-3 seconds page load). With 1.6.1, it goes fast UNTIL I clear the cache, after that it's broken. I have tried changing the setting to never recompile, I have tried setting MySQL cache or files, no difference. It's like smarty is compiling every page every time it's called.

 

Disabling smarty cache actually speed things up, as pageload then drops from 10+ seconds to "only" 7 seconds or so.

Link to comment
Share on other sites

In my 1.6.0.9 installation, the above settings produce a really fast result (2-3 seconds page load). With 1.6.1, it goes fast UNTIL I clear the cache, after that it's broken. I have tried changing the setting to never recompile, I have tried setting MySQL cache or files, no difference. It's like smarty is compiling every page every time it's called.

 

Can you confirm this statement by reviewing the file system and seeing that he time stamps are changing?

Link to comment
Share on other sites

Have you had any luck with this yet? I've just had the same problem after clearing the cache, and my page load times have gone from 3 seconds to 44 seconds! It's a joke as I'm going to lose a lot of visitors because of the problem. Is there any way to get back to how it was pre cache clearance?

Link to comment
Share on other sites

If you can give me quick instructions on how to do that, I will be happy to oblige. :-)

Smarty compile cache is located under \cache\smarty\

 

There will be many sub folder and files, so if you believe smarty tpl files are being recreated all the time, then review these files and see if their timestamps are changing.  I suspect they are not

  • Like 1
Link to comment
Share on other sites

Smarty compile cache is located under \cache\smarty\

 

There will be many sub folder and files, so if you believe smarty tpl files are being recreated all the time, then review these files and see if their timestamps are changing.  I suspect they are not

 

Silly me, of course, I hadn't understood what you meant! ;-p

 

I am going to check that, right now I can't because my hosting company is also checking the issue, and the clear cache function has been disabled (I get a warning message in the BO) - so I will have to wait a couple of days to try again.

 

@ garyjj127: no solution yet, but do you have a backup you could restore, a recent backup from before clearing the cache?

Link to comment
Share on other sites

My site is now fully back to original speed. Not sure whether this is due to the cache being slowly recompiled or the fact that I switched to MySQL cache and then back to file system.

I don't know whether this helps you but I thought if share anyhow.

Link to comment
Share on other sites

Smarty compile cache is located under \cache\smarty\

 

There will be many sub folder and files, so if you believe smarty tpl files are being recreated all the time, then review these files and see if their timestamps are changing.  I suspect they are not

 

Hi bellini13,

 

another user found a fix to this issue by comparing the Git versions of smarty: https://www.prestashop.com/forums/topic/460156-1610-bug-speeds-drop-drastically-if-you-press-clear-cache-button/page-2

 

By changing a line in ../config/smarty.config.inc.php about SmartyCustom - reverting SmartyCustom back to Smarty (like it was before changes in May), the site speed returns to normal.

 

So whatever Prestashop changed and that prevents Smarty from working on several websites, it's related to SmartyCustom.

Link to comment
Share on other sites

Smarty compile cache is located under \cache\smarty\

 

There will be many sub folder and files, so if you believe smarty tpl files are being recreated all the time, then review these files and see if their timestamps are changing.  I suspect they are not

 

UPDATE: the interim solution above does work, but I still wanted to get to the depth of this issue and did what you suggested. I cleared the cache at 10:48 pm. What I observed is that there are only three files in cache/smarty/cache:

- index.php which has the timestamp of 10:48pm

- last_template_flush which has a timestamp that changes every time I access the website - basically this file changes every time someone accesses the website

- there is only one other file, usually a folder of some module like slider or productcomment, depending on which page I access - as soon as I navigate to a different page, the folder is replaced by something else.

Link to comment
Share on other sites

@ bellini13: Regarding the issue, with a clean PS 1.6.1 installation, at first it works super fast, but after clearing cache, super slow. I ran the debug tool, and it shows that all queries begin with "select SQL_no_cache" - I am no DB expert, but to me it looks like the website is recompiling all queries for every visitor, and never uses the cache.

 

 

 

hi, not related - but how did you test the site speed like in the attached screen shots?

 

thanks

Matan

Link to comment
Share on other sites

hi, not related - but how did you test the site speed like in the attached screen shots?

 

thanks

Matan

 

You can enable debugging by changing "false" in define('_PS_MODE_DEV_', false); to "true" in following file: /config/defines.inc.php

 

Depending on your version, that might not be enough, for example for 1.6.1 I had to change several of the "false" values in the file to "true" before the debugging screen became visible.

 

Please note that when you enable this, the info is available to every visitor on your website, so if you run a live website, best put it into maintenance mode first! ;-)

Link to comment
Share on other sites

I also experienced an increase in site loading time after prestashop 1.6.1.1 update. I was upgrading from version 1.6.0.8 and I had to revert to the initial version, due to the poor performances. Even the solution of changing the smarty config code did not work for me.

  • Like 1
Link to comment
Share on other sites

I also experienced an increase in site loading time after prestashop 1.6.1.1 update. I was upgrading from version 1.6.0.8 and I had to revert to the initial version, due to the poor performances. Even the solution of changing the smarty config code did not work for me.

 

Have you tried this? http://forge.prestashop.com/browse/PSCSX-6601

 

For me, the last fix suggested by Jocelyn did work: https://github.com/PrestaShop/PrestaShop/pull/3836

Link to comment
Share on other sites

SET NAMES 'utf8';

UPDATE `PREFIX_image_shop` ish, `PREFIX_image` i SET ish.id_product = i.id_product WHERE i.id_image=ish.id_image;

REPLACE INTO `PREFIX_tag_count` (id_group, id_tag, id_lang, id_shop, counter)
			SELECT cg.id_group, t.id_tag, t.id_lang, ps.id_shop, COUNT(pt.id_tag) AS times
				FROM `PREFIX_product_tag` pt
				LEFT JOIN `PREFIX_tag` t ON (t.id_tag = pt.id_tag AND t.id_lang = pt.id_lang)
				LEFT JOIN `PREFIX_product` p ON (p.id_product = pt.id_product)
				INNER JOIN `PREFIX_product_shop` product_shop
					ON (product_shop.id_product = p.id_product)
				JOIN (SELECT DISTINCT id_group FROM `PREFIX_category_group`) cg
				JOIN (SELECT DISTINCT id_shop FROM `PREFIX_shop`) ps
				WHERE product_shop.`active` = 1
				AND EXISTS(SELECT 1 FROM `PREFIX_category_product` cp
								LEFT JOIN `PREFIX_category_group` cgo ON (cp.`id_category` = cgo.`id_category`)
								WHERE cgo.`id_group` = cg.id_group AND p.`id_product` = cp.`id_product`)
				AND product_shop.id_shop = ps.id_shop
				GROUP BY pt.id_tag, pt.id_lang, cg.id_group, ps.id_shop;
REPLACE INTO `PREFIX_tag_count` (id_group, id_tag, id_lang, id_shop, counter)
			SELECT 0, t.id_tag, t.id_lang, ps.id_shop, COUNT(pt.id_tag) AS times
				FROM `PREFIX_product_tag` pt
				LEFT JOIN `PREFIX_tag` t ON (t.id_tag = pt.id_tag AND t.id_lang = pt.id_lang)
				LEFT JOIN `PREFIX_product` p ON (p.id_product = pt.id_product)
				INNER JOIN `PREFIX_product_shop` product_shop
					ON (product_shop.id_product = p.id_product)
				JOIN (SELECT DISTINCT id_shop FROM `PREFIX_shop`) ps
				WHERE product_shop.`active` = 1
				AND product_shop.id_shop = ps.id_shop
				GROUP BY pt.id_tag, pt.id_lang, ps.id_shop;

TRUNCATE TABLE `PREFIX_smarty_last_flush`;

I have the same speed issues as all of you. I have updated my SmartyCustom.php from this merge with the new prestashop 1.6.1.2  Here is the patch below on git...

 

https://github.com/PrestaShop/PrestaShop/pull/3836

 

However when I run the .sql above from the patch over on the git repository. I get this error below in phpMyAdmin.

Error

SQL query:



UPDATE `PREFIX_image_shop` ish, `PREFIX_image` i SET ish.id_product = i.id_product WHERE i.id_image=ish.id_image;

MySQL said: Documentation
#1146 - Table 'xxxxx_data.PREFIX_image_shop' doesn't exist

This is what it shows in my table.

	1	id_image	int(11)		UNSIGNED	No 	None		Change Change	Drop Drop	

    Primary Primary
    Unique Unique
    Index Index
    Spatial Spatial
    Fulltext Fulltext
    Distinct values Distinct values

	2	id_shop	int(11)		UNSIGNED	No 	None		Change Change	Drop Drop	

    Primary Primary
    Unique Unique
    Index Index
    Spatial Spatial
    Fulltext Fulltext
    Distinct values Distinct values

	3	cover	tinyint(1)		UNSIGNED	Yes 	NULL		Change Change	Drop Drop	

    Primary Primary
    Unique Unique
    Index Index
    Spatial Spatial
    Fulltext Fulltext
    Distinct values Distinct values

	4	id_product	int(10)		UNSIGNED	No 	None		Change Change	Drop Drop

How would I get around this error? I have only found one issue related in google search but it is from prestashop 1.5.0.18 I am now on 1.6.1.1 So if i use this older patch to Run SQL query/queries on database I might make matter worse. Anyway here is the link to that issue.

 

https://translate.google.com/translate?hl=en&sl=fr&u=https://www.prestashop.com/forums/topic/187805-resolu-bug-categoryphp/&prev=search

 

I would like to thank all you guys in advance for any help at all. Also and of course the patch by  jocel1

Link to comment
Share on other sites

SET NAMES 'utf8';

UPDATE `ps_image_shop` ish, `ps_image` i SET ish.id_product = i.id_product WHERE i.id_image=ish.id_image;

REPLACE INTO `ps_tag_count` (id_group, id_tag, id_lang, id_shop, counter)
			SELECT cg.id_group, t.id_tag, t.id_lang, ps.id_shop, COUNT(pt.id_tag) AS times
				FROM `ps_product_tag` pt
				LEFT JOIN `ps_tag` t ON (t.id_tag = pt.id_tag AND t.id_lang = pt.id_lang)
				LEFT JOIN `ps_product` p ON (p.id_product = pt.id_product)
				INNER JOIN `ps_product_shop` product_shop
					ON (product_shop.id_product = p.id_product)
				JOIN (SELECT DISTINCT id_group FROM `ps_category_group`) cg
				JOIN (SELECT DISTINCT id_shop FROM `ps_shop`) ps
				WHERE product_shop.`active` = 1
				AND EXISTS(SELECT 1 FROM `ps_category_product` cp
								LEFT JOIN `ps_category_group` cgo ON (cp.`id_category` = cgo.`id_category`)
								WHERE cgo.`id_group` = cg.id_group AND p.`id_product` = cp.`id_product`)
				AND product_shop.id_shop = ps.id_shop
				GROUP BY pt.id_tag, pt.id_lang, cg.id_group, ps.id_shop;
REPLACE INTO `ps_tag_count` (id_group, id_tag, id_lang, id_shop, counter)
			SELECT 0, t.id_tag, t.id_lang, ps.id_shop, COUNT(pt.id_tag) AS times
				FROM `ps_product_tag` pt
				LEFT JOIN `ps_tag` t ON (t.id_tag = pt.id_tag AND t.id_lang = pt.id_lang)
				LEFT JOIN `ps_product` p ON (p.id_product = pt.id_product)
				INNER JOIN `ps_product_shop` product_shop
					ON (product_shop.id_product = p.id_product)
				JOIN (SELECT DISTINCT id_shop FROM `ps_shop`) ps
				WHERE product_shop.`active` = 1
				AND product_shop.id_shop = ps.id_shop
				GROUP BY pt.id_tag, pt.id_lang, ps.id_shop;

TRUNCATE TABLE `ps_smarty_last_flush`;

Ok so I ran this once and here are the results...

# MySQL returned an empty result set (i.e. zero rows).

------

SET NAMES 'utf8';# MySQL returned an empty result set (i.e. zero rows).


UPDATE `ps_image_shop` ish, `ps_image` i SET ish.id_product = i.id_product WHERE i.id_image=ish.id_image;# MySQL returned an empty result set (i.e. zero rows).


REPLACE INTO `ps_tag_count` (id_group, id_tag, id_lang, id_shop, counter)
SELECT cg.id_group, t.id_tag, t.id_lang, ps.id_shop, COUNT(pt.id_tag) AS times
FROM `ps_product_tag` pt
LEFT JOIN `ps_tag` t ON (t.id_tag = pt.id_tag AND t.id_lang = pt.id_lang)
LEFT JOIN `ps_product` p ON (p.id_product = pt.id_product)
INNER JOIN `ps_product_shop` product_shop
ON (product_shop.id_product = p.id_product)
JOIN (SELECT DISTINCT id_group FROM `ps_category_group`) cg
JOIN (SELECT DISTINCT id_shop FROM `ps_shop`) ps
WHERE product_shop.`active` = 1
AND EXISTS(SELECT 1 FROM `ps_category_product` cp
LEFT JOIN `ps_category_group` cgo ON (cp.`id_category` = cgo.`id_category`)
WHERE cgo.`id_group` = cg.id[...]

I still have speed issues so I am not so sure it worked. There are some posts over on stacked that say probally not.

Link to comment
Share on other sites

Hi I'm not sure if it may help somebody.... but in my case after updating from Ps 1.6.0.9 to 1.6.1.1 I have experienced random terrible slow performance on both backoffice and front. During a few minutes the site hangs and then after some minutes it started working again... and then back to slow performance again...

 

So after reading some posts from the forum I realized that it seems that the problem could be related with cache smarty... So I just deleted all the cache/smarty/cache folders and files except index.php.... I did it by ftp ...

 

while the ftp program was deleting files from cache then site suddenly starts working and it has never crashed again... In fact now it works faster than before when it was PS 1.6.0.9

Edited by Antakarana (see edit history)
Link to comment
Share on other sites

  • 2 months later...

Hi, I am using prestashop 1.5.6 english version, I have deleted 5 files from my httpdocs folded "product.php, productdownload.php, productsale.php, product supplier.php and configuration.php"


After deleting these file my site was not working then i paste these file again on same location. 


But after that my site is working too slow. taking 10+ sec to load. 


please help me to solve the issue. please check my site http://slmobileprice.com


 


Thanks,


Somit


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...