Are 4.1.3 & 4.1.4 Inherently As Slow As Poison ?

I am running 3.0.6 and it hums along very nicely.

Installed 4.1.3 in a separate folder in the 'root'.

I assume the 'root' is the area under public_html where my 3.0.6 is located.

Installed with no sample data.

Anyway, 4.1.3 was basically crawling. I deleted the folder.

Tried 4.1.4 ( except with sample products ) as I did 4.1.3

Same 'crawling' so I deleted the folder.

Are 4.1.3 & 4.1.4 just plain slow 'out of the box' ?

Running PHP 5.3

My web host has advised that PHP 5.4 has more to do with security

that speed.

My interim solution is to stay with 3.0.6 until SAAS is commercially live.

Why would you think SaaS is going to be any faster than a resident version?

Currently SAAS runs almost as quickly as my 3.0.6

Fully loaded later may be a different story I suppose.

In any case my future options will not include 4.1.3 or 4.1.4

unless support can offer a solution to speed them up.

My 3.0.6 is non-tweeked out of the box.

My 4 installation is flying, much much faster than 3 (which I skipped)

Half your luck Flow.

I am not going to pay good money to support for optimization information

that should be available in the installation package so I will sit tight for now.

All the best for your business.

I take it you know the hardware and config specs of what the SAAS demos are running on?

All servers need tweaking to make the best of the main software running on them. If you installed a vanilla web server and then configured it for streaming corporate videos it would be a different setup from a 100,000 product webstore.

If SAAS is not an option then I will stay with 3.0.6

I installed 3.0.6 without any problems at all.

I have installed 4.1.4 three times now and it is as slow as poison.

Perhaps I have misconfigured something but I can easily blame

the documentation, which in my view cannot possibly be aimed

at the general knowledge user.

I like CS-Cart very very much but I can get so flustered at times.

I just had a look at the installation documentation and I think

I probably stuffed up the permissions.

Time to give it another shot. Fingers crossed.

This is how reports demo of at present.


[color=#777777][font=Arial, Tahoma, Verdana, sans-serif][size=3]


[size=3]Page Speed Grade:[/size]




[size=3]YSlow Grade:[/size]



Page load time: 5.64s

Total page size: 1.87MB

Total number of requests: 105[/size][/size][/font][/color]

Just tried it with my cart.

It would be great if I understood how to implement the recommendations…lol

I guess if I stare and google long enough some light bulbs might go off.

Is there any service available to implement the recommendations

and can this service give me a quote ?

I'm 88 and 91%, loadtime 3 sec, without any fine-tuning at all, with the new responsive theme.

You have a very high number of requests… I have only half of that,

Running 4.1.3

Page Speed Grade: A (95%)

YSlow Grade: B (86%)

Page load time: 2.21s

Total page size: 740KB

Total number of requests: 33

Running 4.1.3 on a dedicated server. Optimized or tweaked by Future Hosting the best we/they knew how. We had better luck on a “shared” hosting package then we did a VPN and without a doubt it is better on a dedicate box.

Page Speed Grade: A (94%)

YSlow Grade: B (86%)

Page load time: 3.56s

Total page size: 524KB

Total number of requests: 56

Since we're all measuring sizes; dedicated VPS with my own tuning.

Page Speed Grade: A (96%)

YSlow Grade: B (84%)

Page load time: 4.96s

Total page size: 1.11MB

Total number of requests: 32

Damn, does that mean that “size matters”? :-)

Giving it another go.

This is it out of the box with sample products.

Any hints for tweaking config.local.php would be greatly appreciated.[color=#777777][font=Arial, Tahoma, Verdana, sans-serif][size=3]

[size=3]Page Speed Grade:[/size]


79%[/size][/font][/color][color=#777777][font=Arial, Tahoma, Verdana, sans-serif][size=3]


[size=3]YSlow Grade:[/size]



Experiment with this setting

// Cache backend

// Available backends: file, sqlite, database, redis

// To use sqlite cache the “sqlite3” PHP module should be installed

$config['cache_backend'] = 'file';

Tried 'sqlite' and 'sqli' and 'sql'. Each resulted in no loading at all.

Went back to 'database' and loads OK but slow.

Valid options are (for V4), 'mysql' and 'file'. I don't believe sqllite is supported any more and neither is 'shmem'.

I would recommend you stick with 'file' and look at what you can change in your hosting environment to find the point where things start to work for you. There are a lot of variables on the hosting side. If you're using a shared environment then you have zero control over how the available resources are being used. If you run a VPS, you can allocate memory so that you provide more (than standard) to mysql which is probably the greatest resource consumer of your environment.

// Cache backend

// Available backends: file, sqlite, database, redis

// To use sqlite cache the “sqlite3” PHP module should be installed

$config['cache_backend'] = 'file';

$config['cache_redis_server'] = 'localhost';

// Storage backend for sessions. Available backends: database, redis

$config['session_backend'] = 'database';

$config['session_redis_server'] = 'localhost';

Same loading speed if file is substituted with database.

Early days yet. I will leave it in a sub folder of public_html

until I can get it sorted out.

I am sorry but you are comparing apples with bananas (not even that) - this is not the best way to benchmark and what you are seeing from others is all irrelevant and non-comparable to you, apart perhaps to indicate that the problem is not inherently with 4.1.3. Some people posting results from 2Mb pages with 100+ requests, others from 500Kb pages with 30 requests. Even within your own installation you are comparing a live store with one with sample products etc.

Also, you are just comparing the overall 'grade', even having big/small images will really affect that loading time.

It would be best to get someone who has done it before to methodically work through things - need to break it down and see what is taking time, why it is slow etc. Can be anything from the db, to the config, to the presentation. Also I am guessing you are only comparing the homepage?