Tuning PrestaShop 1.5

[Nils-H]

I'm trying to squeeze out a little more speed of my PrestaShop site. I have tried running Apache2 with fastcgi/php-fpm instead of mod-php, and I have tried installing and enabling APC. Using _PS_DEBUG_PROFILING_, I cannot see any substantial increase of performance, which surprises me. I have verified with phpinfo() that it is in fact running with the expected modules. 

 

Have anyone noticed any improvement of performance tweaking this setup/parameters?

[Dh42]

I haven't seen your site, but the first thing I would recommend is optimizing all of the on site aspects of your site, then move on to server side.

 

As far as having apc installed, do you have a apc.php file so you can see your cache hits and misses? Also what is the shm set at? Depending on the site size, I would go for at least 64mb. 

 

Using fast cgi does to me improve the site speed to over dso or suPhp. 

 

One thing I would ask is who are you using for hosting and what package? I have been having a dog of a time lately with my clients using hosts that do not provide enough processing power for the accounts. You can have all of the memory in the world, but if there is not processing power nothing will ever get done. 

 

Another couple things that I would recommend are mod_pagespeed and there is a whm plugin called apache booster. It uses a nginx / varnish reverse proxy for static files on your server. 

 

also what version of Prestashop are you running?

[roband]

As Dh42 wrote above, site optimizations initially help more than server-side optimization. Check out your site using the Google PageSpeed and Yahoo YSlow browser addons.

 

First think to check is that you have turned on the Prestashop CCC optimizations under  Advanced Parameters -> Performance.

 

Unless your database is very slow I would drop APC, instead install zendopcache, it's the PHP op-cache you normally want, not the database cache.

 

 

Cheers, Robert.

[Nils-H]

I'm running PrestaShop 1.5.5.0 in a Xen DomU on my dedicated server at hezner. The box itself is a Intel® Core i7-3770 with 32GB RAM. I have (so far) dedicated 1GB ram and 1 VCPU to the DomU. I thought APC actually was the opcode cache. If it is not, then I'll certainly look into zendopcache.

 

The site is http://htpc.no

 

BTW: I'm using combinations, which generates a few thousand products in some cases. That might have an impact as well.

Edited September 9, 2013 by Nils-H (see edit history)

[Dh42]

I am sorry, but I have to disagree with just about everything that Roband said. 

 

Zend optimizer is going to be the cache in php 5.5, but APC works better for Prestashop in all the tests that I have done, and I have done a lot of tests.

 

Server optimizations are going to give you the most bang for your buck in my opinion. But they are more expensive than on site optimizations. 

 

You actually want the PHP and the database to utilize caching to be honest. You should use mysqltuner.pl on your server it can give great suggestions on what your mysql caches need to be. 

 

One other thing I would recommend is to move to a server with an enterprise class processor. 

[Nils-H]

I tried doubling the number of vcpus and double the RAM for the DomU, but there is no noticable change in speed.

[roband]

Server specs look fine.

 

APC is kinda weird, it's both a opcode cache and a database cache. The PHP project has deprecated it, the opcode cache in zendopcache is better.

 

Your site performance looks pretty good. Only obvious thing I see is to enable CCC.

 

htpc jo, har handlet fra deg der jeg, gratulerer med nytt nettsted!

 

 

Cheers, Robert.

[Dh42]

APC was not depricated, it was never part of PHP project. It was considered to be the opcode cache for php, but was booted by zend. Just because zend was chosen does not mean that APC is not actually better, because it is with Prestashop. 

 

This what a stock 1.5.5 install loads in with a good server and apc installed, http://tools.pingdom.com/fpt/#!/eM8aNv/http://bijouthings.com/prestashop

[Nils-H]

Thank you for your input. I'm already using CCC. At least it is set to on in the back office... Pingdom says my page loads half as fast as your example, so I guess there's something to gain somewhere...

Edited September 9, 2013 by Nils-H (see edit history)

[El Patron]

one may want to focus on their mysql setup.  You can get the run-time variable using your phpmyadmin, it even highlights in red where there are issues/improvements that can be made.

[Nils-H]

I did run logging of slow queries, and nothing ends up there. It's rather an issue with the amount of queries. Especially when using combinations. A little off topic really, but when saving a combination product in the back office, it might take as long as 3-4 minutes before the update is completed, and several thousand update queries are made...

 

I have tried setting up some alias subdomains and using them as media servers. At least that increases the number of parallell requests the browser can make, so it is a little bit faster.

[Nils-H]

After running in staging for a while, these are the steps I have taken to (try to) improve the site speed:

 

