PrestaShop 1.6.0.8 Performance Help

[Anelmo]

Hi,

 

I'm running PrestaShop 1.6.0.8 on a 2xCPU Linux VPS With 3 GB RAM  . Circka 3000 Products. Have tuned PS with APC (nginx webserver 1.6.0) and getting great load times in both FO and BO most of the time, but it seems to buckle under with modest load. Goes from 2 sec load times to 40 sec.. according to my monitoring.

 

In BO I get weird problems like the new order notification/ messages not counting down when I check them /read them.. (caching)  ..

 

I've used osCommerce and Zen Cart since 2004 but now I really are starting to doubt PrestaShop ever running without needing expert help for every minute detail of setting this up...

 

Can this software really not be run without caching or monster specs on hardware?.

 

I'm running vBulletin 5.x on the same Linux VPS and it has great load times..

 

Is there any decent setup guides excluding Prestashop's own?

 

 

 

 

[El Patron]

often times, out of the box things are grovvy, where we start to have issue is when we customize either with modules/themes.

 

to discover what is going on in ps under the hood then one should use ps debug profiling

 

config/settings.inc.php

 

set this to true

define('_PS_DEBUG_PROFILING_', false);

replicate issue and note (copy findings).

 

if one does not do this often, then we it is more difficult to trace back to point of slowdown.

 

It is important to note that when set to true, all visitors will see this information, fo or bo...so use carefully..

[El Patron]

also as an aside, make sure this hot fix is applied

 

http://www.prestashop.com/forums/topic/349796-performance-hot-fix-please-apply-solved-1609-class-indexphp-has-disappeared/

[Anelmo]

I'm running 1.6.0.8 and the file exists in the cache folder.

When running the debug info parameter with true setting ,it showed the following error:

 

Warning: apc_store(): Unable to allocate memory for pool. in line 50..

 

Saw another topic on the forum about emptying smarty cache.. tried but got timeouts.. believe I got it at last, but not sure if this is the complete picture.

 

This afternoon I have had to orders duplicate entries in backoffice (one quadruple entries(!)) , using different payment methods... The first one was with credit card handled on external site. Payment has been approved only 1 time with my credit card handler, but 4 separate order entries in Back Office lowering the stock for each order...

 

My suspicions lie on caching problem of some sort... but the whole thing is getting pretty annoying..

Edited September 13, 2014 by Anelmo (see edit history)

[El Patron]

I'm running 1.6.0.8 and the file exists in the cache folder.

When running the debug info parameter with true setting ,it showed the following error:

 

Warning: apc_store(): Unable to allocate memory for pool. in line 50..

 

Saw another topic on the forum about emptying smarty cache.. tried but got timeouts.. believe I got it at last, but not sure if this is the complete picture.

 

This afternoon I have had to orders duplicate entries in backoffice (one quadruple entries(!)) , using different payment methods... The first one was with credit card handled on external site. Payment has been approved only 1 time with my credit card handler, but 4 separate order entries in Back Office lowering the stock for each order...

 

My suspicions lie on caching problem of some sort... but the whole thing is getting pretty annoying..

 

yes, these things are a pain for sure, to me sounds like override that is causing that issue. (duplicate entries). so poke around your override folder and review any overrides there.  This can also be caused by module hooked to orders so see module-->positions

 

and I don't think you have the fix I mentioned if 1.6.0.8, as the fix was for 1.6.0.9 but one can retrofit backwards.

 

Personally I prefer modules that directly address ps performance as underlying server type caching is not specific to ps in general.  so of course we see issues on forum related to server cache.  I prefer method of tuning ps and using whatever specific module to address before I'd look at server cache.  but that is just my two cents.

 

also use the profiling I mentioned above, it can provide some really good info to help you understand how your shop is doing.

[Anelmo]

Thanks for the tips, I'll look into it and also talk to my webhost, I'll update this thread when I have new info :-)

[Anelmo]

Hi, got help from a Linux expert, and I think we're on to something on the hardware running the Linux VPS.

 

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
                       11.35    0.03    2.01   30.48    0.00   56.14

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
hda              19.99       288.65       207.36    1122003     806014
hda1              0.02         0.51         0.00       1990         14
hda2              0.01         0.42         0.00       1635          0
hda3             19.95       287.57       207.35    1117794     806000

 

As you can see the iowait is ca 30% which would indicate either hardware problems or stress/load on the disks used by the VM.

 

I'll check with my host tomorrow.

[El Patron]

what is vps, just souped up shared, in that another partition can suck the resources and page you out.  I worked in vm and it's not that uncommon depending on how they set up favor etc. by partition.  good luck!

[Anelmo]

Hi,

 

Finally thing seems to have been resolved. RAID on host machine was not optimal. Also connector software between host and vm was updated. IOwait has been drastically reduced. We removed nginx and went back to Apache keeping fastcgi, and we get great speed at the moment. Hopefully it will persist :-)

 

Thanks for input