Hey OP
Try recreating the problem using the firefox browser in debug mode and see if it tells you which script is causing the problem
I got an issue where a hanging script crashes IE and freezes my entire computer but if I recreate the bug in Firefox then it tells me the script:
[B]Script: [url]https://www.fukc.com/lib/jquery/jquery.js:11[/url][/B]
So might help you find the issue… give it a try!
[quote name=‘tbirnseth’]Suggest you remove the whole var/compiled directory, not just the customer subdirectory.
You can accomplish the same thing from your admin panel by simply adding a ?cc or &cc to the end of your URL.
I would NOT use mysql as the backend. The registry caches DB queries. Hence you are caching what you’re caching. Several other threads in the forum discuss this. The best seems to be ‘sqlite’ for the Registry cache.[/QUOTE]
We ended up setting up a cron job that deletes, /htdocs/demo/var/cache and /htdocs/demo/var/compiled/customer. The site checkout performance greatly improved.
We now experiencing long page load times in the admin panel when product or category pages are updated. I am suspicious that this is another caching issue. Is this why you suggested that we, “remove the whole var/compiled directory, not just the customer subdirectory.”
Thanks,
Cory
In reality, they are all interrelated. The ‘cache’ directory holds the data used by both the ‘admin’ and ‘customer’ sub directories in the ‘compiled’ directory. Hence, removing one of the ‘compiled’ subdirectories could cause the cache to become confused.
You shouldn’t have to remove the ‘compiled’ directory since it doesn’t grow until a new page reference is made. It’s the ‘cache’ directory (Registry) that tends to get unweildly especially if using a lot of filters and/or features.
[quote name=‘tbirnseth’]In reality, they are all interrelated. The ‘cache’ directory holds the data used by both the ‘admin’ and ‘customer’ sub directories in the ‘compiled’ directory. Hence, removing one of the ‘compiled’ subdirectories could cause the cache to become confused.
You shouldn’t have to remove the ‘compiled’ directory since it doesn’t grow until a new page reference is made. It’s the ‘cache’ directory (Registry) that tends to get unweildly especially if using a lot of filters and/or features.[/QUOTE]
It is very frustrating to have so many proplems with this cart out of the box… here is where we are at now
After implementing cron jobs to delete the below folders, the site performance of http://www.harrisonmotorsports.com improved at first.
/bin/rm -r -f /imedia/users/hmsport3/htdocs/var/cache/* On Sun, Twe, Thu at 3:27
/bin/rm -r -f /imedia/users/hmsport3/htdocs/var/compiled/* Everyday at 3:37
We also followed the instructions here, [url]CS-Cart Documentation — CS-Cart 4.15.x documentation , and changed the config.local.php file from $config['cache_backend'] = 'file'; to $config['cache_backend'] = 'mysql';
Now that the site is out of beta and receiving 5,000 visits a month, the checkout and admin performance have slowed.
The problem is most noticeable in the following instances:
During checkout the “Placing the order. Please be patient…” pages stays up 20-60 seconds
Changing order status in the Admin - 45-90 second page load times
Saving changes to product pages using the “save” or “save and close” buttons - 90+ second load times
Adding or removing product from categories or secondary categories
and the list goes on…
Browsing is very fast. The page load time problem only seems to occur when an item is saved in the customer or admin section.
We have also noticed that the database is growing at an exceptionally fast rate. On Monday the database was 22MB, two days later it is 31MB. The tables that are the exceptionally large are as follows:
All cscart_stat_xxx tables
cscart_sessions
Even when these are cleared through the admin (Administration > Statistics > Remove Statistics), page load times are still very slow. These appear to be two separate issues, but I may be wrong. Even if the statistics issue is unrelated to the page load times, I want to turn them off. They are redundant with Google Analytics.
The log table was previously very large, but it has been cleared and all log options with the exception of backups are now turned off. The log table is no longer growing.
Well, I’m no exactly an expert on server stuff or speed, but there are a few things that might help.
First, you don’t appear to be using Smartoptimizer or gzip. Have you looked into using those?
You ySlow grade is a D and your page speed grade is 74/100
Your page size is about 1.46 MB. That is a huge page to load.
I tried loading you site through Pingdom and Pingdom timed out before your site could load. Probably not a good thing.
Your site is also very slow loading for me.
As for your database size, if you are using mysql as your cache, of course your database size is going to grow. Personally, I use the file cache. I tried using the sqllite cache, but for some reason it would break my site from time to time.
So, a few things to try and do:
First, try and reduce your page size.
Then, install smartoptimizer and enable gzip
Change you cache back to file
Turn off your statistics
I know that you were complaining about the loading button, but you really need to try and fix this other stuff as well. Maybe when this other stuff is fixed the loading button will also be fixed.
I’m not trying to be a dick about contradicting you on your page loading speeds, but what you are saying does not reflect what I am seeing.
I hope that helps,
Brandon
Brandon,
I don’t think you are a dick. You seem to be very helpful 
The issue only occurs when an item is saved, ie something is written to the DB. Otherwise the pages seem to be loading well. Yes they could be downsized a bit, but I don’t think that is the core issue.
I’m not really sure about the problem you are having, but 30+ second load times for your home page definitely isn’t going to help you.
What type of server and specs are you using? Are you just on a shared host, VPS, or dedicated server?
Brandon
[quote name=‘brandonvd’]I’m not really sure about the problem you are having, but 30+ second load times for your home page definitely isn’t going to help you.
[/QUOTE]
Even with cache cleared the home page has never taken 30+ seconds to load. I am surprised by your numbers. Additionally, we are experiencing slow refresh times after saving in the admin as well. The admin has not been modified, so this would rule out the theory a bloated design.
I am also not sure about your suggestion to switch back to a file cache from sql. Writing to a file may be quicker initially but as that file grows it will be slower. Databases are optimized better for this type of thing.
I would NOT use mysql as the caching method.
I do not know how many products you have nor how many features or filters you use. All are factors.
It sounds like you’re slowing on INSERT’s which would indicate an over use of indexes or tables that have been cleared but have “overhead” remaining. Suggest you look at your DB and optimize tables that have wasted space.
But the first thing I would do is change the caching method to either sqlite or sqlite3 and see if that makes a difference for you. If your home page is loading slowly I would ensure I have gzip compression enabled. It is the single biggest win there is from a user performance perspective.
But as Brandon indicates, if your server can’t handle the site, that’s a whole different issue.
[quote]
am also not sure about your suggestion to switch back to a file cache from sql. Writing to a file may be quicker initially but as that file grows it will be slower. Databases are optimized better for this type of thing.
[/quote]
You asked for experiences of those who’ve come before you. Using the database to cache queries on the database is far from efficient. Using a different DB (like sqlite) is much more appropriate. But if you’re such an expert in how all this works, why are you asking us?
[quote name=‘tbirnseth’]You asked for experiences of those who’ve come before you. Using the database to cache queries on the database is far from efficient. Using a different DB (like sqlite) is much more appropriate. But if you’re such an expert in how all this works, why are you asking us?[/QUOTE]
I am not trying to ruffle anyone’s feathers. I am appreciative of the advice provided and didn’t mean to come across in any other way.
Let me rephrase…
Writing to a file may be quicker initially but as that file grows it will be slower. I was under the assumption that databases are optimized better for this type of thing.
- It is not “a” file, it is a directory heirarchy of files.
- The sqlite method is a DB and is better suited to index the information rather than reading directories in the file system to find the file of interest.
Some folks here have fixed or run many, many carts in many environments. Simply trying to tell you what our experience is. If you’re going to push back on that experience, that’s fine, but do your homework and come back with facts, not assumptions.
Your epxerience is NOT normal so there is something abnormal about your environment. No one that I know of is using mysql for the Registry cache. The whole goal of the registry is to cache DB queries so that mysql doesn’t have to be accessed.
[quote name=‘tbirnseth’]I would NOT use mysql as the caching method.
I do not know how many products you have nor how many features or filters you use. All are factors.[/QUOTE]
1000 products
3 filters
2 active features: 58 variants and 30 variants - plans to add more
[quote name=‘tbirnseth’]It sounds like you’re slowing on INSERT’s which would indicate an over use of indexes or tables that have been cleared but have “overhead” remaining. Suggest you look at your DB and optimize tables that have wasted space.[/QUOTE]
From anecdotal evidence, the data seems to be processing and the page refresh seems to be the problem. For example, when an order is placed I will receive the confirmation email long before the “Placing the order. Please be patient” has closed and the new page has opened. The notification email shows up after only a few seconds. A similar thing happens in the admin panel when a change is made and saved. Although the loading arrows will continue to run after an item has been saved, if the page is stopped and manually refreshed the changes made appear.
[quote name=‘tbirnseth’]But the first thing I would do is change the caching method to either sqlite or sqlite3 and see if that makes a difference for you. If your home page is loading slowly I would ensure I have gzip compression enabled. It is the single biggest win there is from a user performance perspective.[/QUOTE]
Other than changing $config['cache_backend'] = 'mysql'; to $config['cache_backend'] = 'sqlite'; does anything else need to be done to switch to sqlite? I have read that sqlite doesn’t play well when you have too many features. Is this true and what constitutes too many?
[quote name=‘tbirnseth’]But as Brandon indicates, if your server can’t handle the site, that’s a whole different issue.[/QUOTE]
The site is on a shared environment. I spoke to the hosting company and there have been no known spikes in server load recently. The hosting company claimed that with the site’s current traffic and low server load, there was no reason at this time to move to a VPS. The plan is for 20gb storage and 200GB bandwidth. The zen cart previously ran fine on the same server and cs-cart worked well initially.
Thanks again for the help.
[quote name=‘tbirnseth’]1) It is not “a” file, it is a directory heirarchy of files.
2) The sqlite method is a DB and is better suited to index the information rather than reading directories in the file system to find the file of interest.
Some folks here have fixed or run many, many carts in many environments. Simply trying to tell you what our experience is. If you’re going to push back on that experience, that’s fine, but do your homework and come back with facts, not assumptions.
Your epxerience is NOT normal so there is something abnormal about your environment. No one that I know of is using mysql for the Registry cache. The whole goal of the registry is to cache DB queries so that mysql doesn’t have to be accessed.[/QUOTE]
That is very helpful advice. Your comments about mysql make perfect sense. The only reason we switched was because this article suggested it, [url]CS-Cart Documentation — CS-Cart 4.15.x documentation .
As for pushing back, again that is not the impression I am trying to give. I know there are many members of this forum with significantly more cs-cart experience than myself. I am thankful of that.
I just switched to sqlite. I will monitor the site and report back.
What are the advantages of sqlite3 and are there any special requirements?
Thanks!
[quote name=‘cory1970’]I just switched to sqlite. I will monitor the site and report back.
What are the advantages of sqlite3 and are there any special requirements?
Thanks![/QUOTE]
Checkout times were initally very quick after switching to sqlite. Over the course of the day they grew to over a minute and then the cart stopped working all together.
I switched back to file with no success and eventually switched back to mysql. The checkout loading page and saving in the admin is still very slow, but it is at least working for the moment.
I submitted a ticket to CS-Cart.
My previous checkout times in seconds with $config['cache_backend'] = 'mysql'; were as follows:
16
23
18
13
55
After making changes recomended by CS-Cart and staying with mysql cache, my times were:
19
7
8
6
6
Here is the message I received from CS-Cart:
Thank you for your request.
As far as I see you use the version 2.1.0. I advise you to upgrade the store the latest version.
As for your current version In order to increase the site speed I advise you to replace the following part of code:
// Tweaks
$config['tweaks'] = array (
'js_compression' => false, // enables compession to reduce size of javascript files
'check_templates' => true, // disables templates checking to improve template engine speed
'inline_compilation' => true, // compiles nested templates in one file
'anti_csfr' => false, // protect forms from CSFR attacks (experimental)
'disable_ajax_preload' => false, // used to disable ajax preload for speed-up admin area
);
with this one:
// Tweaks
$config['tweaks'] = array (
'js_compression' => false, // enables compession to reduce size of javascript files
'check_templates' =>false, // disables templates checking to improve template engine speed
'inline_compilation' => true, // compiles nested templates in one file
'anti_csfr' => false, // protect forms from CSFR attacks (experimental)
'disable_ajax_preload' => false, // used to disable ajax preload for speed-up admin area
);
in the “config.local.php” file, located in the root directory of your CS-Cart installation and replace the following part of code:
if (AREA == 'A') {
fn_init_view_tools($_REQUEST);
}
with this one:
if (AREA == 'A') {
//fn_init_view_tools($_REQUEST);
}
in the “fn.control.php” file, located in the “core” directory and replace the following part of code:
function fn_addon_template_overrides($resource_name, &$view)
{
Registry::register_cache('template_overrides', array(), CACHE_LEVEL_STATIC);
if (!Registry::is_exist('template_overrides')) {
$template_overrides = array();
foreach (Registry::get('addons') as $a => $_settings) {
$odir = $view->template_dir . '/addons/' . $a . '/overrides';
if (is_dir($odir)) {
$tpls = fn_get_dir_contents($odir, false, true, '', '', true);
foreach ($tpls as $k => $t) {
if (empty($template_overrides[md5($t)])) {
$template_overrides[md5($t)] = 'addons/' . $a . '/overrides/' . $t;
}
}
}
}
Registry::set('template_overrides', $template_overrides);
}
$resource_name = Registry::if_get('template_overrides.' . md5($resource_name), $resource_name);
return $resource_name;
}
with this one:
function fn_addon_template_overrides($resource_name, &$view)
{
static $init = false;
$o_name = 'template_overrides_' . AREA;
if ($init == false) {
Registry::register_cache($o_name, array(), CACHE_LEVEL_STATIC);
if (!Registry::is_exist($o_name)) {
$template_overrides = array();
foreach (Registry::get('addons') as $a => $_settings) {
$odir = $view->template_dir . '/addons/' . $a . '/overrides';
if (is_dir($odir)) {
$tpls = fn_get_dir_contents($odir, false, true, '', '', true);
foreach ($tpls as $k => $t) {
if (empty($template_overrides[md5($t)])) {
$template_overrides[md5($t)] = 'addons/' . $a . '/overrides/' . $t;
}
}
}
}
if (empty($template_overrides)) {
$template_overrides['plug'] = true;
}
Registry::set($o_name, $template_overrides);
}
$init = true;
}
return Registry::if_get($o_name . '.' . md5($resource_name), $resource_name);
}
in the “fn.control.php” file, located in the “core” directory.
[quote name=‘cory1970’]I submitted a ticket to CS-Cart[/quote]
They basically upgraded your cache system to 2.1.2
Time for you to stop busting nuts and just upgrade :rolleyes:
[quote name=‘cory1970’]I just switched to sqlite. I will monitor the site and report back.
What are the advantages of sqlite3 and are there any special requirements?
Thanks![/QUOTE]
For this purpose, they are effectively the same.
I didn’t realize you were running 2.1.0… That version had a major template bug that caused templates to be recached on almost every access… I would do as Jesse suggests and upgrade to 2.1.2 (and apply fixes you can find becuase there are problems there too - but fewer than you probably have now). Then after 2.1.3 comes out you can determine whether to upgrade to that version.
I would not use mysql as the cache method. Either use sqlite or files.