• - Run with FastCGI/PHP-FPM, connecting to file socket instead of tcp
• - Add subdomain redirects to static files, and adding them as media servers, so the concurrency of the browser increases (it doesnt offload my server though)
• - Install mod_pagespeed

 

I think the performance is better now, although the pingdom-tool does report quite high page load speeds. I think that is related to some javascripts that run asynchronously though. The score is now 79. I did try to enable APC, but that didn't give any noticable increase in performance for me, and it also resulted in some strange redirect problems. Basically, all page loads resulted in an intedmediate "this page has been moved" page being displayed. So I have not dared enabling it in my production site.

 

The only really big annoyance performance wise now is the incredibly slow saving of combination products, but I fear that is a core prestashop issue, not something that can be tuned.

Edited September 11, 2013 by Nils-H (see edit history)

[El Patron]

one may want to focus on their mysql setup.  You can get the run-time variable using your phpmyadmin, it even highlights in red where there are issues/improvements that can be made.

did you look at your mysql runtime?

[Nils-H]

I have logged all queries and noticed that each individual query does not take long time, yes. If that's what you mean. I don't use phpmyadmin, and I don't intend to either, noticing all the hacking attempts targetted towards it in my webserver logs.

 

I did enable apc anyway though. I notice that the hit-rate is in the 80% area. It still doesn't seem to affect the performance though.

Edited September 11, 2013 by Nils-H (see edit history)

[El Patron]

I have logged all queries and noticed that each individual query does not take long time, yes. If that's what you mean. I don't use phpmyadmin, and I don't intend to either, noticing all the hacking attempts targetted towards it in my webserver logs.

 

I did enable apc anyway though. I notice that the hit-rate is in the 80% area. It still doesn't seem to affect the performance though.

I have never 'ever' heard that about phpmyadmin.  When one realizes that their cms is limited by the db..they can move forward in their quest for a faster shop...

[Nils-H]

Maybe not, but I don't feel the need to install it, as I have access to the command line tools I feel I need. Anyway, I doubt that the database itself is the culprit. I rather think it's how PrestaShop uses it.

[Nils-H]

I did enable profiling in the back office, and I can see that the SQL queries are only a minor part of the load times. I have a feeling that it's the javascripts that are the "sinners":

 

 

Edited September 11, 2013 by Nils-H (see edit history)

[Pressed0024]

After running in staging for a while, these are the steps I have taken to (try to) improve the site speed:

 

• - Run with FastCGI/PHP-FPM, connecting to file socket instead of tcp
• - Add subdomain redirects to static files, and adding them as media servers, so the concurrency of the browser increases (it doesnt offload my server though)
• - Install mod_pagespeed

 

I think the performance is better now, although the pingdom-tool does report quite high page load speeds. I think that is related to some javascripts that run asynchronously though. The score is now 79. I did try to enable APC, but that didn't give any noticable increase in performance for me, and it also resulted in some strange redirect problems. Basically, all page loads resulted in an intedmediate "this page has been moved" page being displayed. So I have not dared enabling it in my production site.

 

The only really big annoyance performance wise now is the incredibly slow saving of combination products, but I fear that is a core prestashop issue, not something that can be tuned.

 

I am also getting 404 after activating APC on prestashop. Accept for the homepage, all other pages get 404. Setting APC as disabled by turning off cache also does not resolve the 404. The 404 somehow gets resolved magically over time (a few hours). I retested this several time.

 

Any reason why APC is causing URL rewrite to fail?

[Dh42]

There is no reason it would cause the rewrite to fail. I would try generating a new htaccess file. 

 

The redirect issue that nils-H was talking about is because he has debug profiling enabled. 

[Pressed0024]

There is no reason it would cause the rewrite to fail. I would try generating a new htaccess file. 

 

The redirect issue that nils-H was talking about is because he has debug profiling enabled. 

The weird thing is that it gets magically fixed over time. Changing the htaccess may not work since it hasn't been touched as I can see. It's the same as when it was in working condition.

 

Could any of the APC ttl cause this? I'm not sure how.

[Dh42]

I cannot cause this. Are you running any other type of caching engine?

[Pressed0024]

This are the settings at cpanel. It's a page where I can check and uncheck the modules:

 

I also have Full Page Cache prestashop module running. That's about it. The rest are typical Smarty, CCC, etc.

 

[Dh42]

Turn off the full page cache module that is more than likely your problem. 

[Trip]

Hi there,

as stated in another post already I recognized a big difference in performance when I changed

 

Minify HTML to Keep HTML as original and

Compress inline JavaScript in HTML to Keep inline JavaScript in HTML as original under CCC options 

 

