Slow Page Load TTFB 8000ms I Need Help

[bald43]

I'm working on this website www.bizbuyz.net and I need help. My hosting company worked with me getting the time to first byte down from 28 seconds to 8, vast improvement but it's still to slow. I've hired a few so called "experts" off O'Desk who couldn't seem to figure out why the TTFB is taking so long. If anyone had this problem, in the past and knows how to fix it please advise.

 

All the usual performance setting are in place, Gzip, Memcached, Apache Keep Alive, Force Compile - No, CCC, and the Connections tables have been flushed.

 

There are 4 other sites running on this server 2 WordPress, 2 Prestashop and they don't have this problem, so I don't think it's a server issue. Here is a link to the latest test results http://www.webpagetest.org/result/111127_MF_2AFWV/1/details/

 

Need Help !!!!!!!!!!!!!!!!

 

Thanks

 

 

 

Keith

[bald43]

Problem Fixed

[Jack Gill]

I have the same issuses with my Prestashop www.extremepcs.co.uk Time To First Byte 15 - 30 seconds, please confirm how the problem was fixed! - I have disabled all modules, but the site is still slow.

[otrain77]

Hi,

 

I am experiencing a very slow site as well (26 seconds to load!). What did you end up doing to fix your site speed?

[DIT]

Problem Fixed

 

A forum is helpfull if users would share solutions, not only asking for them. Please explain how did you solve, tks

[Online Office USA]

 

A forum is helpfull if users would share solutions, not only asking for them. Please explain how did you solve, tks

 

Try this post: http://www.prestashop.com/forums/topic/103628-prestashop-v14-performance-settings/page__p__733212?do=findComment&comment=733212

[AITOC]

Hi everyone, please take a look at http://addons.prestashop.com/en/administration-tools/4633-Performance-Booster.html

This module fully caches the pages and, without initializing PrestaShop, provides your visitors with ready output that takes significantly less time to load.

[guest*]

It's a shame that Prestashop 1.4.6.2. and 1.4.7. needs a paid module to have the speed I had BEFORE upgrading my 1.4.4.0 Version to 1.4.6.2. Before upgrading I had a parse of 2 seconds now I have a parse of 5-17 seconds, although I used all optimization possibilities... CCC, clearing DB-Tables, etc...

 

I've never had problems with first byte time, after the upgrade it is about 12 seconds !!!

[phrasespot]

It's a shame that Prestashop 1.4.6.2. and 1.4.7. needs a paid module to have the speed I had BEFORE upgrading my 1.4.4.0 Version to 1.4.6.2. Before upgrading I had a parse of 2 seconds now I have a parse of 5-17 seconds, although I used all optimization possibilities... CCC, clearing DB-Tables, etc...

 

I've never had problems with first byte time, after the upgrade it is about 12 seconds !!!

 

True, true.....

 

Working on 1.3. occasionally, it feels much snappier, BO and FO.

 

In 1.4, for any sufficiently large number of products, say 5000 or more, I could not get 1.3. like speeds even after using all tricks in the book with server settings, hand optimizing many of the SQL queries, and even removing the functionality not required. If the shop has 50K products...forget about it.

 

I am now afraid to recommend PS to any client unless they have below 5000 products and can host it on a dedicated server, because otherwise one always ends up with a non-happy client.

[guest*]

By searching on GG I found some optimization snippets for PS. I implemented them and now my shop works very fast again. I also discarted "modal module before home-site", this was causing a first byte loading problem of about 5-7 sec..

So before optimization: loading of about 7-17 sec.

 

My catalog: 19.000 products, but only 8.000 only (rest parked for revision on description, prices, features, etc... They go online step-by-step)

 

After optimization:

Opening home, categories and undercategories: 2-3 sec.

Opening products: here I got only 2 seconds less, so parse about 3-4 sec.. I think the problem must be in the architecture of the shop. Products are linked to more than one category (3-4). I'm sure the problem is on too many DB requests at the same time.

 

What I did to optimize:

 

1) Preferences -> performance

 

force compile = no

Cache = yes

----------------------------------------------------------------------

 

Smart cache for CSS = CCC

Smart cache for JS = CCC

reduction HTML-code = reduction HTML after smarty compilation

compression of JS in HTML-Code = compression of JS on HTML-code after smarty compilation

Max compilation of HTML (risk) = max. compression of HTML

------------------------------------------------------------------------

