MASSIVE speed improvement

Hi all, I thought I would just share with you my experience and SO sorry if this has already been posted. I have just opened my config.local.php and altered my cache backend from



$config[‘cache_backend’] = ‘file’;



to



$config[‘cache_backend’] = ‘mysql’;



And I have to say I have seen a mahoosive speed increase in CS-Cart



Let me know how you all get on.

[quote name=‘AmitP’]Hi all, I thought I would just share with you my experience and SO sorry if this has already been posted. I have just opened my config.local.php and altered my cache backend from



$config[‘cache_backend’] = ‘file’;



to



$config[‘cache_backend’] = ‘mysql’;



And I have to say I have seen a mahoosive speed increase in CS-Cart



Let me know how you all get on.[/QUOTE]



Amit, now go back & switch the cache method to SQLITE which will give you the best long term troublefree results & observe. (You may soon start to run into problems if using the SQL method as this method can rapidly increase the size of your Mysql database!)

sqlite has not improved the speed at all, infact it’s hindered it and made it slower. Can I not gain back the bloated space on the mysql cache by pressing the optimize database once in a while?

[QUOTE]sqlite has not improved the speed at all, infact it’s hindered it and made it slower[/QUOTE]



Amit, you would have to be one of the very few that has experienced this then!



If you are on 2.1.1 per your signature, than I can also say there have been some quite substantial cache improvements from 2.1.1 to 2.1.4 (the caching of blocks alone makes a big difference & was highly needed).

[quote name=‘AmitP’]sqlite has not improved the speed at all, infact it’s hindered it and made it slower. Can I not gain back the bloated space on the mysql cache by pressing the optimize database once in a while?[/QUOTE]





I have had multiple larger clients crash their shops using the mysql cache method because some of the table fields filling to capacity and this then causes mysql errors preventing the store from loading at all.



This is caused by the table/field structure and can be remedied by increasing some values.



Original Structure

name varchar(128)
data text
expiry int(11)
tags varchar(64)




Changing this to below should resolve this problem for all stores

name varchar(256)
data mediumtext
expiry int(11)
tags varchar(128)

your welcome to take a look Struck



www.custom-cable.co.uk



This is with SQLite, will ?cc clear the cache for SQlite and mysql when its run?

[quote name=‘AmitP’]your welcome to take a look Struck



www.custom-cable.co.uk



This is with SQLite, will ?cc clear the cache for SQlite and mysql when its run?[/QUOTE]



The url method will clear the cache regardless of which cache method used. Personally I prefer to delete the entire /var/cache as well as /var/compiled directories thru ftp and watch them rebuild.

i take it back, I just rebooted my pc, cleared my browser cache now the store flies. Thanks a lot dude. really nice improvement to the stores speed.

Well, I am a bit confused now… So, regardless, choose the cache method you want to use, clear your cache out, and then let it rebuild as it can take quite some time for your entire site to be fully re-cached and stabilize as each page has been re-visited for the 1st time.



Anytime I clear my site cache, I take the time to browse through the majority of my site pages and load them to speed up the cache building process rather than allowing our site visitors to experience a slow initial page load while the site is re-caching.



Also, S-combs clearly explained why you most likely do not want to use the Mysql cache method, so best to choose sqlite and let it stabilize. :wink:

We received “Division by zero Error” errors when we changed “file” to “sqlite” on the config.local.php . I am guessing we do not have “sqlite” installed on our server. So be very careful doing the change unless you know you have the software needed on your server.



Good thing we had a back up of the file as everything is fine again.

Have been running sqlite now for a few hours and now I’m getting an error 500 internal server error and this



Fatal error: Out of memory (allocated 524288) (tried to allocate 77824 bytes) in /public_html/core/fn.users.php on line 744

sqlite uses the same database table structure as the mysql method I posted above so you may have exceeded a character limit in some of the fields which resulted in corruption of that data. That could in turn cause the PHP memory and divide by 0 errors since the cached instructions are corrupted.



Increasing the field sizes and clearing the existing cached data should resolve it if that is the case.



