I have been struggling to enter products in this site. I re-uploaded all images into a different folder but no difference. This site has 2 categories and 13 products. I ran a test on WebPage test and got 38/100.
I ran a test on GTmetrics and got
Page Speed Grade: F (38%)
YSlow Grade: C (73%)
Page load time: 5.94s
Total page size: 654KB
Total # of requests: 43
I compared that result with another website with hundreds of products and got hugely different results. Is it the # requests? What do I do now?
Thoughts) Overall, What is your server stats? Mem, CPU, etc? Can you log into SSH to see TOP (or lveTOP) and check out mySQL CPU useage? If no, use cpanel and hit your site, keep refreshing cpanel to see stats. When you are in cpanel, what are your max entry processes set at? Do you notice anything in error_log in cpanel? Anything popping out in WHM daily load averages (your host can tell you)? Any LVE EPf faults? Your host can run lveinfo --period=14d --by-fault=mep --display-username to see this. Via this same lveinfo the host can tell you what your CPU and ram is averaging at, perhaps its capping out?
Requests) These are the times a browser has to connect to acquire a resource (code, file, css, js, images, widgets, etc). Facebook, peoples extensions, and other stuff ends up adding tons of requests since they end up with their own libraries, scripts, css, etc. The less of those there are, especially SSL, especially for slow net, the faster your page will be able to render. Make sure all items that require SSL use the "//" instead of "https://" and this will make them conditional. You can also counter requests slightly by setting caches in HTACCESS within store level. You can also use https://code.google.com/p/minify/ to consolidate resources into 1 if you know what youre doing. There is also varnish cache, but thats even more advanced. Heres the HT example:
You can also turn on Gzip (Apache mod_deflate) from store settings, turn it up to like 4-6 and check to see if its enabeled on your server here http://www.gidnetwork.com/tools/gzip-test.php but remember to put your whole site address including http://www if applicable. If its off, ask your host to turn it on. if he doesn't, checkout how to do it with HTACCESS via some random tutorial.
Sessions) There is a possibility that your max clients are capping out too, but its unlikely without thousands of unique ppl a day hitting your install and/or your server limits set too low for this traffic. In this case, a client would have to wait for an open spot to connect to your server. If you need to see recent sessions, check out the little VQ we are working on: That will allow you to see recent customer online reports more clearly (found at bottom of this post). Keep in mind its beta, internal tool
As far as Apache/SQL side here is a cool guide for Max Clients http://diywpblog.com/how-to-work-out-ma ... ng-apache/
High SQL Use) This seems to be the culprit for alot of OC installs -- slow and too many DB queries. In default OC, each query will start at row 1 for each table and reiterate through until the row is found. This is mega slow and on a weak server can take a long time even with low items. Index keys are the "key" to making it a runner. Our store has about 18,000 entities and pageload is now less than 2 seconds. Here is an overview http://bloke.org/php/opencart-is-slow-w ... ategories/ and here is the post with the correct queries http://bloke.org/php/opencart-is-slow-w ... mment-3993 or if youre feeling dangerous/lazy, you can run turbo to put keys on ALL tables in your store https://github.com/chrisatomix/opencart-turbo (we ran it on a test store with no negative effect)
GooglePagespeed) This tool is pretty hardcore -- if you ever ran google itself through the pagespeed you will understand why its hard to get above 80%. Pay attention to the suggestions like: sprites, consolidate css, minify js, reduce inline styles/scripts, turn on long limit caching (1 week or more). As you can see even the developers site doesnt score too great http://developers.google.com/speed/page ... ab=desktop
Overall, its sometimes hard to just *make it go faster* since its often a combination of angles you need to work down to 1 cause of a bottleneck. By going over all of these though you should be able to speed it up at least some. Have fun!
Requests) These are the times a browser has to connect to acquire a resource (code, file, css, js, images, widgets, etc). Facebook, peoples extensions, and other stuff ends up adding tons of requests since they end up with their own libraries, scripts, css, etc. The less of those there are, especially SSL, especially for slow net, the faster your page will be able to render. Make sure all items that require SSL use the "//" instead of "https://" and this will make them conditional. You can also counter requests slightly by setting caches in HTACCESS within store level. You can also use https://code.google.com/p/minify/ to consolidate resources into 1 if you know what youre doing. There is also varnish cache, but thats even more advanced. Heres the HT example:
Code: Select all
### Caching - Turn on Expires and Set Default to 0
ExpiresActive On
ExpiresDefault A0
### Caching Media Files - 1 Month
<FilesMatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav)$">
ExpiresDefault A2592000
Header append Cache-Control "public"
</FilesMatch>
### Caching Image Files - 1 Month
<FilesMatch "\.(gif|jpg|jpeg|png|swf)$">
ExpiresDefault A2592000
Header append Cache-Control "public"
</FilesMatch>
### Caching Build Files - Currently Set to 1 Day For Development - Change to 1 month later
<FilesMatch "\.(xml|txt|html|js|css)$">
ExpiresDefault A86400
Header append Cache-Control "proxy-revalidate"
</FilesMatch>
### No-Cache Dynamic Files
<FilesMatch "\.(php|cgi|pl|htm)$">
ExpiresActive Off
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</FilesMatch>
Sessions) There is a possibility that your max clients are capping out too, but its unlikely without thousands of unique ppl a day hitting your install and/or your server limits set too low for this traffic. In this case, a client would have to wait for an open spot to connect to your server. If you need to see recent sessions, check out the little VQ we are working on: That will allow you to see recent customer online reports more clearly (found at bottom of this post). Keep in mind its beta, internal tool
As far as Apache/SQL side here is a cool guide for Max Clients http://diywpblog.com/how-to-work-out-ma ... ng-apache/High SQL Use) This seems to be the culprit for alot of OC installs -- slow and too many DB queries. In default OC, each query will start at row 1 for each table and reiterate through until the row is found. This is mega slow and on a weak server can take a long time even with low items. Index keys are the "key" to making it a runner. Our store has about 18,000 entities and pageload is now less than 2 seconds. Here is an overview http://bloke.org/php/opencart-is-slow-w ... ategories/ and here is the post with the correct queries http://bloke.org/php/opencart-is-slow-w ... mment-3993 or if youre feeling dangerous/lazy, you can run turbo to put keys on ALL tables in your store https://github.com/chrisatomix/opencart-turbo (we ran it on a test store with no negative effect)
GooglePagespeed) This tool is pretty hardcore -- if you ever ran google itself through the pagespeed you will understand why its hard to get above 80%. Pay attention to the suggestions like: sprites, consolidate css, minify js, reduce inline styles/scripts, turn on long limit caching (1 week or more). As you can see even the developers site doesnt score too great
http://developers.google.com/speed/page ... ab=desktopOverall, its sometimes hard to just *make it go faster* since its often a combination of angles you need to work down to 1 cause of a bottleneck. By going over all of these though you should be able to speed it up at least some. Have fun!
https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.
Thanks very much for your comprehensive reply, Dhaupin.
I contacted the hosting company and they said this site was on an old server. They could move it but that would mean they would have to also move the other site on this account. So, the techie added in a memory limit line in the htaccess to override the system and that seemed to have immediate effect. I then decided to make another change to the htaccess file and that got me 500 error pages instead. Everything I tried messed it up more, and the only way I could get it to work was to go back to the original htaccess.
So I purchased NitroPack and now it is running at 79% page speed which is more than twice the speed previously. It might not be perfect, but I'm happy.
I contacted the hosting company and they said this site was on an old server. They could move it but that would mean they would have to also move the other site on this account. So, the techie added in a memory limit line in the htaccess to override the system and that seemed to have immediate effect. I then decided to make another change to the htaccess file and that got me 500 error pages instead. Everything I tried messed it up more, and the only way I could get it to work was to go back to the original htaccess.
So I purchased NitroPack and now it is running at 79% page speed which is more than twice the speed previously. It might not be perfect, but I'm happy.
Who is online
Users browsing this forum: No registered users and 42 guests