Media Server - nothing changed = empty

 

------------------------------------------------------------------------

 

Mcrypt = Rijndael

------------------------------------------------------------------------

 

As fast-cgi servers do not have any other and do not need memcache this is disabled.

 

-------------------------------------------------------------------------

 

2 ) I'm now also using the optimization-possibility on .htaccess

 

tools -> generator -> htaccess

 

Optimization = yes

Apache multiviews = yes

 

HERE YOU MUST TAKE CARE THAT THE BLOCK GENERATED IS ON THE END OF .htaccess. OTHERWISE IT WILL BRAKE BO ON CUSTOMERS/ADDRESSES/OPEN CARTS.

 

This block should be the last block on your .htaccess, if not re-arrange:

 

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType image/x-icon "access plus 1 year"
</IfModule>
FileETag INode MTime Size
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>

 

 

For me the best Versions 1.4. were:

 

1.4.4.0 and 1.4.5.1

 

they are working without any speed problems. If you don't need to upgrade, so don't do it...

[guest*]

I gave up. Besides the server has peaks (provider problem), the shop is slow... I downgraded after 3 months 1.4.6.2 to 1.4.5.1 (exporting/importing, migrating manually each row/ps_table, because a 1:1 copy of DB will also take the slow queries with it - wrong set indexes ??)

 

1.4.5.1 is now running with a parse of 2-3 seconds instead 5-12 with 1.4.6.2. I tried also all other versions after 1.4.6.2 they all have the same speed problem (also on an empty shop with 10 categories and only one product !! TTFB is 2x, 3x more as for 1.4.5.1).

[rkinfo]

I gave up. Besides the server has peaks (provider problem), the shop is slow... I downgraded after 3 months 1.4.6.2 to 1.4.5.1 (exporting/importing, migrating manually each row/ps_table, because a 1:1 copy of DB will also take the slow queries with it - wrong set indexes ??)

 

1.4.5.1 is now running with a parse of 2-3 seconds instead 5-12 with 1.4.6.2. I tried also all other versions after 1.4.6.2 they all have the same speed problem (also on an empty shop with 10 categories and only one product !! TTFB is 2x, 3x more as for 1.4.5.1).

 

demo-store.prestashop.com/en/

 

http://www.webpagete...first_byte_time

First Byte Time (back-end processing): 60/100

814 ms First Byte Time

423 ms Target First Byte Time

 

A featured store from the prestashop showcase

First Byte Time (back-end processing): 50/100

915 ms First Byte Time

420 ms Target First Byte Time

 

Another featured store from the prestashop showcase

First Byte Time (back-end processing): 6/100

1368 ms First Byte Time

432 ms Target First Byte Time

 

You might want to put the featured shops before you look at yours for now

[guest*]

@rkinfo

 

I really don't know what you want to say to me. You are linkig to webpagetest to a demoshop with only some products and some categories. I made a comparation between PS default versions, it says: 1.4.4.0, 1.4.5.1, 1.4.6.2 and 1.4.7.3. All the four with presta standard theme, presta standard demo categories and products. The performance between 1.4.4.0. and 1.4.5.1 is better that the performance for the version 1.4.6.2 and 1.4..7.3. this compared on the same server and all the same. till 2.000 products you don't will notice any difference between the versions, but all shops over this wil. notice the extreme fall down of the parse.

 

For me as seller it is not important what a demoshop can or how fast it is. For me it is important to have the same performance on a live shop, and this is not what happens when you use a version 1.4.6.2 onwards. The best versions, with best performance are 1.4.4.0 and 1.4.5.1. So for big shops recommendable, also without need of extra performance settings like the one I named in here before. I'm speaking on facts, aside from that I'm not selling PS-Shops but my own products. And I need a reliable, fast software for this.

[phrasespot]

The best versions, with best performance are 1.4.4.0

FWIW I concur with this. Given the same hardware and hosting specs, 5K products, I have not been able to reproduce the load performance on any other version.

Edited May 16, 2012 by phrasespot (see edit history)

[LeGastronome]

Hi,

 

I have the same problem as your.

 

I have 2 same shop on my server : 1.3.3 and very last 1.4.8.2 (I would like to upgrade soon if I found the issue about loading page)

> Server is a VPS dedicated.

> 1.3.3 run as flash gordon. 700 products

 

The Time to first byte TTFB on 1.3 was very short : 400 to 900 ms

 

