Every time I see an ecommerce site made with VirtueMart I am noticing that whole site is just too slow. Why? I have made a ecommerce site with VM that is slow as well. This is just so annoying. When I use cache plug I get cached all the staff that I don't want to. Does anyone know any good solution on how to speed up VirtueMart?
Which VM version do you use? My pages are pretty fast.
Quote from: eNEXT on July 04, 2013, 14:19:15 PM
Does anyone know any good solution on how to speed up VirtueMart?
Yes, we know nice solution.
You just need give us url to your well hidden website.
Quote from: eNEXT on July 04, 2013, 14:19:15 PM
Every time I see an ecommerce site made with VirtueMart I am noticing that whole site is just too slow. Why?
@eNEXT
Your VM2-Shop (demo?) offering 'Fitness pulsmetry Garmin' products is running pretty quick and if you don't spoil it it will continue to be quick as you add more products.
VirtueMart is pretty fast, but quite a few folks manage to embed it into a lot of slow stuff.
Ok, this is the speed i like. http://www.easyjoomla.org/speeding-up-virtuemart-2-0-joomla-e-commerce-site-case-study
Just for info - The shop the 'case study' is talking about has a javascript problem with the slideshow:
ReferenceError: jQuery is not defined
.../js/slider.js
Line 68
My own VM2 shop, which displays the same number of products on a category browse page, even is a little bit faster than the one from the 'case study' - without any kind of 'speed optimization' and also it's running on a cheap shared server'. Shops which are loading 'a lot' or 'huge' images into each page are slower, but that's because browsers are loading one image after another (not simultaniously), which is not the fault of VM2.
My own VM2 shop, which displays the same number of products on a category browse page, even is a little bit faster than the one from the 'case study'.....
Can I see it? ;)
Quote from: eNEXT on July 05, 2013, 14:18:56 PM
Can I see it? ;)
If you follow the link (posted last November) provided here: http://forum.virtuemart.net/index.php?topic=110005.0
(Note that it still runs on php 5.2, which is a bit slower than newer versions)
post a link to your site and we will give you some suggestions
i dont have a problem with my site being slow
hi guys
i have 51683 products with over 100 categories and manufacturers but we don't have a single manufacturer category and when i go to single product detail page it takes a lot of time to load 20 to 30+secs, also if i search using VM mod product search it also takes a lot of time to return the search result 20 to 30+secs.. already tried to 2 diff version of virtuemart
VM version 2.0.22a, Joomla! 2.5.16 and
VM version 2.0.26a, Joomla! 2.5.17
but still no noticeable diff on the load speed on single product detail page or using VM mod product search but when i got to pages that doesn't has virtuemart component like our homepage,about page, or pages that only has articles it loads fast so i really think that its virtuemart that is really slow..
we're already using Jotcache and JCH optimize plugins
also tried a copy of our site with same template but with default virtuemart sample data and single product detail page loads wayyyy faster compared to our site with 50K products
you can test these 3 same site template with diff versions of joomla,virtuemart and products
http://www.circlebcshop.com.au/ - live actual website with VM version 2.0.22a | Joomla 2.5.16 | over 50k products | installed with JCH Optimize and JotCache plugin
http://demo.circlebcshop.com.au/ - demo site with VM version 2.0.26a | Joomla 2.5.17 | over 50k products installed with System - jbetolo and JotCache plugins
http://demov2.circlebcshop.com.au/ - demov2 with VM version 2.0.22a | Joomla 2.5.16 | default virtuemart sample data | installed with JCH Optimize and JotCache plugin
so can anybody confirm to me that why our site with 50k products is really slow?is it really the product quantity? i really have a big feeling that virtuemart its not ideal for having a big ecommerce site.. :-\
open for any suggestion to enhance virtuemart speedload :-[
ronjb,
you have lots of javascript files being loaded
I gzip my js files like this
http://www.kaizenmediaworks.com/jch-optimize-virtuemart-2-0
You can exclude files if you need to.
Quote from: PRO on January 10, 2014, 01:47:05 AM
ronjb,
you have lots of javascript files being loaded
I gzip my js files like this
http://www.kaizenmediaworks.com/jch-optimize-virtuemart-2-0
You can exclude files if you need to.
thanks for the link,i'll try this out asap..
btw can you guys show me a virtuemart website that has 50+ products and loads fast or with ideal speed load? just curious if virtuemart can really handle a big ecommerce site
thanks
I call bullshit to the responses you gave this poor guy. And all this feedback comes from a MS certified DBA w/ 15 years experience...
Ron they tried same thing with me. Blame you until you give up
First they blamed my host (so I changed to faster host named Rochen)
Then they blamed my template (so i bought Eugen's out of the vm extensions store. Supposedly which was built around VM.....)
Then they said for 500 bucks they would fix it and optimize it, I accepted the offer yet they never spent more than 20mins and again blamed the webhost's mysql server (this time Rochen)
1 year later they wont even reply to my emails or pm's...
Fact of the matter is VM2 pulls from too many tables at once. They even have products broken into multiple tables (up to 4 how sad).
The more rows you have in your database exponentially slows it down due to bad structure and bad query management. Period
If you are running a real company with any sizable inventory then Virtuemart is NOT for you unless you are simply too busy or just don't care what your customers think.
Just walk away now.
If you insist on keeping VM and want your VM to go faster I might suggest that you simply dump the data in all the tables attached to products (by query) and watch it fly
product manufactures, product categories, product this that and the other.....an entire table of rows to search through instead of simply adding a column...
In summary if you have 100k products, start with 200k since products is really 2 separate tables (sigh) then add 100k more to query the linking category, then 100k more for the manufacturer, god forbid you have a pdf or download that's 100k more. See the genius at work here ? There are enough links on this anchor to sink the boat...
Notice there are 27 Pages of result when you search this forum for slow.
Nuff said
Quote from: tampasounds on March 04, 2014, 20:58:09 PM
First they blamed my host (so I changed to faster host named Rochen)
Of course you need with 800k products a really good hosting. You need at least a vserver, better a root server, if not a cloud.
Quote from: tampasounds on March 04, 2014, 20:58:09 PM
Then they blamed my template (so i bought Eugen's out of the vm extensions store. Supposedly which was built around VM.....)
Then they said for 500 bucks they would fix it and optimize it, I accepted the offer yet they never spent more than 20mins and again blamed the webhost's mysql server (this time Rochen)
1 year later they wont even reply to my emails or pm's...
You did not really accept the offer. The problem was that your host did not offer the settings. I told you, you must first switch the hoster. After that you never contacted me again, maybe I missed it. I also never got money from you, so from my point of view, I just spent an hour for nothing.
Quote from: tampasounds on March 04, 2014, 20:58:09 PM
Fact of the matter is VM2 pulls from too many tables at once. They even have products broken into multiple tables (up to 4 how sad).
The more rows you have in your database exponentially slows it down due to bad structure and bad query management. Period
LoL, we call it database normalisation http://en.wikipedia.org/wiki/Database_normalization . In the moment you can store an array of values in relation to a dataset of a table, you need an extra table. You could store it with an implode within a field, but then it is unsearchable.
Quote from: tampasounds on March 04, 2014, 20:58:09 PM
If you are running a real company ...
If you are running a real company, then you should know that performance costs money. From nothing comes nothing, if you are not willing to invest a part of what you want to earn per month, I doubt you will have success. This rule counts for any business.
Quote from: tampasounds on March 04, 2014, 20:58:09 PM
.....an entire table of rows to search through instead of simply adding a column...
yeh lol http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect. You are a Microsoft certified database manager? I should show Microsoft your post and they will remove your certification. Clearly nothing worth. Seems they did not even teach you that a database design is always a compromise between
- Normalisation
- Data reduncy (influences also used space on the hdd)
- Selection performance
The more a database is normalised, the more tables you get. The less data redundancy you have, the more the selection performance goes down. You do not have multiple manufacturers per category, so you do not need this normalisation, you also dont want to search for manufacturers, then remove it.
and if you are a database manager since 15 years, trained by microsoft, tell us the right layout. In case we would just add a manufacturer row to the product table, what would happen if you have more than one manufacturer? We would have two rows, exact the same except the manufacturer. =>redundant data. We store it in a relation table as the normalisation rules say, no redundant data, searchable, but needs an extra JOIN. Please read here http://en.wikipedia.org/wiki/Denormalization
Most VM users have shops up to 50k products and of course VM is optimised for this people, for the majority. There are a lot more people using the multiple manufacturers feature than people having problem with the performance. VirtueMart is a Beetle VolksWagen, if you wanna use it as Pickup, you must invest something, if you want to use it as racing car, you must tune it for this purpose.
and please read here http://en.wikipedia.org/wiki/Professional_open_source
I don't visit very often and saw this reply...That site belongs to one of my clients. My day job is with a ERP software company (desktop) which is also in house there.
They are a prized client though as you have seen their offering
Milbo, I'm going to be honest here , and I'm not going to use a wiki to try and insult you. You can re-read your own post and you will feel bad enough I'm sure.
Normalization is what they teach kids to be the holy grail of database design structure from day 2. It has proven ""concepts"" to a degree but your teacher was wrong to describe this as be all end all LAW
An inflexible approach to a single known concept is what someone who doesn't really know what to do will lean on for rigidity. They will defend their belief vehemently thinking that is the only ""right"" way (and you drop Kruger in my lap, lulz)
I could go on and on arguing the ups and downs of normalization which is what you want but not what you need. The bottom line if is that if you want to fix a million*(x) record bottle neck and support larger businesses,
you gotta flatten the table and lose the joins. Normalization is a practice not a law.
The Microsoft police wont come out and take your certs because you sinned and had a few extra redundant columns to avoid multiple joins for the sake of exponentially increasing capacity and performance of your application.
I can pull a part number (Product name) out of (now 600k rows) in sub 1 sec with a flat wide open search. Seriously
PM me and i'll let you team viewer in to see it yourself...
And Yes ill build you the table to test with, but the fix is so easy you could write it on the back of your hand like a chicks phone number.
It seems you just ignored what I wrote.
In short words. You cannot write a perfect table layout optimised for any case. It is always a compromise.
BTW: Version vm26 has a more finegrained selection. At one point the general rant was okey. We unnecessary joined the manufacturer table sometimes. This is removed. But we still use the same table layout.
Quote from: Milbo on March 05, 2014, 11:02:28 AM
a database design is always a compromise between
- Normalisation
- Data reduncy (influences also used space on the hdd)
- Selection performance
The more a database is normalised, the more tables you get. The less data redundancy you have, the more the selection performance goes down. You do not have multiple manufacturers per category, so you do not need this normalisation, you also dont want to search for manufacturers, then remove it.
... In case we would just add a manufacturer row to the product table, ...? We would have two rows, exact the same except the manufacturer. =>redundant data. We store it in a relation table as the normalisation rules say, no redundant data, searchable, but needs an extra JOIN. Please read here http://en.wikipedia.org/wiki/Denormalization
... VM is optimised ... for the majority. There are a lot more people using the multiple manufacturers feature than people having problem with the performance. VirtueMart is a Beetle VolksWagen, if you wanna use it as Pickup, you must invest something, if you want to use it as racing car, you must tune it for this purpose.
Quote from: tampasounds on April 02, 2014, 06:37:51 AM
And Yes ill build you the table to test with, but the fix is so easy you could write it on the back of your hand like a chicks phone number.
Ehrm, and why you tell us this instead of just giving the fix? It seems you do not understand how an opensource project works. The idea of opensource projects is exactly that people use the code and donate something back. Some people give support, others test and some others return fixes, some people organise, others do marketing and so on.
tampasounds i like your post but you might missing some other aspects which are important according to my humble opinion.
1. How will you deal with 1 x many relationships? Possibly you will have to repeat the same rows again and again creating an enormous table
2. How you can maintain a table which is not normalized?
For example you can work with keys when the tables are normalized but when this does not happen you will possibly have to repeat the same values. Right?
So lets say that you want to update a manufacturer name of a manufacturer used in x products.
Without normalization that means that you have to update all the x product records?
What i mean is that reading the db and the performance of this is just one aspect and requirement but not the only one. You have to deal with others as well
I may be a little late, but I think the best way to go for such a large store is to go VPS at the very least. Once that`s installed, optimize you images with JCH and install Varnish to go along with your server. There are also cdn options that will make things even faster.
MCaves the post is completly outdated, because it was written in vm2 times. VM3 is a lot faster, also with 100k products.
Quote from: tampasounds on April 02, 2014, 06:37:51 AM
Normalization is what they teach kids to be the holy grail of database design structure from day 2. It has proven ""concepts"" to a degree but your teacher was wrong to describe this as be all end all LAW
He ignored my already given answer, because I wrote
Quote from: Milbo on March 05, 2014, 11:02:28 AM
... a database design is always a compromise between
- Normalisation
- Data reduncy (influences also used space on the hdd)
- Selection performance
The more a database is normalised, the more tables you get. The less data redundancy you have, the more the selection performance goes down. You do not have multiple manufacturers per category, so you do not need this normalisation, you also dont want to search for manufacturers, then remove it.
So I said already, that we dont do database normalisation for itself. A good example are the product prices. They dont have multiple shoppergroups, you would need to store an extra price for each shoppergroup. We get redundant values, because the price rows are the same except for the shoppergroup entry, but it is a lot faster than to add an extra JOIN just for the shoppergroup depended prices. The amount of redundant data is not that much and the feature is used by approximatly less than 20% of our users.