With Minify HTML after "smarty compile" execution and Compress inline JavaScript in HTML after "smarty compile" execution. I get

a wait time of 1.37 secs

http://tools.pingdom.com/fpt/#!/c3sD6m/http://www.jing-shop.com/en/14-ethno-and-festivalpants

Without these option I get a wait time of 0.256 secs which is about 1,2 seconds faster and feels a lot less sluggy than before.
http://tools.pingdom.com/fpt/#!/eQjNRL/www.jing-shop.com/en/14-ethno-and-festivalpants

 

I wonder if anyone can test the different setups to verify my observations?

All the best, Trip

 

Edited November 17, 2013 by Trip (see edit history)

[Pressed0024]

Turn off the full page cache module that is more than likely your problem. 

1. I tried turning it off. It didn't help. I zoomed down the possibility and it has to do with choosing the caching system in Prestashop BO (memcached, APC, etc). The moment it's changed, the problem occur and I have to wait it out for the site to return to normal working state.

 

2. Also, when I do get APC to work, somehow APC keeps flushing itself. I see the fragmentation there once APC caching system is selected but after a few refresh at apc.php, the cache flushes itself making APC useless. Hit and Miss returns to 1 and 0 respectively. The uptime always shows 0 minutes. I have checked that the timezone used in php.ini and my server timezone (via SSH date check) is the same. So there is no time difference.

 

I followed your APC config and a few others (since yours didn't work for me). Also tried to play around with the settings, it still auto flushes itself every 2-5 secs or so:

 

https://drupal.org/node/1777090

http://blog.dh42.com/fastest-prestashop/

http://www.vionblog.com/biggest-apc-configuration-mistake/

http://www.cyberciti.biz/faq/linux-unix-php-warning-unable-to-allocate-memory-for-pool/

 

3. I also noticed setting apc.mmap_file_mask="/var/tmp/apc.XXXXXX" creates tonnes of i/o for my hosting account. It maxed out my allowed i/o usage, making the whole site sluggish. How does this work?

 

Anyone out there to help?

[Pressed0024]

Here's my APC settings. Server has suPHP. If only I can get the APC to stop flushing itself like a toilet bowl:

 

[Dh42]

The APC problem you are having is more than likely because you are not running PHP correctly. Which interpreter are you using? APC only works with FASTcgi or DSO php. If you are running PHP under SUexec it is not going to work because of the way that threads are handled. 

[Pressed0024]

The APC problem you are having is more than likely because you are not running PHP correctly. Which interpreter are you using? APC only works with FASTcgi or DSO php. If you are running PHP under SUexec it is not going to work because of the way that threads are handled. 

Yes, I figured that out yesterday. I searched "APC uptime 0 minutes" and lotsa results. There is a solution here but unfortunately I'm on Shared Hosting (with SSH): http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/#implementation

 

1. I decided to hop over and use Zend opCache. I use https://github.com/amnuts/opcache-gui to check the stats. It has the same issue like APC where it keeps flushing cache due to multi threads. Is there any benefit to keep opCache running on my shop despite it flushing itself every 1-5 seconds? 

 

2. I also have Prestashop Full Page Cache module running which gives good speed by storing the compiled HTML in cache in /cache/pagecache/. But assuming I get to fix the Zend opCache/APC flushing issue, is there anyway to make the opcode cacher cache the compiled HTML from /cache/pagecache/ instead? That would make it incredibly FAST since it reads the compilied HTML from RAM! http://www.prestashop.com/forums/topic/281654-module-page-cache-speedup-your-shop/

Edited November 18, 2013 by Pressed0024 (see edit history)

[Dh42]

More than likely php is not set up correctly to run any kind of caching. There is no benefit to running the caching modules in that state. 

 

Opcode caches do not store the html in memory, you would need varnish or something similar to do that, but you are going to run into issues if you use varnish to cache anything other than static assets. 

[Pressed0024]

More than likely php is not set up correctly to run any kind of caching. There is no benefit to running the caching modules in that state. 

 

Opcode caches do not store the html in memory, you would need varnish or something similar to do that, but you are going to run into issues if you use varnish to cache anything other than static assets. 

 

 

I actually think http://addons.prestashop.com/en/administration-tools-prestashop-modules/7939-page-cache.html would be able to replace Varnish and way easier to configure. The only benefit of Varnish is that the cached files are in RAM but the above FPC prestashop module is cached in hdd (only way to make it faster is use SSD).

 

I saw in your blog post about using Varnish to cache static contents like images. If I already use CDN, what benefit does the Varnish still give since it won't be able to cache html? (html is the only I can't do CDN)

[Dh42]