On 1.4 TTFB it's another story : from 1,5 to 4s !!! 8sec with memcached on

 

> Cache Yes

> Force compile No

> 3 sub domains for CDN

> MCrypt

> CCC "ON"

> Memcached (off)

> GZIP

> Expires 1 week

> All Statistics off, All external modules off

 

Every one say that is my host config which is bad ?

 

Some nice catch from your side ? I would like to try an install on 1.4.4.0 ??? How do you think ?

[LeGastronome]

No improvement for me when using 1.4.5 or 1.4.4

 

Just to let you know.... I will trace php with a profiler this evening

[guest*]

See my veridict here: http://forge.prestas...wse/PSCFI-5154. The manual downgrade to 1.4.5.1 solved the problem. All versions under 1.4.5.1. including have no speed issues, but all over this have. Same Server, same settings, all same to can compare equal with equal.

 

Shop of 9.000 products. 19.000 on database but not acutally all activated. Other 10.000 waiting for multishop feature to use them.

[Mister Denial]

@ CD2500 - any recommendations on how to downgrade? I am seriously considering doing this too! So if you have any recommendations on what to pay attention to, or how to best do it, I would appreciate!

[guest*]

No, sorry. you must migrate each table-data of your DB to an clean, empty one. Don't do it by copy to, because you are also copying than the index and SQL-queries. You should pay attention to only migrate the data of each table.

[bellini13]

i had reported in a similar post. I saw a vast improvement by reviewing all the modules that are disabled, and uninstalling them and removing their hooks in the position page. The core code still executes the hooks even though they are disabled.

 

In addition, there are a handful of tables that do not have proper indexes. There are queries that are using columns in where clauses, and those columns need indexes to perform efficiently.

[Mister Denial]

Thanks for the input, that was helpful, because now I know what to expect in order to downgrade. And, considering my limited SQL knowledge, this seems like a risky venture, so I'll keep my fingers of it, or hire a pro to do it for me.

[clayton29657]

Guys I really must know are there any bug issues right now or security issues if I do not upgrade my shop? I am currently using 1.4.5 and the speed I have is awesome with over 15,000 products on their. It's not live yet because still designing a template for it but I need to know what your thoughts are.

 

1.4.5 upgrade to 1.4.8?

[Mister Denial]

I was kinda wondering the same thing as Clayton too, being on 1.4.6.2.

[Aswin C.]

are you all using category block ?

if yes, this is your problem.

solution:

http://www.prestashop.com/forums/topic/176681-slow-blockcategoriestpl/

[clayton29657]

Well Mister Denial,

 

let's see what they say if there's no issues with bugs to fix I will not upgrade my shop at all. I am not upgrading my shop to have to buy modules for speed that's for sure

[clayton29657]

Aswinc why does it not cause a problem in 1.4.5 if this is an issue?

[Mister Denial]

Hi AswinC, do you mean if we use the left column block to display categories?

 

If yes, I have about 20 categories, and one language & currency - do you feel this calls for the solution you posted in the thread you linked?

 

Thanks for your input!

[clayton29657]

I have over around 80 categories with one language but I do not have this problem now Answinc. So if you may please explain why it would do this on a upgrade?

Edited July 20, 2012 by clayton29657 (see edit history)

[Aswin C.]

first of all in settings of smarty set debug to ON ...

and see what exactly takes so long,

inr preference -> performance -> set force compile on AND smarty cache off
/config/smarty.config.inc.php  ::   $smarty->debugging = true;

 

now see what exactly takes so long. ( in the popup )

that might give you a good hint about with block is poorly written.

and don't just visit the homepage with debugging on... try some deep nested product.

 

besides this, there is a HUGE bugg in the block category.

he caches the output of the category block.

the html looks different for each category you have --> somewhere html is class="selected"

so you need for each language and each category and each costumer group a cache file with the generated html code for the category block.

20 categories * 2 languages = 40 cache files....

 

look at the code:

$smartyCacheId = 'blockcategories|'.$groups.'_'.$id_lang.'_'.$id_product.'_'.$id_category;

he says you need one cache file for each costumer group,

each language, and EACH PRODUCT !!!!! AND each category

so with 20 categories * 2 languages * 1 cust group * 20k products = to much files

 

with 170 categories you have a 17KB cache file.

170 categories * 2 lang * 1 * 20k producs = 6 800 000 files !!

6 800 000 * 16 KB = 106 GB !!!!!!!

 

 

