Large Store Running Very Slow

[alexr451]

I have built a very large and complex Virtuemart store with about 200k itmes in it but now that they are all upload the load times for are very slow. Please HELP!  there is no way my store will be successful with load times like this.   Thanks!!

[PRO]

do you want us to look at it?

[jenkinhill]

!!!  http://forum.virtuemart.net/index.php?topic=79799

[GJC Web Design]

To set a bench mark you should try with the standard Protostar template to eliminate template loading delays etc (I assume your on J3/VM3)

[Milbo]

or even better, he should try the BE product listing.

[Studio 42]

Hi alexr451, first try to optimize your site.

I have optimise a site running in 8.5 second to 2.3 secondes loading time without any database changes !
And the other from +4 secondes  to 1.3/1.4 secondes.

How :
Remove unused modules, disable when you are not sure.
Remove unused plugins,
Try to use only one template, if you can.
Set default number of product to 20 MAX.
Set latest,best sale... to 10 products max in main vm page and modules.
Disable all unneeded sildeshow.
Check your server settings(cache, expire time ...)
Remove 3party sef.

More advanced with database changes :
Do not use product childs(or only really needed levels) Each level add plenty of query.
Set correctly your modules(see in "all page", is pretty faster as selecting "some pages" ...), remove modules set to page "none".
Do not forget to delete your trashed items(menu,module ...) !

Resize your big images, use optiPNG or similar tools.

Look in google pagespeed, he gives you many more advices.

[David Kan]

Thanks Studio 42

https://developers.google.com/speed/pagespeed/insights/

https://developers.google.com/speed/pagespeed/module/

[Milbo]

More advanced with database changes :
Do not use product childs(or only really needed levels) Each level add plenty of query.

This is completly wrong for vm3, it is the opposite! You can spare a lot of queries if you put your common attributes in a parent!

[Studio 42]

Max, do you have test it?
I have do the test, you have always more query for childs in my tests, especially when you use multiple levels.
The parent is cached in vm3 now, and so for 1st level the difference is negligible(in number of query and memory)

Now my test result in vm3 for 10 products with no module, i created 1 categorie, for each test  (this include all joomla queries):
10 products : 149 queries
1 product,9 childs, one level : 151 queries
1 product,9 childs, 1,2,3 or 4 levels : 164 queries

i only changed the short desc for childrens, no new price, categories or any settings.
And this is for Vm3 , vm2 has no so advanced cache, and give even poorer results.
For what reason, I will say that children are slower ?

More advanced with database changes :
Do not use product childs(or only really needed levels) Each level add plenty of query.

This is completly wrong for vm3, it is the opposite! You can spare a lot of queries if you put your common attributes in a parent!

[Milbo]

Yes I talked about vm3. Yes I tested it. It depends on the kind of query. Just to count the queries is not sufficient. It becomes really faster, when you compare it with customfields.

[Studio 42]

Hi max
Some more result for 10 products(multiple-levels),
1st run and 2nd run
in case of multi levels:
loading : 1231.1,1207.1 ms
memory: 26 589 312 Bytes,26 590 800 Bytes
database query:320.0 ,201.0 ms
No child
loading : 1208.1, 1148.1 ms
memory: 26 248 608 Bytes,26 210 064 Bytes
database query:209.0 ,183.0 ms

As i said only when you use 1st level you can be faster, when you reuse it multiple times in same category.
On the product details page, can never be faster, because you have always to load, child and main product(at least)

My conclusion(i tested this before this post and redo today the test to be sure) is that child can only be a little faster when used many times in same categories when using 1 level.

The real gain you have is in the database size.

This conclusion is for VM3( in vm2 you are always slower with childs)

[Milbo]

Nono, quite useless comparison. The trick comes, when you load more than one product, for example 50 products.

[Studio 42]

Hi Max,
I tried a standard value.
How many shop display 50 products in the same page ?

10 is the half of 20 and this is the standard value for shop(or 18,24) paginaoins. I think most of time you display not more as 10 children using a parent product as model in other case you use variant, especially if you don't wan't duplicate content(if you change all the product, then using children is stupid).
I don't say that the children are bad, i said only do not use multiple levels for nothing.
And here we speak for category view not for product details. Because in this case you have always to get all parents products.

I only checked the logic way to use children from a main product model.
Why 50 ? To have duplicate contents in google? TO override all the main product informations ?

[Milbo]

How many shop display 50 products in the same page ?

Patrick, OMG. Priceless. We talk about benchmarking, you can also use 20 products. The point is that the more often you use the same parent, and the more often you display a product using the same parent, the faster it becomes compared to before. Because the parent is already loaded.

10 is the half of 20 and this is the standard value for shop(or 18,24) paginaoins....
...
Why 50 ? To have duplicate contents in google? TO override all the main product informations ?

And there you see the nonsense, you are talking about. No one wrote you should display 50 times the same product, and you know that. I talked about products using the same PARENT! and i am sure you know that also. So why do you try to show me as stupid guy who has no clue. It is silly man. At begin you talk about the pagination, suddenly you talk about duplicated content. I was of course talking about a pagination set to 50.

[Studio 42]

Max,
I simply don't benchmark, a never used situation, but a real live sample.
Of course if you load 50 times the cached parent, it's faster. I never said that your test is false.