News:

You may pay someone to create your store, or you visit our seminar and become a professional yourself with the silver certification

Main Menu

Large Store Running Very Slow

Started by alexr451, June 29, 2015, 21:51:30 PM

Previous topic - Next topic

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


jenkinhill

Kelvyn
Lowestoft, Suffolk, UK

Retired from forum life November 2023

Please mention your VirtueMart, Joomla and PHP versions when asking a question in this forum

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)
GJC Web Design
VirtueMart and Joomla Developers - php developers https://www.gjcwebdesign.com
VM4 AusPost Shipping Plugin - e-go Shipping Plugin - VM4 Postcode Shipping Plugin - Radius Shipping Plugin - VM4 NZ Post Shipping Plugin - AusPost Estimator
Samport Payment Plugin - EcomMerchant Payment Plugin - ccBill payment Plugin
VM2 Product Lock Extension - VM2 Preconfig Adresses Extension - TaxCloud USA Taxes Plugin - Virtuemart  Product Review Component
https://extensions.joomla.org/profile/profile/details/67210
Contact for any VirtueMart or Joomla development & customisation

Milbo

or even better, he should try the BE product listing.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

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.




Milbo

Quote from: Studio 42 on July 03, 2015, 00:52:55 AM
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!
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Studio 42

#8
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 ?

Quote from: Milbo on July 06, 2015, 13:56:20 PM
Quote from: Studio 42 on July 03, 2015, 00:52:55 AM
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.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

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.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

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

Quote from: Studio 42 on July 08, 2015, 22:44:06 PM
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.


Quote from: Studio 42 on July 08, 2015, 22:44:06 PM
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.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

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.