Prestashop: It's your host...........Host: it's your software

[MassiveRC]

So I've been beating up both iPage and Prestashop because there are problems on both ends. I've done everything within my power to speed up my website outside of going with another hosting provider (which I'll do at later date).

 

One thing I've been doing nightly is going into MySQL and doing the optimize SQL on all tables, but I doubt it's doing much. Now I'm excellent at MSSQL back end set up and performance optimization, and my fiancee is good at MSSQL queries\optimization, but I'd rather hear from experts what I can do in addition to selecting all tables and clicking the 'Optimize' button, or is that all I need to do to tell iPage to go pound sand about my queries not being optimized.

Edited December 2, 2012 by MassiveRC (see edit history)

[a2hosting-andy]

Quadcopters are frigging cool - just sayin!!

 

Sorry to hear about the trouble you've been having with your host. If they're pointing fingers and not offering solutions, it probably would be wise to move on.

 

Before we get to that, though, let's gather some information here and see if we can help. For starters, how is your site set up - what type of hosting do you currently have - shared/VPS/etc?

 

Second, aside from optimizing tables, what else have you done to optimize your site? When you go to Advanced Parameters -> Performance, do you get any warnings? Do you have caching turned on? (Look both under Smarty and the Caching section at the bottom)? What all do you have checked in the CCC section?

 

I definitely noticed a difference between your static site and your store.

[tdr170]

I use Ipage and have no issues at all, most likely you need to edit your PHP.ini file and adjust a few setting such as increasing PHP memory limit, turning zlib.output compression to on, register globals should be off, magic quotes should be off, allow url fopen should be on, in addition you should have the options set under Preferences, Performance to use CCC for the first two options, minify html and compress inline javascript, leave the last option as keep Wc3.

Force compile should be off and cache should be on.

In your config.inc.php file located in the config folder you can also add this line ini_set('memory_limit','128M'); to the

/* Improve PHP configuration to prevent issues */ section.

If these are not your setting try to adjust to these and see if it helps.

[MassiveRC]

Thanks TDR, just about all those settings were already set with exception of zlib compression and the memory limit (I believe it's already in there, but was set to 32). Website is still pretty slow.

[Trip]

Use this method carefully, if there is any misconfiguration in your shop it might kill your frontend but at least you know there is something wrong.

You change

define('_PS_DEBUG_PROFILING_', true);

in /config/defines.inc.php for example like this:

In case it works it will give you nice statictics on the bottom of each page with hook/db processing time and so on to see where the bottleneck is located. Maybe it is just a module that slows down your page.

But as I said. If it crashes your shop set debug profiling to false and clear all cache files. I would use that carefully at times when there are no visitors or even better test the feature on a local copy of your installation to get confident with that.

Best regards, trip

Edited December 5, 2012 by Trip (see edit history)

[tdr170]

Thanks TDR, just about all those settings were already set with exception of zlib compression and the memory limit (I believe it's already in there, but was set to 32). Website is still pretty slow.

 

The ini_set I posted above is not part of the config.inc.php its an addition, your PHP.ini memory limit should be set the same, 32 is not nearly enough.

64 mb is the minimum amount required to run Prestashop.

[MassiveRC]

Use this method carefully, if there is any misconfiguration in your shop it might kill your frontend but at least you know there is something wrong.

You can add

define('_PS_DEBUG_PROFILING_', true);

at the beginning of config.inc.php for example like this:

/* Debug only */
@ini_set('display_errors', 'off');
define('_PS_DEBUG_SQL_', false);
define('_PS_DEBUG_PROFILING_', true);
$start_time = microtime(true);

In case it works it will give you nice statictics on the bottom of each page with hook/db processing time and so on to see where the bottleneck is located. Maybe it is just a module that slows down your page.

But as I said. If it crashes your shop set debug profiling to false and clear all cache files. I would use that carefully at times when there are no visitors or even better test the feature on a local copy of your installation to get confident with that.

Best regards, trip

 

Thanks Trip. I'm a little leary of implementing this right now, but I have uninstalled alot of fluff to try and speed up processing. I really miss the slider, but it had to go.

 

 

The ini_set I posted above is not part of the config.inc.php its an addition, your PHP.ini memory limit should be set the same, 32 is not nearly enough.

64 mb is the minimum amount required to run Prestashop.

 

Thanks. I found the file and added it. Does it take awhile to take a affect? Do I have to stop and restart PS either through maintenance mode or webservice for it take effect or is it immediate?

 

The other thing I've tried doing is adding more name servers to my domain setup, mainly the site-perf.com name servers. I tried adding Googe's 8.8.8.8, but it wouldn't take it (nor the nslookup value).

[MassiveRC]

TDR, I'm starting to see the page loading become a little more tolerable, thanks.

[SuperCharlie]

I am in central US... I clicked around a bit on the site and from a developer point of view it was too slow for me. Home page took almost 15 seconds from dead load and around 10 or so on reload.. a product link took around 7 or so. The experience was pretty wait-heavy. I did some light digging and I dont see anything really holding you back that much to have your site feel this bogged down. I would definitely make a copy of the files and database and try it on another host. I cant tell for sure, but it really smells like the web host mysql server is the bottleneck. Like the site and products.. I think ya might need a better host to make the user experience better..

 

Here is my first-look tool whenever I hear a site is slow..

http://gtmetrix.com/reports/www.massiverc.com/2e50asO2

 

In the timeline view, it appears that it takes 7 seconds before anything starts happening..which I am thinking might be the mysql server choking.

 

 

Good Luck!

SC

[BillyHardcore]

Hi, I had problems with long waiting times as described in above post, because I had enabled the Cache File System.

Enabling most of the CCC options, disabling Cache (the one with memcached, filesystem etc) but enabling the overall Cache (the one for smarty) worked, to some degree...

[MassiveRC]

I am in central US... I clicked around a bit on the site and from a developer point of view it was too slow for me. Home page took almost 15 seconds from dead load and around 10 or so on reload.. a product link took around 7 or so. The experience was pretty wait-heavy. I did some light digging and I dont see anything really holding you back that much to have your site feel this bogged down. I would definitely make a copy of the files and database and try it on another host. I cant tell for sure, but it really smells like the web host mysql server is the bottleneck. Like the site and products.. I think ya might need a better host to make the user experience better..

 

Here is my first-look tool whenever I hear a site is slow..

http://gtmetrix.com/...rc.com/2e50asO2

 

In the timeline view, it appears that it takes 7 seconds before anything starts happening..which I am thinking might be the mysql server choking.

 

 

Good Luck!

SC

 

Thanks SC. I guess it would be prudent to go with another host that supports my modules natively so If I had to reload\reinstall, I could at least start from there? I'm been spamming iPage's Facebook page because of this and normally you see their PR reps countering or even offering to help as everyone sees those posts. They know what I'm saying about their hosting is true so they can offer no reply.

[Guest]

Is the real problem shared hosting? All my sites on shared hosting are quite slow - but it is hard to justify the cost of a dedicated server

[MassiveRC]

One of the things I see is Gzip compression. It's using Zlib compression. Googling says it supports Gzip, Should I enable Gzip and why isn't this enabled by default?

[Trip]

Hey Massive,

once again. Your "server" needs 8 to 10 seconds to handle the initial request.

This has nothing to do with page compression or whatever you think you can optimize. Maybe the memory limit is to small or your database or whatever. I gave you a code snippet for debugging. You do not have much categories nor products which could make the server slow so make a local installation (copy) of your live system and see if it is slow too. If not it is a server problem - otherwise you have a configuration problem. If you can not find the bottleneck you should maybe hire a pro here for some bucks instead of groping in the dark for weeks. Your page load time is from a customer and SEO point view a nightmare. We want to help here but we do not have a crystal ball so it is hard to guess what your problem is.

Good luck, trip

[Guest]

I have just tried gtmetrix - what a great site (if frightening for me)

 

I noticed on our site, that the time delay seems to be when the site switches from to standard url to the /en url

 

 

Is this normal? We do have different languages installed, but if it having this kind of a hitch perhaps we should uninstall

[SuperCharlie]

I have just tried gtmetrix - what a great site (if frightening for me)

 

I noticed on our site, that the time delay seems to be when the site switches from to standard url to the /en url

 

 

Is this normal? We do have different languages installed, but if it having this kind of a hitch perhaps we should uninstall

 

Without getting dirty and a lot of testing etc it is hard to tell. I think you always have to make a balance between speed and functions. It is always better to get rid of things you dont need, but if you do need them then you weigh the speed against the need. I have clients who have all kinds of crazy external stuff they simply cant live without that drag their site speed down. Its a trade off.

 

I would use that tool to see if there are any glaring problems, not sweat it if the site performs to your satisfaction, and maybe try tweaking some things if the speed isnt what you want. In some cases, when youve tweaked until you are blue in the face, try some other hosting as that can bring huge differences.. And always always make backups..cuz ya never know when the next button you click or file you edit will crash the whole thing.

 

Good Luck!!

[tdr170]

Once again I use Ipage without any issues my site speed seems good, however I do not use any other languages, currencies and do not have layered navigation.

Edited December 3, 2012 by tdr170 (see edit history)

[Guest]

Once again I use Ipage without any issues my site speed seems good, however I do not use any other languages, currencies and do not have layered navigation.

 

Here is a link to my site so others can test just in case I am wrong. (been known to happen)

http://team-shepherdusa.com/shop

 

I suppose this is why we all have to be careful with stats.

 

I have just ran your site and get these figures

 

F 31% for page speed, but >80% on yslow

 

At the end of the day I suppose what SuperCharlie said makes sense. Do't sweat on it if you sites performs well enough for you. There are so many factors that can be taken into account (not least location of server compared to location of user)

[MassiveRC]

So I've stripped back a lot of stuff, layered navigation (which I wasn't even using) was uninstalled, but something that was in the back of my mind was anything related to SQL. I know that analytics are really resource intensive so I disabled a lot of the built-in analytics and statistics and the site loads much quicker now. Can you all load her again and confirm? Even the site performance tests are showing it loading quicker. Thanks.

[Dh42]

Seems a bit faster on my end.

[MassiveRC]

Thanks............the biggest difference from all the tweaking seems to be from uninstalling all the canned analytics.