I actually don't really recommend using a CDN for most clients. It depends on how much traffic you are getting to your site really. A good rule of thumb is if you are using shared hosting, a CDN is a waste of money. For a CDN to work properly, your files have to be accessed a lot. Places like cloudflare will not cache files that are not used a lot, so there is no benefit. Plus one thing you have to deal with using a CDN is slow DNS responses, and the added weight of the CDN cookie on the resources. 

 

There are a lot of misconceptions about what it takes to make a site fast. I don't necessarily thing that SSD drives do the trick either, it is just another gimmick to sell you something. This site is running on my dedicated server that I set up, it is using Prestashop 1.5 and no CDN, http://screencast.com/t/XEQZ98Sa  You can't really get much faster than that. It is not running a caching module either. 

 

Most of the server latency you get is from the disk, there is a huge benefit to running varnish over having disk's accessing a resource. 

[fallbright]

this forum is very helpful..

[Pressed0024]

I actually don't really recommend using a CDN for most clients. It depends on how much traffic you are getting to your site really. A good rule of thumb is if you are using shared hosting, a CDN is a waste of money. For a CDN to work properly, your files have to be accessed a lot. Places like cloudflare will not cache files that are not used a lot, so there is no benefit. Plus one thing you have to deal with using a CDN is slow DNS responses, and the added weight of the CDN cookie on the resources. 

 

There are a lot of misconceptions about what it takes to make a site fast. I don't necessarily thing that SSD drives do the trick either, it is just another gimmick to sell you something. This site is running on my dedicated server that I set up, it is using Prestashop 1.5 and no CDN, http://screencast.com/t/XEQZ98Sa  You can't really get much faster than that. It is not running a caching module either. 

 

Most of the server latency you get is from the disk, there is a huge benefit to running varnish over having disk's accessing a resource. 

 

But that is on the static content part like CSS, JS and images which at the moment isn't slowing my site down.

 

The thing that is slow is the first HTML that gets loaded. I'm assuming Varnish doesn't play a role here since it can only be useful for non PHP and HTML objects?

[Dh42]

The first html loading slow is because your server is not devoting enough resources to your site. It takes time to complete that request, and more than likely your server is throttling your cpu. There is no way around speeding that up other than to get better hosting. It is a factor of things that build the pages, but somewhere you have a bottle neck. Where do you host at again?

[Pressed0024]

Stablehost - Enterprise Plan. I get to use 100% of 2 cores. Most of the time, resources are as shown here with CPU 8-12% when there are a few visitors. Rarely see CPU more than 20%:

 

Edited November 18, 2013 by Pressed0024 (see edit history)

[Dh42]

I personally would think and 8% load is too high. Things start getting sluggish around 4% or so I have seen. 

[Pressed0024]

I personally would think and 8% load is too high. Things start getting sluggish around 4% or so I have seen. 

 

Meaning faster CPU speed (mhz) is needed or more CPU core/% needs to be allocated to my account?

[Dh42]

More than likely. I mean, this is how I think of it, I looked at the plans on the site you linked, for $20 a month I can get a server and have 2 cores dedicated to myself. What are they cores of though? This is who I use and their machines are very reasonably priced, http://www.webhostingbuzz.com/dedicated-servers.php but a 4 core dedicated machine bottom of the like is $140 a month. I don't think they are giving 2 true cores for $20 a month, they couldn't make money on it. If they are, they are not xeon class cores, your site could be running a intel celeron or something like that. 

[Pressed0024]

Its running on dual Intel Xeon L5520 @ 2.27GHz. 

 

How bad can that be?

[Tia©]

Hi there,

as stated in another post already I recognized a big difference in performance when I changed

 

Minify HTML to Keep HTML as original and

Compress inline JavaScript in HTML to Keep inline JavaScript in HTML as original under CCC options 

 

With Minify HTML after "smarty compile" execution and Compress inline JavaScript in HTML after "smarty compile" execution. I get

a wait time of 1.37 secs

http://tools.pingdom.com/fpt/#!/c3sD6m/http://www.jing-shop.com/en/14-ethno-and-festivalpants

 

Without these option I get a wait time of 0.256 secs which is about 1,2 seconds faster and feels a lot less sluggy than before.

http://tools.pingdom.com/fpt/#!/eQjNRL/www.jing-shop.com/en/14-ethno-and-festivalpants

 

I wonder if anyone can test the different setups to verify my observations?

All the best, Trip

 

 

Hi,

nice observation.

I try this test and my first byte time improved a lot.

Thank's!

[El Patron]

for 1.5,  the best turning of front office? JavaPro  zoom zoom