this gets very drastic if you have more categories ( like 100 or 1000 )

not only you need LOTS of storage ...

your site will be never cached for that block unless ALL products and categories for EACH language have been visited.

so each time a visitor gets for the first time on a product or category ...

he needs to do the query + rebuild the HTML for the category block .

 

 

/tools/smarty/cache --> look there. how many blockcat files you have.

clear everything

visit homepage -> takes long. , one cache file is added.

visit again -> fast

go to one product -> takes long, one cache file is added

go to an other product in same category, one cache file is added ....

.....

Edited July 20, 2012 by AswinC (see edit history)

[sbm]

Hi answic,

 

I disabled the category block, but the load time is still the same....

 

Deleting the blockcat files wont affect the database?

 

First time visitors will experience high load times anyway?

 

Regards,

 

Steven

[Aswin C.]

I don't think you read everything.

no watch inside those files it is just the generated html, it has nothing to do with database what so ever.

 

 

inr preference -> performance -> set force compile on AND smarty cache off

in file /config/smarty.config.inc.php set $smarty->debugging = true;

 

do that and prestashop is exactly TELLING you what is slow.

either way small categories or not small categories...

you will end up with amount of products * languages * categories... which is a big bugg. + cache gets invalid each hour.

[bellini13]

so if I understand aswinc correctly, this is an issue if you have a lot of languages, products and categories. so this might not affect everyone user with a store, that remains to be seen.

 

there are still plenty of other issues that will cause the TTFB to be high. search the forums on the topic

[Aswin C.]

As I said, set smarty debug to true, and prestashop will tell you what the problem is.

Caching ? rendering ? compiling ? --- he will tell

 

But try to open a folder on your pc with 20 000 files in it. ( cache folder )

your operating system isn't happy with that.

Exactly for that reason, prestashop is using alphabethic sub folders for images.

so if the math [ languages * products * categories * costumer group ] > 10 000

Then yes this would be a problem.

- 100 categories isn't that much,

- 4 languages, isn't that much.

- 500 products isn't that much

100 * 4 * 500 = 200 000 files !

200 000 files of lets says ~10 KB = 1.9 GB in one folder.

 

500 cats * 4 lang * 20 000 products * 3 costumer groups = 240 Million files !

 

The forum's are full of people asking for a button for cleaning up the cache because its getting to big..

The cache cleans up himself !!! so why are their so many ppl asking for it ?

Some even claim you must clean this each day to speed up the website .. What???

because it are so MUCH files that it looks like you need to clean them up manually .

and if you need one file in such a big big folder it takes a long time...

FAT32 has even a limit of 65 000 files in one folder.

NTFS 4 billion.

EXT3 has not a real limit. ( limited by drive size )

but either way none of all are happy with many files in one folder.

for instance: the c-lib readdir() reads up to 32 000 entries at one time.

And iterates over them in a slow linear unsorted way.

so if you have more then 32 000 files in one folder, performance will go south in a fast way.

So much that even for a small website, finding one file in a list of 32 000 items will take up a serious amount of time. ( and that for each file you need from the cache folder )

 

but either way... the amount of cache files caused by blockcategory will be a problem for everyone.

and about the sites with a big size of categories it will cause continuously CPU pikes because the cache will expire each hour and he needs to query + re-render (cpu spike) the output and save the cache again + you need crazy lot of storage.

he sets the lifetime of the cache to a year, but its at the wrong line...

so when he checks if the cache is valid, the default value of one hour lifetime is there...

So each hour the cache expires. meaning all those 200k blockcart cache files are useless.

Edited July 21, 2012 by AswinC (see edit history)

[bellini13]

so aswinc, you obviously have located an issue for some users that have a lot of cache files. I know you posted your solution above, but reading through it, it is not easy to understand what you have changed.

 

perhaps you can provide override files in a zip file for a particular version of prestashop, or provide the changes in an easier to understand format.

[sbm]

Yes answic, please. I understand your point, but not sure about the steps to solve it. Could you list in detail the steps please?

[guest*]

i had reported in a similar post. I saw a vast improvement by reviewing all the modules that are disabled, and uninstalling them and removing their hooks in the position page. The core code still executes the hooks even though they are disabled.

helped nothing for me...

In addition, there are a handful of tables that do not have proper indexes. There are queries that are using columns in where clauses, and those columns need indexes to perform efficiently.