I have had no clients mention problems with sqlite yet but I’m not sure if any are using it… Since the tables are the same as the mysql method it is just as susceptible to the same problem…

Thanks S-combs, where would the file alterations be amended so as to alter the char size limit etc, is this a mysql query that needs running? actually it looks like this can be ammended in phpMyAdmin?

This can be done by dropping and recreating the table with the increased values in phpmyadmin




DROP TABLE IF EXISTS `cscart_cache`;
CREATE TABLE IF NOT EXISTS `cscart_cache` (
`name` varchar(256) NOT NULL DEFAULT '',
`data` mediumtext,
`expiry` int(11) DEFAULT NULL,
`tags` varchar(128) DEFAULT NULL,
PRIMARY KEY (`name`),
KEY `tags` (`tags`),
KEY `name` (`name`,`expiry`)
);

Be very careful using mysql as the backend cache. Part of the goal of a cache is to use a separate channel or descriptor for cached data. Spreading data betwen mysql and sqlite (or shared memory) is better.



Amit’s memory setting is way too low to begin with at 48M in his config.local.php file. I would recommend a minimum of 64M and usually set my clients at 128M.



Shared memory (by definition) would be the fastest. But if you’re short on RAM and the system starts swapping to account for the data usage then you end up no better than files or sqlite method.



If the method is not available on your system, you will get an error on the first access clearly stating that the caching method is not supported by your server.

Thanks all, I have played with memory and adjusted to 128M. I did have one error message when using sqlite but it then resolved itself after a second load of the page. It looked like it ran a self install on my server looking at my logs from last night.



Regards

I was gonna have a try at this but my config.local.php doesnt have

$config[‘cache_backend’] = ‘file’

anywhere,



Is this discrimination ?:rolleyes:

But I will say that I changed over to the VPS recently and it runs much smoother/faster than before and would recommmend it to anyone if budget allows.

JOhn

Johnbol,



Within your “config.local.php” file, (towards the bottom you should see):


// Cache backend
// Available backends: file, sqlite, mysql, shmem
// To use sqlite cache the "sqlite3" PHP module should be installed
// To use shmem cache the "shmop" PHP module should be installed
$config['cache_backend'] = 'sqlite';




You can see that I have chosen the sqlite cache method in this example.



After selecting the new cache method, clear your cache to remove any files from the old cache method and let your site cache rebuild itself fresh. Also, if using smartoptimizer, I always delete the contents of my /smartoptimizer/cache/ folder as well so that it also rebuilds as needed after the cache method changes. Remember it will take some time for all of your site files to be re-cached and stabilize so give it some time before coming to a conclusion of good or bad! :wink:

yeah in my OLD config.local.php i have this

// Default permissions for newly created files and directoriesdefine(‘DEFAULT_FILE_PERMISSIONS’, 0666);define(‘DEFAULT_DIR_PERMISSIONS’, 0777);// Database tables prefixdefine(‘TABLE_PREFIX’, ‘cscart_’);// Default permissions for newly created files and directoriesdefine(‘DEFAULT_FILE_PERMISSIONS’, 0666);define(‘DEFAULT_DIR_PERMISSIONS’, 0777);// Database tables prefixdefine(‘TABLE_PREFIX’, ‘cscart_’);// Cache backend// Available backends: file, sqlite, mysql, shmem$config[‘cache_backend’] = ‘file’;// Cache backend// Available backends: file, sqlite, mysql, shmem$config[‘cache_backend’] = ‘file’;?>



But in my new one I dont, shall I just copy it in do you reckon and give it a go.





JOhn

Amit,


[QUOTE]Thanks all, I have played with memory and adjusted to 128M. I did have one error message when using sqlite but it then resolved itself after a second load of the page[/QUOTE]



Most likely nothing more than a temporary conflict of cached files after switching cache methods, this is why I always go back & clear the cart cache (after switching the cache method) to let it rebuild fresh & proper, consider it cleaning house. If you are running smartoptimizer (which you should be), then also clear out the contents of the /smartoptimizer/cache/ directory.