2.2.2 Extremely Slow

Just upgraded from 2.1.4 to 2.2.2.



My site is now extremely slow!! What has changed to affect this? I reverted back to 2.1.4 and it seems as if something broke the database now.



Everything worked great in my preprod environment… so confused whats going on and can't figure this out.



Anyone else having this issue or have a resolution?

–UPDATE–



Installing a fresh copy of 2.2.2 I did not experience the slow issues. I'm not sure the technical reasons… but I ended up running a DB repair and Optimize after the upgrade and the site responded much better.



My ISP told me that when I did the upgrade from 2.1.4 to 2.2.2, it appeared to them that there were several rows causing loopback references which put additional strain on the server.



So I guess anyone having this issue too… repair and optimize the DB **Backup the DB before you do that though.

Thanks for telling. I have the same problem, even worse. My webshop (www.akaijashop.com) needs about 30 secends and then suddenly shows up. And sometimes it loads perfectly well I hear from friends.



I shall do the DB trick you mentioned and let you know if it worked.

Update… I've checked the database. I use CPanel on the server.

I backed up the DB first. I noticed it needed a long time with cscart_stat_product_search, but maybe that is normal.

Then did a check and it returned several issues that needed fixing.

Then I did a repair and after that all issues were gone.



But the webshop still is equally slow when opening.

The ISP says the load on the server is low and other website don't have this issue.



Anyone an idea?

The only other thing I have done is clearing the cache… at least once a week or so… wrote a cron job for that…

AND clear the logs / stats. That was taking up like 90mb in the DB and my ISP indicated that those tables put a lot of load on the shared DB servers. I clear them st least every week, but export my logs for archival purposes prior… another script. I enabled cpanel awstats / webanalizer for that information.



There should be an option in the portal to enable or disable certain cart stats to log.



Just recently, I cleaned up my site, reducing number of blocks/content, removing larger banners with gif animations and replacing with the slideshow mod… and wow, I increased the speed at least by 30%.



You may want to see if you have a script,graphic or something that is consuming php resources

[quote name='carterj' timestamp='1316537193' post='121991']

You may want to see if you have a script,graphic or something that is consuming php resources

[/quote]



Thank you for telling.



I think (it looks like it) that the problem was caused by a currency rates addon. It was strange that first time visitor needed to wait 30 seconds. Then all worked fine. I guess that this addon checked a website or webaddress (for actual rates of the day) no longer active, or with changed parameters. That would explain why the shop hangs. It waits for a response, and when it doesn't come, continues after 30 seconds. Most people have moved on by then.

Once the cache is cleared, the first access has to rebuild it. Hence, the first access after a cache clear is the slowest.

You should also look at changing your backend cache method in config.local.php from “file” to “sqlite” if supported by your server. It is much faster and generates far less load on the underlying server. There are many technical reasons why 'file' can be a problem, too many to discuss here since it's been discussed in other threads.

Thank you. I'll look into that. Sounds good.

[font=“Verdana”]I agree.

File caching has its advantages in certain applications (e.g. uses, not scripts). However, SQLite, is by far the best option for CS-Cart as the server can perform so many more operations in an environment designed for high amounts of queries…



I’m glad it was mentioned…



CARTERJ:

Sounds like a good idea with the CRON job. But how do you even setup the basic cron jobs in CS-Cart. That’s one area where the is ZERO documentation.

Would you mind sharing how you managed to automate this? Paths used and executed with CRON?



Thanks very much for everyone’s input! :)[/font]

[font=“Verdana”]I thought I should also add:

Whenever you experience a growing DB and experience slow response and loading times.

Try disabling and uninstalling the QUICK SEARCH addon.

Then perform a Backup. Then Optimise. And backup once more.



Then you can either leave it disabled, or turn it back on.

There seem to be a few addons that cause the Database to grow exponentially.



Automating the CRON to include a backup and optimise would be a good idea - weekly for example. (would love to know how to run the cron anyway!) :P[/font]

Here's instructions and an example of how to run a script withing the Admin context of the cart from CRON.


```php

/**
** Usage: Use the root of your store as the working directory for CRON
** Use this command line: php ./addons/my_changes/ --pw=
** where is the password used for password reminders in Administration/Settings/Security Settings
**/
define('AREA', 'A');
define('AREA_NAME', 'admin');
if( !file_exists('./prepare.php') )
chdir('../..');
require_once("./prepare.php");
require_once("./init.php");

define("RUN_FROM_CRON", true);

if( RUN_FROM_CRON ) {
$cron_password = Registry::get('settings.Security.cron_password');
if( !$cron_password )
die('Bad pass');

if ((!isset($_REQUEST['pw']) || $cron_password != $_REQUEST['pw']) ) {
die(fn_get_lang_var('access_denied'));
}
}

/* Your code goes here to do whatever you want.
*/

?>

```

Thank you very much tbirnseth.

Might use credits to get help from CS-cart to do the rest.



Cheers,

99% of all performance issues with cs-cart usually come down to either:

  1. Database contention (too many users trying to get to the same data at the same time).
  2. Filesystem contention (too many users reading/writing the file based caching at the same time).



    Before you go off and spend money, change your 'backend_cache' to 'sqlite' in config.local.php and see if that makes a difference for you.



    Your host should be able to help you identify if the problem is with #1 above.



    You're looking for the big wins right now. The “tuning” can be done later by using gzip compression and some 3rd party optimizers.

[font=“Verdana”]Ahh, that make much more sense. I'd read all the options in the config file a while ago, and changed some options. Logging in to WHM I can see the server load is quite low, fluctuating as normal.

Server load 0.75 (8 CPUs) (Max 1.50)

Memory Used 45.64% (1,803,756 of 3,952,512)



Currently, I'd changed:

  • 'allow_php_in_templates' => true,
  • 'js_compression' => true,



    However I've now updated the config.local.php the Cache back-end to 'sqlite' now.



    Is it worth increasing the Memory Limit at the top of the file?

    I've always increased it from 32 MB to 48 or 64 MB for clients. There have been no adverse effects.



    Thank you for the tip. Appreciated it.



    However does anyone know if the other options, such as “'join_css' => false,” or “'disable_block_cache' => false,”, offer any advantage if changed?



    Thank you greatly for your advice.[/font]

Increasing memory_limit does not increase memory usage. Think of it as a limit that if hit, you die. So having it large/small doesn't matter if it's never hit. But having to raise it to unrealistic values indicates there is something wrong with your environment.



I never change the default values for the tweaks other than the backend_cache. I see these as experimental or possibly server dependent. If they worked all the time in all cases, then they probably wouldn't be options. If you use gzip compression then compressing javascript is pretty pointless and doubles up the processing. The other options should be used with care and probably enabled one at a time, wait a week, then enable the next, etc…



Part of this is about patience and doing a little and observing the results, then doing a little more. If you just blindly go enable things and you're not sure you know exactly what they do, you will probably end up with a mess on your hands.