And this is the main point... Indexes are wrong set in the DB, which causes big problem on big catalogs. Are you running a catalog under or near by 2.000 products, each good server package should work with it like a charm. The problem is that big catalogs cannot overlay this invisible bad coding on queries. The DB will be slower on each byte she has to process.

This "bug" is only available after all versions 1.4.5.1. Still there no issues on this. That's why I downgraded, to don't loose my customers.

[sbm]

Hi answic,

 

How much time did you reduced your load time by doing what you did ( from how many secs to how many?).

Can you please list the steps you followed? ( just disabled the category block and eliminated the catblock files?)

 

Thanks,

 

Steven

[Eddan]

No, sorry. you must migrate each table-data of your DB to an clean, empty one. Don't do it by copy to, because you are also copying than the index and SQL-queries. You should pay attention to only migrate the data of each table.

 

I have uppgraded to 1,4,8,2 from 1,3,7,0 and I got the same slowload issue, now I´m thinking of downgrading to 1.4.5.1 and if I understand you right the I can do as follows.

 

1. I restore my backup 1.3.7.0 db.'

2. I upgrade to 1.4.5.1 as usual upgrade method

3. After upgrading, I export only data (not structure) from 1,4,8,2 db tables onto 1.4.5.1 (so I get all new orders and customers after upgrading to 1.4.8.2)

 

Is it something that I missed?

 

BR

Eddan

[rkinfo]

Hi everyone, please take a look at http://addons.prestashop.com/en/administration-tools/4633-Performance-Booster.html

This module fully caches the pages and, without initializing PrestaShop, provides your visitors with ready output that takes significantly less time to load.

 

Do you have examples?

[bellini13]

@AITOC: i think you could sell that module better if you can baseline the performance results without your addon, and then apply your addon and document the performance results to show how much better the store would work.

[rkinfo]

@rkinfo

 

I really don't know what you want to say to me. You are linkig to webpagetest to a demoshop with only some products and some categories. I made a comparation between PS default versions, it says: 1.4.4.0, 1.4.5.1, 1.4.6.2 and 1.4.7.3. All the four with presta standard theme, presta standard demo categories and products. The performance between 1.4.4.0. and 1.4.5.1 is better that the performance for the version 1.4.6.2 and 1.4..7.3. this compared on the same server and all the same. till 2.000 products you don't will notice any difference between the versions, but all shops over this wil. notice the extreme fall down of the parse.

 

For me as seller it is not important what a demoshop can or how fast it is. For me it is important to have the same performance on a live shop, and this is not what happens when you use a version 1.4.6.2 onwards. The best versions, with best performance are 1.4.4.0 and 1.4.5.1. So for big shops recommendable, also without need of extra performance settings like the one I named in here before. I'm speaking on facts, aside from that I'm not selling PS-Shops but my own products. And I need a reliable, fast software for this.

 

What do I want to say? Not much. Just general frustration like you. I find it annoying Prestashop provides these built in capabilities for APC and Memcached but has nil documentation on it - if you are lucky you might get your hosting provider to install it correctly for you and have it running optimally. In addition to that - there are all these guides now that say "Just install an opcode cache like APC or eAccellerator" as if it were some very easy thing that just works right off the bat. I've found nothing but frustration with memcache - finding that it either is not working period or was not at all working correctly with Prestashop. (wouldn't create servers in the BO)

Additionally memcache seems to cache things you do NEVER want to cache - adding further absurdity to the grossly oversimplified guides that say "just get memcached going!" Which I've found requires creating filters or lists for particular tables - otherwise you are CONSTANTLY flushing the cache every time you need to make an update to your shop. APC is nearly as bad - it will cache CacheAPC.php and other files and create redudant caching problems - requiring you to needle through every and any potential php file that could overlap. Not to mention flushing that cache incessantly....

 

Also. The worst offender in 1.4.6 and higher is, in my experience is that 'Products Category' module. I knocked a good 200ms off product page first time bytes by ditching it. I'm looking into setting up caching for it, however

Edited September 19, 2012 by rkinfo (see edit history)

[rkinfo]

Hi everyone, please take a look at http://addons.prestashop.com/en/administration-tools/4633-Performance-Booster.html

This module fully caches the pages and, without initializing PrestaShop, provides your visitors with ready output that takes significantly less time to load.

 

Can you provide some examples? I bet plenty of people would pay for this when they see all the fast sites.